They miss toxic access combinations that emerge only when entitlements are evaluated across multiple systems. In practice, that means SoD conflicts, approval conflicts, and privileged-risk patterns can remain invisible until an audit or incident forces a manual reconstruction of evidence.
Why single-application GRC views miss the real control problem
GRC tools that evaluate one application in isolation can confirm local permissions while missing the cross-system combination that actually creates toxic access. The issue is not just missing data, it is missing the relationship between entitlements, so a user can look compliant in each system and still hold an unsafe end-to-end access path across the business process.
That matters most where access is assembled across ERP, HR, finance, procurement, and supporting workflow tools. A single app may show only a benign role, but the combined path can still let one person request, approve, and execute the same transaction, or hold conflicting duties that should never coexist.
Because of that, the right question is not whether each system has a valid role model, but whether the enterprise can evaluate the effective access chain across systems, business units, and approval steps. If the tool cannot correlate those pieces, it is measuring coverage, not control.
What breaks in SoD, approval, and privilege analysis
Segregation of duties fails first because SoD rules are usually defined at the business-process level, not the application level. One system may grant initiation rights, another may grant approval rights, and neither system on its own appears unsafe. The conflict only exists when the enterprise joins those entitlements into a single decision view.
Approval analysis breaks in the same way. A workflow owner may think approval is independent because the request and approval happen in different tools, but if both paths are controlled by the same individual, or by closely related roles, the approval becomes decorative rather than compensating. That is a governance failure even when every individual entitlement looks justified in isolation.
Privileged-risk analysis also degrades when tools cannot see shared administrative power across systems. A person may not have an obvious superuser role in any one platform, yet still hold enough combined access to alter records, bypass review, or hide activity. For practical control design, that is why enterprise access reviews need the combined entitlement picture, not just per-application attestations. Authoritative control guidance for access and least privilege is also reflected in ISO/IEC 27002:2022 Information Security Controls and NIST SP 800-53 Rev 5 Security and Privacy Controls.
How to rebuild visibility across applications
The practical fix is to model access as a business capability graph, not a list of application permissions. That means mapping who can initiate, approve, modify, and reconcile across the full process, then tying each entitlement back to the role, account, or exception that created it. Once those relationships are visible, toxic combinations can be tested against actual business duties instead of guessed from isolated role names.
Good coverage usually requires three views at once: entitlement data from each system, business-process rules that define incompatible duties, and evidence of temporary exceptions or delegated access. If any one of those is missing, the review may still look complete while the real conflict remains hidden. In connected environments, the control objective is cross-system correlation, not perfect uniformity.
For teams working with access-heavy workflows, it helps to anchor reviews in the process path itself. The strongest signal is whether the same person can create a condition, approve it, and benefit from it, even if those steps occur in separate tools. That is where least privilege becomes measurable rather than rhetorical. For related control practice, see ISO/IEC 27002:2022 Information Security Controls.
Risk and Threat Considerations
When GRC only sees one application at a time, the main risk is false confidence. A control may appear effective because no single system shows an obvious violation, while the real exposure sits in the combination of entitlements, delegated approvals, and privileged paths across multiple systems.
Failure mechanism: separate systems each pass their own checks, but the enterprise never evaluates whether the same actor can combine those rights into an unsafe business action, so toxic access survives until a manual audit or incident reconstruction exposes it.
Impact: SoD violations, approval conflicts, and hidden privileged access can persist longer, widen audit scope, and increase the likelihood that an insider or compromised account can move from access to harmful action without early detection.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 27001:2022 | A.5.15 — Access control | Cross-application access review needs enterprise access control rules. |
| Recommendation — Define cross-system access rules and review toxic combinations against them. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Toxic access emerges when combined permissions exceed need-to-know. |
| AC-5 — Separation of Duties | The question is about SoD conflicts hidden across multiple systems. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Cross-system conflicts are often found only through correlated review and analysis. | |
| Recommendation — Limit combined entitlements to the minimum needed for the business process. Enforce duty separation across systems, not only within each application. Correlate audit evidence across applications to surface hidden toxic combinations. | ||
| NIST CSF 2.0 | PR.AA-05 — Least privilege | The issue is effective privilege across business workflows, not single-app roles. |
| GV.RM-01 — Risk management strategy | Enterprise risk needs a method for identifying cross-system access exposure. | |
| Recommendation — Review aggregated access paths and remove unnecessary privilege. Define a process to assess composite access risk across applications. | ||
Practitioner Guidance
What to verify: Confirm that your access review process can answer one cross-system question: can this person complete a prohibited business sequence end to end? If the answer depends on spreadsheets or after-the-fact evidence assembly, the control is not yet operationally reliable.
Decision rule: If a role review is limited to one application, treat it as a local hygiene check, not a SoD decision. Escalate any access path that spans request, approval, and execution, because that is where effective privilege is created.
Practitioner takeaway: The control problem is not incomplete inventory, it is incomplete correlation. If you cannot evaluate entitlements in combination, you cannot prove that the business process is actually segregated.