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
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.
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.