Yoetz.ai Team May 14, 2026 9 min read

Workday SOX Audit Prep: The 12 Controls Auditors Always Check

Every SOX audit of a Workday tenant tests the same 12 ITGC controls. The difference between a clean audit and a finding is having the evidence ready in the format the auditor expects. Here is each control, the test procedure, and the exact Workday report that satisfies it.

Abstract visualisation of layered audit evidence and control checks
Compliance

Control C1 — User access provisioning

Evidence: 'New Hire' BP completion records for a sample of joiners; 'View Worker Security Profile' for each. Auditor verifies access was granted within policy and matched to role.

Control C2 — Deprovisioning

Evidence: termination date vs. account deactivation timestamp from 'View Worker' for terminated sample. The #1 finding when these don't match within 24 hours.

Control C3 — Privileged access review

Evidence: quarterly attestation of HR Admin, System Admin, and Security Admin group membership. Run 'View Members of Security Group' for each and have the data owner sign off.

Control C4 — ISU access scope

Evidence: 'View Integration System User' for every ISU plus the ISSG domain list. Documented business justification per integration.

Abstract visualisation of sequential release readiness gates
Abstract visualisation of sequential release readiness gates

Control C5 — ISU UI session restriction

Evidence: every ISU shows 'Do Not Allow UI Sessions' = checked.

Control C6 — Integration monitoring

Evidence: 'View Integration System' showing alert subscribers configured; 'Integration Audit' showing failed-run response.

Controls C7–C12

  • C7 — Change management: Preview promotion records and change approval tickets.
  • C8 — SoD: 'Compare Security Permissions' across conflicting groups.
  • C9 — Password & ISU credential rotation log.
  • C10 — BP security: 'Business Process View' for material transaction types.
  • C11 — Calculated field validation: 'All Calculated Fields' filtered Has Errors = No.
  • C12 — SOC 2 review: Workday's SOC 1 Type II + complementary user entity controls.

How to bundle all 12 in one evidence package

Run a Yoetz.ai scan. The export contains one row per control, the test procedure, the Workday source, and the result. Hand it to the auditor on day one of fieldwork.

Preparing the evidence package before the auditor arrives

The difference between a smooth SOX walkthrough and a multi-week finding remediation cycle usually comes down to timing: evidence gathered in the days before fieldwork begins is almost always incomplete, because some of the required reports (privileged access attestations, quarterly access reviews) are point-in-time artefacts that cannot be recreated retroactively if they were not captured when due. Build a standing evidence calendar tied to each of the 12 controls, with monthly or quarterly capture dates that are independent of the audit schedule. When the auditor requests evidence for Control C3 (privileged access review), you should be retrieving an already-completed quarterly attestation from your evidence archive, not scrambling to run the review for the first time during fieldwork — the latter pattern is itself often flagged as a control deficiency, since it suggests the control was not actually operating throughout the period under review.

Common findings and how to pre-empt them

  • Deactivation lag beyond 24 hours (Control C2) — the single most frequent SOX finding in Workday tenants; fix by automating termination-to-deactivation via a BP-triggered integration rather than relying on manual follow-up.
  • ISUs with UI sessions still enabled (Control C5) — often introduced years earlier for a one-time manual task and never reverted; run a full ISU audit before every fieldwork period, not just at initial control design.
  • Stale privileged group membership (Control C3) — former project team members retaining Security Administrator access long after their project ended; tie group membership reviews to HR transfer and termination events, not just a calendar cadence.
  • Calculated fields with unresolved errors (Control C11) — frequently accumulate silently since they only surface when someone happens to use the affected field; schedule a standing quarterly 'Has Errors' report review independent of the audit cycle.
  • Missing SoD documentation for newly created security groups (Control C8) — new groups created mid-year for a specific project often bypass the SoD review process that applied at initial control design; require SoD sign-off as a mandatory step in the new security group creation workflow itself.

Coordinating ITGC testing across a multi-tenant or M&A environment

Organisations running multiple Workday tenants — due to acquisitions, regional deployments, or historical carve-outs — face a materially harder SOX evidence challenge, because each of the 12 controls must be tested and evidenced separately per tenant unless the tenants have been formally consolidated. Auditors will not accept evidence from one tenant as a proxy for another even if the configuration is nominally similar, since ITGC testing is tenant-specific by design. Build a control matrix that tracks evidence completeness per tenant per control, and flag any newly acquired tenant that has not yet had a full SOX control baseline established — this is a common gap in the first audit cycle following an acquisition and a frequent source of scope surprises during fieldwork.

Working with external auditors on sampling methodology

Auditors typically test a sample of transactions or user accounts per control rather than the full population, and the sample size and selection methodology can materially affect how much evidence you need to prepare. Engage with the audit team early in the planning phase to understand their sampling approach — some firms use attribute sampling with a fixed sample size regardless of population, while others scale sample size to population size. Understanding this in advance lets you pre-stage evidence for the likely sample population rather than preparing evidence reactively once the sample is selected, which can compress your evidence-gathering timeline significantly during the fieldwork window.

Handling control exceptions when they are found

Even a well-prepared programme will occasionally surface a genuine control exception during testing — a deactivation that took 30 hours instead of 24, an ISU that briefly had UI sessions enabled during a troubleshooting exercise. The auditor's response to an exception depends heavily on how it is handled: a documented root cause, a specific remediation action already taken, and evidence the exception was isolated rather than systemic will typically result in a minor observation rather than a material weakness finding. Build a standing exception-response playbook before fieldwork begins so that when (not if) an exception surfaces, your team has a rehearsed process for investigating and documenting it rather than reacting for the first time under audit pressure.

