Use layered approvals for critical transactions so at least two independent people review the request before execution. Pair that with documented role ownership, system enforced permissions, and logs that show who approved what and when. The goal is not bureaucracy for its own sake, but a control design that makes collusion and single person abuse much harder.
Why multi-level approval is a control, not a formality
Multi-level approval is most effective when it changes the execution path for a high-risk transaction, not when it merely adds a second click. The control should create independent review, clear ownership, and an auditable decision trail so that a single compromised account, rushed operator, or coerced approver cannot complete the action alone. For transaction flows that depend on privileged access or sensitive keys, that separation is essential.
In practice, the approval chain should be risk-based: routine low-risk actions stay simple, while high-impact transactions require stronger scrutiny, tighter permissions, and stronger evidence of intent. That is especially important where the transaction can move funds, change entitlements, rotate secrets, or alter production state. NHIMG’s Ultimate Guide to NHIs, what are non-human identities is useful background where the transaction is executed through service accounts, API keys, or other machine-access paths.
How to design the approval path so it actually reduces abuse
Use approvals that are independent in both people and authority. The two reviewers should not share the same business interest, the same credential, or the same operational path to execution, otherwise the control can collapse into one person validating their own decision. Where possible, make the system enforce the separation so approvers cannot self-approve, backdate approval, or reuse delegated access to bypass the second review.
- Define which transaction types require two approvals, and which require more.
- Separate requestor, approver, and executor roles in the workflow engine.
- Bind approval to the specific transaction object, amount, destination, or change set.
- Record who approved, what they approved, and when the approval was granted.
- Require step-up review for exceptional thresholds, new beneficiaries, or emergency actions.
The approval flow should also be paired with least privilege. If the executor already has broad authority, approval becomes a paper control rather than a hard barrier. NHIMG’s 2024 Non-Human Identity Security Report is relevant here because overprivilege and weak lifecycle controls are common ways privileged actions slip past intended safeguards.
What teams should verify before trusting the control
Approval is only useful if the enforcement point is real. Teams should verify that the system blocks execution until all required approvals are present, that exceptions are explicitly governed, and that approval evidence is tamper-resistant. If approvals are collected in email, chat, or spreadsheets but the real system can still be executed independently, the control is weak by design.
Good governance also depends on reviewability. Logs should make it possible to reconstruct the full decision path, including any override, emergency approval, or delegated action. For sensitive transaction classes, that audit trail should be easy to query and retained long enough for investigation and post-incident review. The operational lesson is simple: if you cannot prove the decision path later, the approval path was not strong enough in the first place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Multi-level approval relies on restricting who can execute high-risk actions. |
| Recommendation — Enforce least privilege and separate duties for high-risk transaction execution. | ||
| NIST CSF 2.0 | PR.AA-04 — Identity Proofing, Authentication, and Authorization | Approval workflows depend on strong authorization before sensitive actions execute. |
| PR.AA-05 — Access Permissions | The control is weakened if approvers or executors hold excessive permissions. | |
| PR.DS-01 — Data-at-Rest Protection | High-risk transaction controls often protect sensitive records, funds, or secrets. | |
| Recommendation — Require strong authorization checks before allowing high-impact transactions. Limit permissions so approvers and executors cannot bypass the approval path. Protect sensitive transaction data and evidence from unauthorized modification. | ||
Practitioner Guidance
What to prioritise: Start with the transactions that create the largest blast radius, such as payments, entitlement changes, secret rotation, and production-impacting operations. Those are the cases where weak approval design turns into real loss or systemic abuse fastest.
What to verify: Confirm the control is enforced by the system of record, not by process memory. The best test is whether a request can still execute if one approver is unavailable, compromised, or colluding.
Common mistake: Treating dual approval as sufficient even when approvers lack independence or the executor already holds the ability to override the workflow. That turns a control into a notification.
Practitioner takeaway: Multi-level approval only works when it constrains execution, preserves independence, and leaves a durable audit trail that can withstand both abuse and investigation.
