Workday Separation of Duties (SoD): The 2026 Audit Guide

What Separation of Duties means in Workday

SoD in Workday is not a single switch. It's the combined effect of three layers: which Security Groups a worker belongs to, what those groups can do (Domain Security Policies — Get/Put/Modify), and what those groups can approve (Business Process Security Policies — Initiate/Approve/Review). A real SoD conflict is when one worker (directly or through a Role-Based group) holds two policy permissions that should never sit in the same pair of hands.

The conflicts auditors test most often

In HCM: Hire + Approve Hire, Compensation Change + Approve Compensation, Add Job + Assign Pay Group. In Payroll: Maintain Pay Component + Run Pay Calculation, Enter One-Time Payment + Approve One-Time Payment, Maintain Payroll Input + Settle Payroll. In Financials: Create Supplier + Approve Supplier Invoice, Initiate Journal + Approve Journal, Maintain Bank Account + Settle Payment. In Security itself: Assign Security Group + Approve Security Group Assignment (the conflict that lets one person silently expand their own access).

Why manual SoD reviews miss most conflicts

Manual reviews export Security Group membership and Domain Security Policy assignments to spreadsheets, then VLOOKUP them against a static SoD matrix. The matrix rarely covers Business Process security (where Initiate/Approve conflicts actually live), almost never covers indirect assignment through Role-Based groups inherited from supervisory organizations, and is never re-run between quarterly audits. The result: real conflicts hide in the gap between the layers.

How an automated SoD scan works

An automated Workday security audit walks every Security Group, expands its members (including indirect role-based assignment), maps the group to every Domain Security Policy and Business Process Security Policy it touches, and intersects the result with the SoD matrix. Every conflict is returned with the worker name, the conflicting permission pair, the security groups that grant each side, and the remediation step (move one permission to a separate group, add a compensating approval, or constrain the role).

Compensating controls when full SoD isn't possible

In small HR or finance teams, one worker often has to hold both sides of a conflict. The audit-acceptable answer is a compensating control: a mandatory second-approver step on the Business Process, a downstream audit report owned by a different function, or a time-boxed elevated-access window with after-the-fact review. Yoetz.ai flags the conflict and the compensating control together so auditors can see both halves of the evidence.

SoD evidence auditors expect (SOX, ISO 27001, SOC 2)

SOX §404 ITGC, ISO 27001 A.5.3, and SOC 2 CC6.3 all require evidence that SoD is tested at a defined frequency — not just designed. Acceptable evidence is a timestamped report listing every conflict, the worker affected, the remediation status, and the date of the next test. Automation produces this artifact on every scan; manual reviews rarely do.

Getting started

Run a free Yoetz.ai scan against your Workday tenant. The security category returns the full SoD conflict list across HCM, Payroll, Financials and Security domains in under two hours, with remediation steps for every finding.

Why SoD conflicts accumulate even in well-governed tenants

SoD conflicts rarely enter a tenant through a single obviously bad decision. They accumulate through a series of individually reasonable actions taken over years: a temporary access grant during a system migration that was never revoked, a new Role-Based security group created for a reorganisation that inadvertently inherited broader Domain Security Policy access than intended, a Business Process Security Policy edited to unblock a specific approval bottleneck without checking who else that step now includes.

Each of these decisions made sense in isolation, at the time, to the person making it. None of them were reviewed against the full SoD matrix because that review would have required cross-referencing dozens of security groups and business processes that the decision-maker had no visibility into. This is the structural reason SoD conflicts are best caught by systematic, comprehensive scanning rather than by asking individual configuration owners to self-police — nobody has visibility into the full picture except a tool that reads the entire tenant at once.

The Assign Security Group + Approve Security Group Assignment conflict, in detail

This is arguably the highest-severity SoD conflict in any Workday tenant because it's self-referential: a worker who holds both permissions can grant themselves additional access and approve their own grant, with no independent check. It typically arises when a small IT Security or HRIS team is granted broad security administration rights for operational convenience, without splitting the initiate and approve steps of the Security Group Assignment business process across two distinct people.

The remediation is straightforward in principle — split initiation and approval across two people or groups — but politically difficult in small teams where there genuinely are only one or two people qualified to do security administration. In those cases, the acceptable compensating control is a mandatory, time-bound review by a third party (often an IT Security manager or internal audit) of every security group assignment made in the prior period, with evidence retained. Auditors will accept this compensating control if it's documented and consistently executed; they will not accept 'we trust this person' as a substitute for it.

SoD in the context of Role-Based versus User-Based security groups

Role-Based security groups grant access based on a worker's position in the org chart (e.g., 'Compensation Partner' for a given supervisory organisation), which means access changes automatically as people move roles — a strength for keeping access current, but a risk for SoD because access can silently expand when a reorganisation nests supervisory organisations differently than before. User-Based security groups grant access to named individuals directly, which is easier to reason about in isolation but tends to accumulate as a graveyard of grants nobody remembers to revoke when someone changes roles internally.

A comprehensive SoD scan must expand both types consistently: Role-Based groups need to be evaluated against the current org structure (not a snapshot from when the group was created), and User-Based groups need to be cross-checked against current worker status and role, not the role the worker held when the grant was made. Manual reviews that treat these two group types with the same static method — exporting membership once and comparing to a matrix — systematically understate Role-Based exposure because the underlying org structure keeps moving underneath the snapshot.

Building an SoD matrix that reflects your actual business, not a generic template

Generic SoD matrices published by consulting firms are a reasonable starting point but miss company-specific risk. A manufacturing company with a unionised workforce needs SoD rules reflecting CBA-mandated approval steps that don't exist in a generic template. A company operating in multiple countries needs country-specific payroll segregation rules — some jurisdictions have statutory requirements about who can initiate versus approve payroll changes that go beyond generic best practice.

The most effective approach is starting from a comprehensive generic library (covering the well-known HCM, Payroll, Financials and Security conflicts), then adding a company-specific layer built from actual incidents, internal audit findings, and legal/compliance requirements specific to the business. This second layer is where most of the real risk-reduction value sits, because it's the layer generic tools and generic AMS reviews are least likely to cover.

How SoD findings should flow into remediation, without creating organisational friction

A common failure mode when introducing systematic SoD scanning for the first time is generating a large initial backlog of findings — often several hundred at a mature enterprise tenant — and presenting the entire list to stakeholders at once. This overwhelms the team responsible for remediation and creates the perception that the SoD program is unmanageable, which undermines support for continuing it.

The better approach is triaging the initial backlog into three tiers before it goes anywhere near a steering committee: conflicts posing genuine financial or compliance risk that need remediation within 30 days, conflicts that are lower-risk but should be fixed within a quarter, and conflicts that are acceptable with a documented compensating control. Presenting the backlog pre-triaged, with a clear remediation timeline attached to each tier, converts an overwhelming list into a manageable project plan and builds credibility for making SoD scanning a permanent, recurring practice rather than a one-time clean-up exercise.

Frequently asked questions

Continue reading

• Workday security group audit
• Workday security group best practices
• Workday payroll audit guide
• Workday tenant health check