Automating evidence collection as a permanent operating model

Manual evidence collection for 12 controls across a full fiscal year is a substantial recurring burden on the HRIS and security teams, typically consuming several weeks of effort per audit cycle when done manually via individual report runs and spreadsheet compilation. An automated scanning approach that captures evidence continuously — rather than reconstructing it at audit time — converts SOX evidence gathering from a periodic fire drill into a background operating process. This has a secondary benefit beyond audit efficiency: because the same evidence surfaces control gaps in near real time rather than at year-end, remediation happens throughout the year rather than being discovered as a finding during the audit itself.

Integrating SOX control evidence with a broader AI readiness scan

Many of the same configuration checks that support SOX ITGC evidence — security group scoping, business process routing health, calculated field validity — overlap significantly with the readiness checks required before activating an AI agent like Workday Illuminate. Organisations running both a SOX compliance programme and an AI activation project separately often duplicate effort, running two similar but not identical scans of the same underlying configuration surface with two different teams and two different findings formats. Coordinating these programmes, even informally, so that a single scan produces evidence usable for both purposes, reduces duplicate effort and ensures a configuration fix made for one purpose is not silently missed by the other programme's tracking.

Board and audit committee reporting on ITGC health between formal audits

Audit committees increasingly expect visibility into ITGC health between the annual audit cycle, not just at year-end when the formal opinion is delivered. Providing a quarterly summary of control status — deactivation timeliness trends, privileged access review completion, exception counts and their resolution status — gives the audit committee early visibility into emerging risk and demonstrates that the control environment is actively managed rather than assessed once a year. This reporting is also valuable internally: it creates a forcing function for the HRIS and security teams to review control health on a cadence independent of the audit calendar, catching issues while they are still easy and inexpensive to fix.

Handling SOX scope changes after a Workday configuration change

A significant configuration change — a new business process affecting a financially material transaction type, a new integration touching payroll data, a reorganisation of security groups — can change the scope of what needs to be tested under SOX, and this scope change is easy to miss if change management and SOX control ownership sit in different teams that do not routinely coordinate. Build a lightweight review step into your Workday change management process specifically asking whether a proposed change affects any of the 12 SOX-relevant control areas, and route any change that does to the SOX control owner for a scope assessment before the change is promoted to production, not after the fact during the next audit cycle.

Lessons from first-year Workday SOX control failures

  • First-year Workday customers frequently under-scope control C2 (deactivation timeliness) because the automated termination-to-deactivation integration was not fully tested under real termination volume before go-live.
  • New implementations often carry over security groups designed for the implementation partner's project team without a formal decommissioning step once the project ends, creating an immediate C3 finding in the first audit cycle.
  • Calculated fields built rapidly during implementation to meet a go-live date are a common source of first-year C11 findings, since validation of edge-case behaviour is often deprioritised under go-live time pressure.
  • Organisations moving from a legacy on-premise HR system frequently underestimate how much manual, undocumented control activity the legacy system's IT team performed informally, and fail to replicate an equivalent control discipline in the new Workday environment from day one.

Preparing management's own testing and self-assessment before external fieldwork

A mature SOX programme does not wait for the external auditor to discover control gaps — management performs its own interim testing throughout the year, using the same control matrix and largely the same evidence standards the external auditor will apply. This management self-assessment, sometimes formalised as management testing of controls (MTOC), catches and remediates gaps months before fieldwork, meaning the external audit becomes a validation exercise rather than a discovery exercise. Organisations that skip interim self-testing and rely solely on the annual external audit to surface issues are, in effect, choosing to discover their control failures at the worst possible time — during the audit itself, under time pressure, with limited ability to remediate before the finding is formally recorded.

Frequently asked questions

How far in advance of fieldwork should we start preparing SOX evidence?

Evidence capture for controls like privileged access review and quarterly attestations should happen throughout the fiscal year on a standing cadence, not compiled in advance of fieldwork. Start a dedicated evidence compilation and gap-check exercise at least 4–6 weeks before fieldwork begins to catch and remediate any missing evidence.

What happens if a control exception is found — does it automatically become a material weakness?

Not automatically. Auditors assess severity based on whether the exception is isolated or systemic, whether compensating controls existed, and whether it was identified and remediated by management before or during the audit. A well-documented, isolated exception with prompt remediation is typically classified as a minor deficiency rather than a material weakness.

Do all 12 controls apply equally to every Workday module?

The core access and change management controls (C1–C8) apply platform-wide. Controls like C10 (BP security) and C11 (calculated field validation) are weighted toward whichever modules process material financial transactions — typically Payroll, Compensation, and Absence — and should be scoped to those modules specifically during control design.

Can an automated scan replace the auditor's independent testing?

No — an automated scan is an internal control and evidence-generation tool that dramatically improves preparation and reduces findings, but external auditors are required to perform their own independent testing procedures regardless of what internal tooling produced the evidence.

Should SOX evidence collection be coordinated with AI readiness scanning?

Yes, where possible — security group scoping, business process routing, and calculated field validity checks overlap substantially between the two programmes. Coordinating them avoids duplicate scans of the same configuration surface by two separate teams using different findings formats.

Why do first-year Workday customers see more SOX findings than mature tenants?

Go-live time pressure typically deprioritises full testing of automated deactivation flows, decommissioning of implementation partner security groups, and edge-case validation of newly built calculated fields — all common sources of first-year findings that a mature tenant has usually already remediated.

Continue reading

Get the next HR tenant health briefing

Monthly. No spam. Unsubscribe with one click.

Find out what's broken in your tenant

Free first scan. Read-only access. Results in under 2 hours.

Start Your Free Scan

Related posts