Poor reviews miss toxic combinations that only become visible when entitlements are analysed together across systems. That lets one user accumulate conflicting capabilities, such as creating and approving the same transaction. The result is not just a policy issue. It is a practical opening for fraud, error, and audit findings.
How weak access reviews turn into SoD violations
Access reviews only work when they test combinations, not just individual permissions. A user can look harmless in isolation and still hold a toxic pair, such as create and approve, request and release, or admin and audit access. Poor review quality misses those combinations, so the organisation keeps entitlements that defeat segregation of duties and weaken control design.
That failure is usually structural: reviews are too broad, too infrequent, or too shallow to reveal how entitlements interact across applications and business processes. When the review process treats each system as a separate list, it can preserve a conflict that only becomes visible when access is analysed as an end-to-end workflow.
Why the same control gap creates fraud exposure
SoD exists to stop one person from completing a high-risk transaction without independent oversight. If a review leaves a conflict in place, the user can both initiate and approve an action, override checks, or conceal a bad transaction inside routine workflow. That turns a governance miss into practical fraud, error, and audit exposure.
The risk is highest where business systems allow privileges to accumulate over time, or where emergency access, role changes, and manual exceptions are not cleaned up promptly. Even without malicious intent, the same conflict can enable self-approval, inaccurate postings, duplicate payments, or undetected manipulation of records.
What good review practice has to test
Effective reviews must evaluate entitlements in context, across systems, and against SoD rules that reflect real transaction paths. A good review asks whether a person can create, modify, approve, release, reconcile, or delete the same business event, not just whether each single entitlement looks reasonable on its own. That is where Segregation of Duties (SoD) Guide is especially useful for building conflict rulesets and managing mitigations.
It also needs the right identity data to be meaningful. If the entitlement inventory is incomplete, stale, or disconnected from role design, reviewers will certify what they can see rather than what actually exists. That is why access review quality depends on lifecycle hygiene, role clarity, and visibility into accumulated access across the full identity estate, as covered in IAM and IGA Basics and Access Reviews and Certification Guide.
Risk and Threat Considerations
Poor reviews create a control gap that attackers and insiders can both exploit. The practical danger is not merely policy non-compliance, but retained conflicting access that lets a single account move from initiation to approval, masking fraudulent activity behind ordinary business workflow.
Failure mechanism: Reviewers approve access based on entitlement names or system-by-system ownership, while toxic combinations across applications, roles, or exception paths remain invisible. Conflicts then persist long enough to be used for fraud, concealment, or control circumvention.
Impact: The organisation can suffer fraudulent transactions, misstatements, failed audits, compensating-control debt, and longer dwell time for abuse because the access model itself keeps authorising unsafe combinations.
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, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Directly addresses conflicting access that reviews must detect. |
| AC-6 — Least Privilege | Reduces accumulated access that creates SoD conflicts. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Supports review and detection of suspicious access/transaction patterns. | |
| Recommendation — Enforce separation of duties checks before certifying access. Remove unnecessary permissions that create toxic combinations. Correlate entitlement reviews with audit evidence for approval paths. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access Control | Requires access rules that prevent inappropriate entitlement combinations. |
| A.5.18 — Access rights | Covers review and adjustment of access rights over time. | |
| Recommendation — Define access rules that block conflicting approvals and actions. Recertify rights and remove access that creates SoD conflicts. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle hygiene is needed to stop stale access from surviving reviews. |
| Recommendation — Continuously remove obsolete access and account combinations. | ||
| OWASP ASVS | V8 — Authorization | Authorization controls must prevent unsafe function combinations in workflows. |
| V16 — Security Logging and Error Handling | Review quality depends on evidence that exposes unsafe approval paths. | |
| Recommendation — Verify that users cannot both initiate and approve sensitive actions. Log approval chains so review teams can validate SoD conflicts. | ||
Practitioner Guidance
What to verify: Check whether your review process evaluates cross-system entitlements and SoD rules, not just individual accounts. If reviewers cannot see create, approve, and reconcile privileges together, the process is not strong enough to certify the access as safe.
Decision rule: If a user holds access that can both originate and complete a sensitive transaction, treat that as a conflict until a documented mitigation exists. If the only defence is “a manager reviewed it,” the control should be treated as weak, not compensating.
Practitioner takeaway: Access reviews fail when they certify snapshots instead of testing business conflict paths, so the real objective is to detect toxic combinations before they become executable fraud paths.