The control breaks at the point where access creation, approval, and oversight collapse into one identity. That makes abuse easier to hide, weakens audit evidence, and removes the second check that SoD is meant to provide. In practice, the organisation loses both preventative control and reliable proof that privileges were assigned legitimately.
Why SoD fails the moment creation and approval sit in one admin path
Segregation of duties is meant to force a second, independent decision before access becomes effective. When the same administrator can both create entitlement and approve it, the control no longer separates request, approval, and execution. That turns SoD into a formality, because the actor who introduces the access can also legitimise it.
The practical problem is not just policy violation. It removes the friction that exposes mistakes, coercion, and self-dealing, and it makes later review much harder because the approval no longer represents an independent control point.
What changes in the audit trail and control evidence
Once one identity can complete the full access path, the audit record still exists, but it loses evidentiary strength. A log entry that shows creation and approval by the same admin proves activity, not independent oversight. For reviewers, that is a weak control signal because the record no longer demonstrates challenge, review, or exception handling.
In mature access governance, the evidence needs to show who requested, who approved, and who implemented, with those roles separated in a way the reviewer can trust. If those actions are collapsed, the organisation may still have logs, but it no longer has reliable proof that privileges were granted legitimately.
Why the risk scales beyond a single bad decision
The danger increases when this pattern is allowed for multiple systems, not just one account. A single all-powerful admin can quietly normalise access for themselves or others, then repeat the pattern without meaningful resistance. That creates concentration of privilege, weakens exception handling, and can mask abuse until it appears as ordinary administration.
If the process is used for privileged or high-impact access, the weakness becomes more than a governance defect. It becomes a trust boundary failure, because the same path that grants power also controls the proof that the power was justified.
Risk and Threat Considerations
When approval is not independent, abuse becomes easier to conceal and harder to challenge. The organisation is exposed to unauthorised access, fraudulent entitlement grants, and prolonged overprivilege because the same actor can both make and legitimise the change.
Failure mechanism: The control fails when approval is treated as a procedural checkbox rather than an independent decision, so the administrator can create access, approve it, and leave no meaningful second check.
Impact: This weakens deterrence, reduces the chance of catching inappropriate access before it becomes active, and leaves audit evidence unable to prove that the privilege was reviewed by a separate authority.
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 CIS Controls v8 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 governs independent control separation for access decisions. |
| AU-2 — Event Logging | Audit evidence must record who requested, approved, and implemented access changes. | |
| Recommendation — Enforce AC-5 so no single admin can both provision and approve the same access. Log each access change with distinct actor, approver, and implementer fields. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | Requires duties to be separated so one role cannot authorise and execute the same access change. |
| A.8.2 — Privileged access rights | Privileged access needs tighter control where admins can create or approve access. | |
| Recommendation — Separate approval from administration for any access-granting workflow. Restrict privileged access so admin roles cannot self-authorise entitlement changes. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Access control management covers provisioning, approval, and review separation. |
| Recommendation — Require distinct approval and provisioning steps for all sensitive access grants. | ||
Practitioner Guidance
What to verify: Confirm that the approval path is technically and operationally separate from the provisioning path. If the same role can do both, the control design is already compromised even if the workflow looks compliant on paper.
Decision rule: If one person can both create and approve access, treat that as a control exception requiring compensating oversight, not as an acceptable shortcut. Where high-risk access is involved, insist on a distinct approver and preserve evidence of that separation.
Common mistake: Teams often rely on workflow status alone and miss that the approving identity is not independent. The real test is whether a reviewer could reasonably disagree, block, or escalate the request without being the same person who requested it.
Practitioner takeaway: Segregation of duties only works when the approval step can genuinely oppose the creation step; once those powers merge, you still have records, but you no longer have independent control.