Workday ISU Over-Access: The Security Gap in Every SOX Audit

1. What ISUs are

Dedicated service accounts (robot accounts) that run Workday integrations. They authenticate via web service API calls. Each ISU is associated with an ISSG (Integration System Security Group) that grants domain-level permissions for the data the integration reads or writes.

2. The implementation shortcut

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 minimum permissions under deadline pressure. Five years later, the integration only reads 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.

3. Why this is a SOX §404 finding every time

SOX ITGC logical access controls require service accounts to have minimum access necessary — least privilege. An ISU with 'All HCM Data' access fails this test immediately. The auditor will flag it as a material-weakness candidate the moment the ISU has access to payroll or compensation domains it does not use.

4. The UI login vulnerability

If an ISU does not have 'Do Not Allow UI Sessions' checked, anyone with the credentials can log into the Workday UI directly. No MFA. No SSO. Full access to everything the ISU's ISSG permits — which in most tenants is everything.

5. Right-sizing ISU permissions

Identify the minimum domain set per integration: start with what the integration actually reads/writes; pull Workday's integration audit log to see which domains were accessed in the last 90 days; remove everything else. Test the reduction in Preview before making production changes. Document the before/after in the SOX Risk Control Matrix.

Continue reading

• Workday Security Group Misconfigurations
• Workday and SOX §404
• Failing Workday Integrations
• Find every over-privileged ISU