Why Traditional SoD Controls Miss Modern Access Risk

Most organizations already have Separation of Duties (SoD) controls in place. They run access reviews, test financial controls, and maintain risk rulesets for critical systems. Cross-application SoD exposes a gap those programs often miss: risk that forms between applications.

A user may appear compliant in SAP, Salesforce, Coupa, or Workday individually, yet have conflicting access across systems. SoD remains useful, but the business process has moved beyond a single ERP. Finance, procurement, HR, SaaS, cloud, API, automation, and AI-driven workflows now connect across multiple control points. Governance has to follow that full process, not stop at the boundary of each application.

Key findings

• Modern business processes now span ERP, SaaS, cloud platforms, APIs, automation, and AI-driven workflows, making application-centric SoD no longer enough on its own.
• A user can pass every individual access review and still hold a dangerous combination of permissions across systems.
• Cross-application SoD depends on complete visibility across human users, service accounts, API integrations, AI agents, and the entitlements that connect them.
• This requires fine-grained entitlement visibility across connected applications rather than the coarse, application-level visibility provided by many traditional governance tools.
• Modern Application Access Governance provides the visibility, entitlement context, continuous analysis, and remediation workflows needed to evaluate access as one connected risk picture, not a set of isolated application checks.
• By continuously identifying, assigning, and remediating cross-application risk, organizations can strengthen fraud prevention, improve audit readiness, and reduce operational risk.

Cross-application SoD definition block

Cross-application SoD identifies conflicting access across multiple systems involved in the same business process. Traditional SoD checks whether a single user has conflicting access within a single application. Cross-application SoD looks across connected systems to identify risky access patterns, such as a user who can create a vendor on one platform and approve payment in another. The same issue can appear outside finance, such as when one identity can modify employee records in Workday and process payroll in a separate payroll system.

Why SoD still matters — and where the risk has moved

Missed cross-system access risks can lead to fraud exposure, audit findings, and control failures. For organizations subject to the Sarbanes-Oxley Act (SOX), financial controls depend on knowing who can initiate, approve, modify, or conceal activity across critical business processes.

The Association of Certified Fraud Examiners found that occupational fraud cases caused a median loss of $145,000. Financial access controls need to reflect how work actually happens, especially when transactions move across systems. When access is reviewed system by system, organizations may miss the combined permissions that make fraud risk harder to detect before financial loss, control failure, or audit findings occur.

SoD remains one of the most important controls for preventing a single user from holding conflicting responsibilities. Many programs, however, were built around ERP-centric environments, where the highest-risk activity typically occurred within a single core system.

Enterprise workflows have outgrown that model. Finance may run through SAP or Oracle, while procurement sits in Coupa, customer data lives in Salesforce, HR data sits in Workday, approvals move through SaaS workflows, and integrations connect cloud services and APIs. Each system may be governed independently, with different security role models. But the business process moves across all of them.

When access risk spans that many systems, governance needs to be business-process-centric, not application-centric. SoD still needs to follow the identity, but it also needs to follow the full path of the transaction across the systems, roles, integrations, and approvals that support it. Otherwise, the organization may have strong individual controls and still miss the combination that creates real financial risk.

Why single-application controls miss the biggest risks

Single-application controls can only evaluate the access they can observe, leaving a structural gap. SAP may know what a user can do inside SAP. Coupa may know what that same user can do inside Coupa. Salesforce, Workday, and a banking platform may each apply their own access rules. But none of those systems can see the full pattern across the business process.

The risk appears only when those permissions are viewed collectively across the systems that support the business process. A user may have compliant access to maintain vendor records on one platform and to approve or release payments on another. Each permission may make sense on its own, but the combined access gives one user too much control over the transaction.

For example:

Vendor maintenance access in System A + payment approval access in System B = cross-application SoD risk.

Periodic certifications help teams review whether access still makes sense at a given point in time. But they are strongest when they are supported by continuous governance across systems, especially as roles change, new applications connect to core processes, and non-human identities move data between platforms.

Cross-application SoD closes that gap by evaluating access across the systems where the business process actually runs. That starts with visibility across the identities, entitlements, applications, and integrations that support the process, so teams can see the full access pattern before they certify, remediate, or document risk.

Key risks of cross-application access gaps

Cross-application access gaps create a risk of application access governance fraud by hiding conflicting access across systems, identities, and ownership models. Risk often appears when separate permissions combine across the business process, even if each individual permission looks reasonable.

Phantom compliance

A user can pass every individual system review and still retain access that poses a fraud risk. SAP, Coupa, Salesforce, and Workday may each show a completed review with no obvious violation. But if those reviews happen in isolation, the audit trail only proves that each application was checked. It does not prove that the full access pattern was safe.

Toxic combinations through platform seams

Risk often appears where one system hands work to another. One application owner may approve access to create or modify vendors. Another may approve access to release payments. Each decision may be reasonable on its own, but together they give one identity too much control over a sensitive process.

NHI and API drift

Service accounts, API integrations, bots, automation accounts, and AI agents can accumulate cross-system privileges over time. These identities often move data between applications, trigger workflows, or support integrations, but they may not have the same ownership, review, and retirement discipline as human users. That makes them easy to overlook in SoD programs built around employee access.

Audit exposure from fragmented controls

Auditors may ask whether controls cover the entire financial process, not just one application. When teams can only show system-by-system evidence, cross-application gaps can become findings that require remediation, retesting, and explanation to leadership.

