The control stops being preventive and becomes self-authorising. Fraud, error, and concealment become easier because the same person can move a transaction through the full lifecycle without independent challenge. The strongest fix is to remove that overlap at the entitlement level, not just ask managers to watch more carefully.
When the Same Person Can Create and Approve a Transaction, What Actually Breaks?
The break is separation of duties. Once one identity can both initiate and authorise the same transaction, the control no longer provides independent challenge, so fraud, error, and concealment become much easier to execute and much harder to detect. The entitlement model, not the workflow reminder, is what determines whether that risk is real.
Why This Is a Control Failure, Not Just a Process Gap
Segregation of duties works because no single person should control every step that turns intent into execution. If creation and approval sit in the same hands, the control collapses into self-authorisation. That removes an important check on legitimacy, especially where the transaction changes cash, access, vendor master data, entitlements, or other high-impact records.
The practical issue is that approval is supposed to be independent evidence that the transaction deserves to proceed. When the same identity performs both actions, the approval no longer tests the request. It only records it. In audit terms, the control may still exist on paper, but its preventive value is gone.
This is why Identity Security Programme Guide matters here: once approval authority and transaction initiation overlap, the governance question is no longer just process design, it becomes entitlement design and ownership.
Where the Weakness Shows Up in Practice
Overlap is most dangerous when the transaction has downstream business effect and the same identity can both originate and bless it without an independent reviewer. That can happen through broad roles, shared admin paths, exception access, or poorly scoped delegated authority. The failure is usually structural, not malicious at first, because the system allows one role to absorb both responsibilities.
It also tends to hide inside convenience patterns, such as temporary access that was never removed, emergency access that became normal, or role combinations granted to make operations faster. At scale, these patterns create a quiet accumulation of self-approved actions that look routine until a dispute, exception, or fraud review exposes them.
Top 10 NHI Issues and NHI Lifecycle Management Guide both reinforce the same underlying governance lesson, entitlement overlap becomes more dangerous when role scope is broad, stale, or poorly reviewed.
How to Stop Self-Authorising Access Before It Reaches the Workflow
The strongest control is to remove the overlap at the entitlement layer, before the user reaches the approval step. If the same identity can both create and approve, the problem is not the manager’s vigilance, it is the authorization model. Separate duties must be enforced by role design, access review, and exception handling, not left to user discipline.
In practice, that means checking whether the requester, approver, and executor paths are truly distinct for the transaction type in question. If one person can still complete the lifecycle through a secondary role, break-glass path, or delegated approval, the control is still weak even if the UI shows two steps.
Active Directory and Entra ID Hardening Guide is useful where privileged roles and delegation make this overlap easy to miss, and Ultimate Guide to NHIs, Regulatory and Audit Perspectives helps anchor the audit expectation that approval rights should be traceable and reviewable.
Risk and Threat Considerations
When one identity can both create and approve a transaction, the main risk is that a single compromised or dishonest user can move value, access, or records through the full lifecycle without independent challenge. That makes concealment easier and reduces the chance that an abnormal request will be stopped before it is effective.
Failure mechanism: The control fails when authorization is broad enough that the same role, account, or delegated path can perform both initiation and approval, turning an approval step into a formality rather than a safeguard.
Impact: Organisations lose an important fraud barrier, disputes become harder to investigate, and access or financial changes can be executed with less chance of timely 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 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 addresses preventing one identity from creating and approving the same transaction. |
| AC-6 — Least Privilege | Limits the broad role grants that let one user self-authorise a transaction. | |
| Recommendation — Enforce AC-5 to split request, approval, and execution authority across distinct roles. Apply AC-6 to restrict each identity to the minimum authority needed for its function. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control governs who can initiate and approve sensitive business actions. |
| A.5.18 — Access rights | Access-right review is needed to find overlapping entitlements that enable self-approval. | |
| Recommendation — Define and enforce access rules that separate initiator and approver privileges. Review access rights regularly and remove combinations that permit self-approval. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Access control management is the operational control family for separating transaction duties. |
| Recommendation — Use CIS-6 to remove role overlap that allows one account to create and approve the same action. | ||
Practitioner Guidance
What to prioritise: Start with high-impact transaction classes, not every workflow equally. Review where the same identity can initiate, approve, and amend the same record, then remove that overlap at the entitlement or policy layer before tuning alerts.
What to verify: Confirm that approvals are enforced by distinct authorization paths, not by separate screens or process promises. If an exception, emergency role, or inherited group membership can still approve the same request, the control is not actually separated.
Common mistake: Teams often treat manager review as sufficient. It is not, if the manager is also the actor who can create the transaction or if the approval function is delegated so broadly that independence is lost.
Practitioner takeaway: If one identity can complete both sides of a transaction, treat that as an access-design defect, not a workflow nuisance, and fix the entitlement model first.
Related resources from NHI Mgmt Group
- What breaks when one person can create and approve the same financial transaction?
- What breaks when one person can create, approve, and reconcile the same SOX transaction?
- What breaks when one identity can create, approve, and pay invoices?
- What breaks when one role can approve and execute the same transaction?