Fortune 500 financial services and insurance company
Ran SafePaaS across an estate whose key systems in scope included Oracle ERP, Okta, Workday and SailPoint.
Key systems in scope Oracle ERP Okta Workday SailPoint Read the case studyTry segregation of duties, SailPoint, or Oracle ERP Cloud access review.
Workday coverage Federated identity governance
Workday access governance
SafePaaS governs segregation of duties, privileged access and configuration change inside Workday — reading Tenant Level, Organization Level, Position, Security Groups and Roles and Security Policies, and testing policy against them.
Inside Workday, not beside it — the same rule book that governs every other system you run.
Organization Level read as Workday defines it, down to the security policies Every snapshot re-tested in full, so a conflict reintroduced since the last one surfaces Across your estate Workday and every other system assessed together, so a duty held here and a duty held elsewhere meet One rule book applied across every system in the process, not one tool per application
Coverage at a glance
What SafePaaS reads, controls and monitors in Workday
| Area | Reads | Controls | Monitors |
|---|---|---|---|
| Access and segregation of duties | Tenant Level, Organization Level, Position, Security Groups and Roles and Security Policies, and who holds each one | SoD rules at the level of the entitlement itself; request-time prevention; simulation of a role change before it is applied; emergency access with a reason and an expiry | New conflicts introduced by an entitlement change, expired assignments, and standing privilege nobody reviews |
| Audit, risk and compliance | Control test results, exceptions, approvals and the versioned Workday rule set | One Workday control mapped to SOX, ITGC and internal policy; exceptions with an owner and an expiry | Test status against each Workday control, and exceptions approaching expiry |
| Identity 360 — NHI and AI agents | Human users, service and integration accounts, and the AI agents acting on a user’s behalf | The same SoD policy applied to non-human identities and AI agents as to people | Standing authorization held by unattended integrations, and what each non-human identity can actually do |
The entitlement model we read
A Workday user’s authority is five layers below the role name
SafePaaS reads the Workday security model as Workday defines it: tenant level, organization level, position, security groups and roles, security policies. Each layer is resolved, not assumed.
Only the deepest layers say what a user can actually do, and where. Everything above them is a container.
- Layer 1 Tenant Level
- Layer 2 Organization Level
- Layer 3 Position
- Layer 4 Security Groups and Roles
- Layer 5 Security Policies Domain policies for data, Business Process policies for participation in workflows
A container in this chain can be widened while keeping the name an access review sees, and the deepest layer differs with every assignment. That is why SafePaaS tests the authority a user actually resolves to, not the label attached to it.
What we detect here
Risks stated the way an auditor would raise them.
Four of many. The SafePaaS Workday rule set carries 813 distinct entries in its HCM set alone, plus a separate financials set, and every one of them is tested against your snapshot. Each is a combination the role name will not reveal — which is why it survives an access review and surfaces in an audit.
Example 01
A payment made and then reconciled by the same identity
Bill (Invoice) Payment held with Bank Account Reconciliation, from the SafePaaS Workday financials rule set. The control that would catch the payment is operated by whoever made it.
Example 02
An asset record maintained by whoever sets its depreciation
Assets Workbench held with Assets Depreciation — the carrying value and the schedule that writes it down, in one pair of hands.
Example 03
An asset acquired and recorded by the same identity
Assets Workbench held with Create Purchase Order or Purchase Requisition, spanning procurement and fixed assets.
Example 04
Someone who can change who is paid, and then run the payroll
Maintain Employee Master Data held with Process Payroll, from the Workday HCM rule set. Maintain Time Data and Maintain Payroll Configuration carry the same collision.
Coverage in detail
How each area works in Workday
How does SafePaaS enforce segregation of duties in Workday?
SafePaaS Enterprise Access Monitor tests SoD rules against an ERP Snapshot of your Workday security model — tenant level, organization level, position, security groups and roles, security policies — rather than against the live system, so a test is repeatable and a result is defensible.
Modules Enterprise Access Monitor Enterprise iAccess Enterprise Roles Manager ▸ Defines rules at the level of the entitlements themselves, not just the user list, so a conflict is found where it actually lives ▸ False-positive filters remove inactive users, expired assignments and end-dated roles before anyone reviews a result ▸ Detects conflicts that span Workday and the rest of your estate, so a duty held in one system and a duty held in another are assessed together rather than separately ▸ Enterprise Roles Manager simulates a role change before it is applied, so a change does not reintroduce the violation you just remediated ▸ Violations carry status — Open, Closed, Remediation, Exception — with workflow, reminders and ITSM ticketing ▸ Mitigation records the compensating control and its evidence where a conflict cannot be removed ▸ Emergency access is granted with a stated reason, a time box, and a log of everything done while elevated
What evidence does SafePaaS produce for a Workday audit?
SafePaaS ARCPaaS turns Workday control activity into the evidence an auditor asks for — the rule, the test, the result, the exception and its approval — without anyone assembling a spreadsheet.
Modules ARCPaaS ▸ Audit Manager holds the test, its result and its evidence against each Workday control, with the date and the approver ▸ Risk Manager ties a Workday access risk to the business process it threatens, so the finding is stated in a language the process owner recognises ▸ Compliance Manager maps one Workday control to every framework that claims it — SOX, ITGC, and internal policy — so it is tested once and reported many times ▸ Rules Repository keeps the Workday rule set versioned, so a change to a rule is itself auditable ▸ Exceptions carry a stated business reason, an owner and an expiry, not a permanent waiver
Who governs the Workday accounts that are not people?
SafePaaS Identity 360 — SafeInsight and SafeIQ — covers every identity with access to Workday, including the integration accounts, batch users and AI agents that no joiner-mover-leaver process was ever built to review.
Modules SafeInsightSafeIQ ▸ Inventories service and integration accounts alongside human users, so a privileged unattended account is visible rather than assumed ▸ Shows what each non-human identity can actually do in Workday, not what its description claims ▸ Flags standing privilege held by integrations that run unattended ▸ Extends the same SoD policy to AI agents acting on a user’s behalf, so an agent cannot complete a conflicting pair a human would be stopped from completing
Connection
How does SafePaaS connect to Workday?
SafePaaS extracts through the platform’s own service interfaces — SOAP per security object, REST for transactions, or a direct database connection where the platform is not cloud-hosted.
Inside Workday → SafePaaS extraction SOAP services per security object returning XML; REST endpoints returning JSON for occurrences; a direct database connection where the platform runs on-premise.
Transfer → DataProbe The collected data is pushed out to SafePaaS through DataProbe.
Normalize → DataPaaS The transformation layer. Normalizes the data where required so one rule book can test it.
Result ERP Snapshot The point-in-time copy every module tests against — SoD, monitoring, certification and audit evidence alike.
What is read Tenant Level, Organization Level, Position, Security Groups and Roles and Security Policies How data moves Everything collected lands in the FSOD_* open interface tables, and DataPaaS normalizes it from there First snapshot A baseline of every user, role and entitlement assignment, and the first SoD test result set against your own rule book Protection Traffic terminates behind a WAF and an API gateway; the snapshot is tenant-isolated at rest
What runs inside Workday Nothing Extraction runs through the platform’s own service interfaces, so no SafePaaS component is deployed into it.
Because every governance module tests the snapshot rather than the live system, the same rule book applies to Workday and to every other system in the same business process.
Coexistence
Does SafePaaS replace SailPoint, Entra ID or my existing IGA?
No — and that is the point of federated identity governance. What your identity platform cannot see is what a role permits once the user is inside Workday, because that answer lives five layers down in the security model Workday publishes.
Your identity platform owns
The account
Joiners, movers and leavers Birthright access The request workflow Provisioning a user into Workday, and recording that they hold a role SafePaaS owns
What the role permits
The entitlement behind the role name SoD across Workday and the rest of the estate Configuration and transaction change inside Workday Findings handed back to your IGASo a certification in your IGA reflects the entitlement rather than the role name, and an access request is checked for SoD before it is approved.
Proof
FAQs
What Workday teams ask first.
The security model as Workday defines it: tenant level, organization level, position, security groups and roles, security policies. SafePaaS resolves the chain rather than recording the role name, because the role name is a container and the permission lives below it.
Go deeper on business application governance
Next step
See how SafePaaS governs a Workday estate
A working walkthrough against a demo environment, with a specialist who can map what you see onto the roles, organisation structure and audit pressure you actually have.
What the walkthrough covers How the entitlement chain is read as Workday defines it — tenant level, organization level, position, security groups and roles, security policies An SoD conflict traced from the rule to the entitlements that create it How a role change is simulated before it reintroduces a remediated conflict Where SafePaaS sits relative to the IGA and GRC tooling you already run