Four-Eyes Dual Control
Require two independent approvers for high-risk actions, where the initiator cannot also be an approver. Cuts fraud, fat-finger errors, and insider risk at the cost of a few minutes per decision.
On this page
Visual Flow
Rendering diagram…
When to Use This Pattern
Use four-eyes when the cost of a single person being wrong — or compromised — is too high:
- Large financial transfers, refunds, and write-offs
- Privileged access grants (admin roles, production DB access)
- Publishing content that represents the company externally
- Changes to security configurations
- Deleting or restoring customer accounts
Regulated industries (banking, pharma, aerospace) often mandate this. For unregulated work, use it anywhere the blast radius is "that's a firing / headline / lawsuit".
How It Works
Two distinct people must approve the action. The initiator cannot be an approver. Often a third constraint applies: the two approvers must be from different roles or departments ("segregation of duties").
The approval is sequential or parallel:
- Sequential: approver 1 signs, then approver 2 sees it
- Parallel: both see it at the same time; either can approve or reject
Parallel is faster; sequential is easier to explain to auditors.
"Cannot be the initiator" includes delegates, shared accounts, and system IDs. If person A asked person B to raise the request, person A still can't approve. Rules-lawyering this is how control breaks.
Implementation Guide
Step 1: Define eligibility per approver slot
Who can approve slot 1? Who can approve slot 2? Often they're different groups — e.g. slot 1 is the requester's manager, slot 2 is from finance or security. Encode this per action type.
Step 2: Enforce the segregation rule server-side
Client-side checks are theatre. The request to record approver 2 must verify they're not the initiator and not approver 1, before accepting the action.
Step 3: Provide context to every approver
Approvers won't read a request carefully if you don't make it easy. Show: what's being requested, who asked, justification, related history, and the change's impact.
Step 4: Audit every decision
Action, actors, timestamps, justifications. Immutable. If your audit trail depends on log retention that rolls off in 30 days, you don't have an audit trail.
Step 5: Handle the "we need it now" case carefully
Emergencies happen. Decide in advance: is there a break-glass path with a single-approver override and mandatory post-hoc review? Or do you wait for the second approver? Both are valid — just don't invent one at 3am.
Tips & Best Practices
- Train approvers to reject. If every approval is a rubber stamp, you don't have a control, you have a speed bump.
- Timeout long-pending requests. Auto-cancel after 48 hours with a notification. Stale requests accumulate risk.
- Report on approver-rejection rates. 0% means no one's reading. 30%+ suggests requestors are throwing spaghetti.
- Don't chain more than two. Four-eyes works; six-eyes is process theatre.
- Exclude approvals from themselves. An approver who's also a beneficiary of the action (expense on their own card) must not be able to approve it, even through delegation.
Related patterns
Budget-Tiered Approval
Route purchase requests, expense reports, and financial approvals through different approval chains based on the dollar amount. Low-value requests skip senior approvers; high-value requests get more scrutiny.
Parallel Approval with Threshold
Send approval requests to multiple people simultaneously and proceed when a minimum number approve. Faster than serial chains for peer-level decisions.
Serial Approval Chain
Route a request through a sequence of approvers where each must approve before the next receives it. The simplest and most common approval pattern.