Delayed detection

Fragmented logs and access reviews make it harder to connect suspicious patterns. The longer teams take to connect activity across systems, the more expensive investigations become, especially when valid credentials make suspicious activity look routine. Activity can appear legitimate in each system because the identity has valid access. Without cross-system correlation, teams may not see the pattern until after a control failure, audit issue, or fraud investigation.

Cross-application SoD vs. traditional SoD: what’s different?

Traditional SoD and cross-application SoD share the same goal: preventing one identity from holding access that creates fraud, compliance, or control risk. The difference is where the control looks. Traditional SoD evaluates conflicts inside one system. Cross-application SoD evaluates risk across the connected applications, cloud systems, APIs, and identities that support the full business process.

How to build cross-application SoD into your access governance program

Cross-application SoD starts with evaluating access across the applications, identities, entitlements, and integrations involved in the full business process. From there, teams can evaluate access in context, define rules tied to real business risk, and create a path from detection to remediation.

• Map entitlements across connected systems.

Start with the processes where access risk has the highest impact, such as finance, procurement, HR, payroll, and vendor management. Then map the systems, identities, and integrations involved in those processes. That should include ERP and SaaS applications, cloud platforms, APIs, service accounts, and other integrations that move data or trigger transactions.

• Define rules around business risk.

Cross-application SoD rules should reflect real access risk, not just application roles. Prioritize access patterns tied to money movement, sensitive data, and financial reporting, such as vendor maintenance and payment approval, or employee record changes and payroll access.

• Evaluate combinations continuously.

Access risk changes as users move roles, applications are added, integrations change, and new workflows are introduced. Quarterly certifications still matter, but they should not be the only control. Evaluate combinations when access changes, rather than waiting for the next scheduled review.

• Assign ownership and remediation workflows.

Every violation needs a named owner, enough reviewer context to understand the risk, and a clear remediation path. Reviewers should be able to see the systems involved, the conflicting entitlements, the business process affected, and the reason the access pattern creates risk. In some cases, remediation means removing access. In others, it may mean documenting an approved exception, adding a compensating control, or changing how responsibilities are split across teams.

• Extend scope to non-human identities.

Service accounts, API integrations, bots, and AI agents can all hold cross-system access. They need the same governance discipline as human users: ownership, purpose, credential oversight, access-path visibility, and retirement when they are no longer needed.

• Connect findings to access certification.

Cross-application violations should appear inside the workflows where reviewers already make access decisions. A separate report may identify risk, but it rarely drives action on its own. SoD findings should become reviewable, owned, and remediated access decisions.

Common mistakes when implementing cross-application SoD

Cross-application SoD programs often fall short when teams treat them as a one-time rule-building exercise. Applications change, roles change, integrations expand, and new identities enter the process. The control model needs to change with them.

Scoping rules once and leaving them unchanged

Many teams define SoD rules during implementation and revisit them only when an audit issue appears. That creates drift. New applications, reorganizations, acquisitions, workflow changes, and role redesigns can all create new access conflicts. SoD rules need regular review and tuning so they reflect how the business actually operates.

Treating ERP and SaaS governance separately

ERP teams, SaaS owners, and IAM, security, and compliance teams may each govern their own environments well. Cross-application risk forms between those environments. If no one owns the full business process, no one sees the full access pattern. Cross-application SoD needs shared ownership across the systems that support the process.

Relying on certification alone

Access certifications are necessary, but they are point-in-time controls. They are also only as useful as the visibility behind them. If reviewers can only see access inside individual systems, they may certify permissions without understanding the cross-application combinations that create risk across the full business process. Certifications should be supported by continuous visibility, so teams can detect risky access created by role changes, emergency access grants, new integrations, or application updates faster than quarterly reviews can provide.

Excluding service accounts and integrations

Service accounts, API integrations, bots, AI agents, and other non-human identities often hold broad, persistent access across systems. If they are excluded from the SoD scope, the program only governs part of the risk. Every identity that can touch a sensitive business process must be assigned ownership, reviewed, and controlled.

How Saviynt handles cross-application SoD

Consider a common enterprise scenario: a user has access in one system to create or modify vendor records, and access in another to approve or release payments. Each application owner may have approved their part of the access. Each system may pass its own review. The combined access can still give one user too much control over a sensitive transaction, even when single-system controls pass.

Saviynt helps close that gap by bringing entitlement visibility, SoD policy evaluation, risk prioritization, access certification, and remediation into one governance workflow. Instead of reviewing SAP, Oracle, Workday, Salesforce, SaaS applications, cloud systems, and integrations as separate control environments, teams can evaluate access across the applications that support the full business process. That includes understanding how human users, service accounts, API integrations, non-human identities, and AI agents relate to each other across connected workflows, even when identities appear differently from one system to another.

With Saviynt Application Access Governance, organizations can use fine-grained visibility, automated SoD detection, prebuilt rulesets, access certifications, remediation workflows, and audit-ready reporting into one connected governance model. That model helps teams evaluate access across the full business process and across every identity involved, including employees, service accounts, API integrations, non-human identities, and AI agents. Cross-application SoD becomes one outcome of that broader approach: risk is identified, assigned, reviewed, remediated, and documented instead of remaining buried in separate application reports.

To see how this applies to SOX control gaps across SAP environments, watch the SAP Insider webinar “Modern Identity Management for SOX."

Frequently asked questions