Workday Security Group Misconfigurations: The Complete Audit Guide
Workday security group misconfigurations are the single most common SOX audit finding in enterprise HR environments. They almost always trace back to one of three patterns: ISU over-access from go-live, user-based group sprawl, or unconstrained groups on payroll and compensation domains. This guide covers all three with the exact Workday navigation paths to find and fix every one.
1. The three security group types and how each one fails
Workday has three security group types, and each fails in a different way.
Role-Based Security Groups are dynamic — membership is tied to org role assignments (HR Partner, Payroll Partner, Benefits Partner) and updates automatically when a worker's role changes. They are the lowest-risk type when configured correctly.
User-Based Security Groups are static and admin-managed. Every member is an explicitly named user. This is where 'the Sarah problem' lives: a worker moves into a new role, the admin adds her to the new group but forgets to remove her from the old one, repeat 200 times over three years, and now nobody knows who has access to what.
Integration System Security Groups (ISSGs) are the robot accounts. Each ISU is associated with an ISSG that grants domain-level permissions for the data the integration reads or writes.
2. The ISU misconfiguration pattern
During go-live, the integration consultant grants the payroll ISU access to the 'Workday Account' domain, the 'All HCM Data' report group, and 'Worker Data: All Positions' — because it was easier than scoping minimal permissions under deadline pressure. Five years later, the integration only needs to read basic worker demographics for a headcount report, but the ISU still has access to every compensation record, every bank detail, and every disciplinary action in the tenant. This is a SOX §404 finding every single time.
3. The 'Do Not Allow UI Sessions' flag
ISUs should interact with Workday via web service calls only — not the UI. If 'Do Not Allow UI Sessions' is not checked on the ISU account, anyone with the ISU credentials can log into the Workday UI directly. No MFA, no SSO, full access to everything the ISU's ISSG permits.
Navigation: ISU account → Edit → check 'Do Not Allow UI Sessions' → Save → activate the pending security policy change.
4. What auditors actually look for
- 'Compare Security Permissions of Two Security Groups' — finds overlapping groups granting unintended cumulative access.
- 'View Security Groups' filtered to User-Based — identifies every static group that requires manual membership management.
- Unconstrained groups — a security group with no org-level constraint on a compensation or payroll domain returns data for ALL workers in the tenant, not just the manager's team. This is a SOX and a GDPR Art. 5 finding simultaneously.
5. The PwC data point
PwC's 2025 Workday security analysis found that companies can reduce Workday security administration cost by 25% with a simplified security model. Security group proliferation — the practice of creating a new group with minor tweaks for a small population rather than reusing existing groups — is the primary driver of audit fee inflation in Workday environments.
6. Remediation steps with exact Workday navigation
- Step 1 — 'View All Security Groups' → filter Type = User-Based → export.
- Step 2 — For each group, 'View Members of Security Group' → identify anyone whose current role no longer justifies membership.
- Step 3 — 'Compare Security Permissions of Two Security Groups' → find overlapping groups and consolidate.
- Step 4 — For ISUs, 'View Integration System User' → check 'Do Not Allow UI Sessions' → review ISSG domain list against what the integration actually reads/writes.
- Step 5 — Document the before/after in the Risk Control Matrix for SOX evidence.
Segregation of duties conflicts hiding inside overlapping groups
Beyond unconstrained access, the second-most common SOX finding in security group audits is a segregation of duties conflict created by overlapping group membership rather than by any single group's design. A worker who sits in both the 'Compensation Partner' role-based group and the 'Payroll Administrator' user-based group — perhaps because they covered a colleague's role during a leave of absence and were never removed — now has the ability to both set a compensation change and process the payroll run that pays it out. Neither group in isolation is misconfigured. The conflict exists only in the intersection, which is precisely why 'Compare Security Permissions of Two Security Groups' needs to be run not just for groups with similar names but for any pairing that could plausibly be held by the same person given your organisational structure.
Building an SoD conflict matrix — a simple grid of role pairs that should never be held by the same individual — and running membership overlap checks against it on a recurring basis catches this pattern before an auditor does. Most tenants that have never built this matrix discover, on first audit, that at least a handful of workers hold conflicting combinations, almost always as a residue of role transitions rather than deliberate provisioning.
The domain security policy layer most admins never touch
Security groups are only half of Workday's access control model. Domain security policies define what actions each security group can perform against a given domain — View, Modify, Approve are common examples — and it is entirely possible for a security group's membership to look correct while the underlying domain policy grants that group far more capability than intended. A group intended to have read-only visibility into compensation data for reporting purposes can end up with Modify access on that domain if the domain policy was copied from a template during initial configuration and never trimmed. Auditing security groups without also auditing the domain policies they are attached to gives an incomplete picture — a correctly scoped group attached to an over-permissive domain policy still results in over-access.
Run 'View Domain' for every domain in the Compensation, Payroll, and Benefits functional areas and check the full list of security groups granted access, cross-referencing the specific permission type (View, Modify, Approve, Correct) against what that group's function actually requires.
Constrained vs. unconstrained: reading the constraint logic correctly
A constrained security group limits the data returned to the members' scope — for example, a manager's security group constrained to 'workers in the manager's supervisory organisation hierarchy' will only ever return data for that manager's own team, regardless of how broad the underlying domain permission is. The constraint is what makes broad functional access safe at scale. When a group is left unconstrained — no organisational, location, or worker-population limiter applied — every member of that group can see or act on every worker in the tenant that the domain covers, which is rarely the intent for anything below the HR Partner or Payroll Partner level.
The audit check here is specific: for every security group with access to a sensitive domain (compensation, benefits enrolment, disciplinary action, bank details), verify a constraint is actually applied and that the constraint logic matches the intended population. A constraint set to the wrong organisational level — say, constrained to 'company' rather than 'supervisory organisation' — technically has a constraint but one so broad it is functionally unconstrained for any company with more than a handful of employees.
Group proliferation and the naming convention problem
Security group proliferation compounds over time because creating a new group is always the path of least resistance compared to reviewing whether an existing group already covers the need. A tenant five years post-go-live commonly has two to three times as many security groups as it functionally needs, many of them near-duplicates created for a single project, a single reorg, or a single manager's specific request that was never revisited once the underlying need expired. Without a naming convention that encodes purpose and creation context (e.g. a required prefix indicating the requesting department and a mandatory 'review by' date field in a companion tracking sheet), these groups become impossible to distinguish from ones that are actually load-bearing in production processes.
A practical remediation programme starts by identifying every security group with zero or near-zero active members, flagging those as deactivation candidates, then moving to groups with overlapping permissions to near-identical domains and consolidating them into a single group with clear ownership. This is tedious work but it is also the single highest-leverage activity for reducing both audit fee and breach surface simultaneously, because PwC's own analysis ties security administration cost directly to the number of active groups an admin team has to reason about.
Handling contractor and temporary worker access
Contractor and contingent worker populations are disproportionately represented in stale security group membership because their engagements end on project timelines rather than HR-managed termination dates, and the offboarding trigger that deactivates an employee's Workday account on termination does not always fire the same way for a contractor whose engagement simply lapses without a formal termination transaction. A contractor who was granted temporary elevated access for a specific project — say, read access to a compensation benchmarking report for a one-off exercise — routinely retains that access long after the project ends because nobody owns the removal step.
Build a specific quarterly check for security group membership held by worker types other than regular employee, cross-referenced against contract end dates where available, and treat any contractor with access to a sensitive domain more than 30 days past their engagement's stated end date as an automatic high-priority finding.
Integrating findings into a remediation tracking system
A security group audit that produces a spreadsheet of findings and stops there does not move the needle unless someone owns closing each item. Feed every finding into whatever ticketing or GRC (governance, risk, compliance) tool your organisation already uses, with a named owner, a due date, and a severity rating tied to the actual risk (compensation domain exposure ranks higher than a stale group with view-only access to job requisition data, for instance). Re-run the comparison scan on a fixed cadence — monthly for high-severity domains, quarterly for the full population — and track closure rate as a metric that HRIS leadership reports up to the audit committee alongside other control effectiveness measures. Organisations that treat this as a one-time clean-up rather than an ongoing programme find the same categories of finding reappearing at the next audit cycle, because the underlying process that created the sprawl (ad hoc group creation, incomplete offboarding, template-copied domain policies) was never fixed — only its symptoms were.
Auditing report-level security independently of transactional security
Security group audits frequently focus on transactional access — who can view, modify, or approve a given business process — while overlooking report-level security, which is governed by a partially overlapping but distinct set of rules. A custom report can be configured with its own security tagging that grants visibility to a security group even when that group has no direct domain access to the underlying data through any transactional path, effectively creating a back door around otherwise well-configured domain security. This is a particularly common gap because report security is often configured by the report author, who may not be the same person or team responsible for the tenant's overall security architecture, and who may not be thinking about domain-level implications when they add a security group to a report's access list simply to make a colleague's request work.
A full audit needs to enumerate every custom report with access to sensitive data categories and cross-reference its security group access list against the domain security policy for the same data, flagging any report that grants broader visibility than the underlying domain would otherwise allow through standard transactional access.
Emergency access and break-glass account governance
Most tenants maintain at least one emergency or 'break-glass' account with elevated access intended for use only during a genuine incident when normal access provisioning would be too slow — a payroll processing failure at month-end, for instance, that requires immediate elevated access to correct before a filing deadline. These accounts are, by design, more broadly permissioned than any standard role, which makes their governance disproportionately important relative to how rarely they should actually be used. Audit findings in this category typically include break-glass accounts with no expiry or automatic deactivation after use, no mandatory post-use review requiring documentation of why the elevated access was invoked, and credentials that have not been rotated since the account was created, sometimes years earlier.
A properly governed break-glass process requires the account to be normally disabled, activated only through a documented approval step (even an expedited one, given the emergency nature), automatically time-boxed to deactivate after a defined window, and followed by a mandatory review logged against the incident that triggered its use. Any tenant unable to produce a log of every break-glass activation and its corresponding review has a governance gap that auditors flag as a significant deficiency, not a minor finding, given the scope of access these accounts typically carry.
Frequently asked questions
How often should security groups be reviewed once cleaned up?
Quarterly for domains touching compensation, payroll, and benefits; semi-annually for lower-sensitivity domains, plus an ad hoc check after any major reorganisation.
Can role-based security groups also be misconfigured, or is the risk limited to user-based groups?
Role-based groups can still be misconfigured through incorrect domain policy assignment or missing organisational constraints, though they avoid the membership-drift problem that plagues user-based groups.
What is the fastest way to find unconstrained groups on sensitive domains?
Export 'View Domain' for each sensitive functional area and cross-reference the constrained security groups list against the group's actual configuration; any listed as unconstrained on a sensitive domain is an immediate flag.
Does consolidating security groups risk breaking existing business processes that reference them by name?
Yes, which is why consolidation should be tested in Preview and any BP routing or condition rule referencing the old group name updated before deactivation, not after.
Does report-level security need to be audited separately from domain security?
Yes — report security tags can grant visibility independent of transactional domain access, so both layers require separate review to close the full gap.
How often should break-glass account activations be reviewed?
Every single activation should trigger a mandatory documented review, not a periodic sample review, given the elevated access these accounts carry by design.
Continue reading
Find out what's broken in your tenant
Free first scan. Read-only access. Results in under 2 hours.
Start Your Free Scan