Four-eyes approval is a control that requires two separate people to review and authorise a request. It is used for changes, payments, access grants, and other sensitive actions, with the second approver acting as an independent check against error, fraud, or misuse.
What Four-Eyes Approval Means in Security Operations
Four-eyes approval is a dual-control pattern, one person initiates or prepares a sensitive action, and a second, independent person reviews and authorises it. The control matters because it reduces single-actor error, fraud, and misuse.
In security programmes, the value of four-eyes approval is not the number of approvers alone, but the independence of the second check. If the same person can both prepare and approve, the control becomes a formality rather than a safeguard.
This is why four-eyes approval is often paired with segregation of duties, approval thresholds, and workflow systems that block self-approval. It is especially relevant where the action is hard to reverse, such as granting access, changing production systems, releasing funds, or disabling protections.
Where Four-Eyes Approval Is Used
The control appears wherever organisations want a deliberate pause before a high-impact decision. Common examples include privileged access requests, emergency changes, payment release, backup deletion, production deployment, and account lifecycle actions that could create lasting exposure.
In change management, four-eyes approval helps ensure a proposed change has been checked for business need, technical impact, and ownership before it reaches production. In access governance, it helps prevent one person from quietly granting themselves or a peer more privilege than policy allows.
The pattern also shows up in operational platforms that support privileged workflows. For example, dual control is often used to gate destructive or high-risk administrator actions so that a second reviewer can confirm the request before the action is executed.
How Four-Eyes Approval Reduces Abuse and Error
The control works by separating intent from execution. That separation lowers the chance that a typo, rushed judgement, hidden conflict of interest, or malicious request slips through without challenge. It also creates a second record of who reviewed the action and why.
For attackers, the main obstacle is that compromise of one account is not enough if the workflow truly requires an independent approver. That makes four-eyes approval a practical barrier against stealthy privilege escalation, unauthorised changes, and some forms of insider misuse.
Its strength depends on workflow integrity. If approvers are not independent, if approval rights are broadly shared, or if notifications can be bypassed, the control can look strong on paper while offering little real resistance.
Design and Governance Considerations
Four-eyes approval needs clear policy boundaries, because applying it to every action creates friction, while applying it too narrowly leaves critical operations unprotected. Mature programmes define which actions require dual approval, who may approve them, and what evidence must be retained.
It also needs role design that prevents collusion and convenience shortcuts. Independent review works best when the approver has enough context to challenge the request, but not so much authority that the same person can effectively authorise both sides of the decision.
Automation can support the control, but it should not replace the governance judgment behind it. The workflow should enforce the rule, preserve an audit trail, and make exceptions visible rather than treating approval as a mere checkbox.
Risk and Threat Considerations
Four-eyes approval reduces the risk of unauthorised or poorly reviewed sensitive actions, but only when the second approver is genuinely independent. If the workflow can be self-approved, rushed, or socially engineered, the control becomes a weak barrier against fraud, misuse, and destructive change.
Failure mechanism: The control fails when a single actor can influence both sides of the decision, either through shared credentials, weak role separation, approval fatigue, or a workflow that accepts rubber-stamp review without meaningful scrutiny.
Impact: A broken dual-control process can permit unauthorised access grants, harmful production changes, improper payments, or irreversible operational damage, with the audit trail giving a false sense of safety.
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 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Four-eyes approval enforces separate authorisation before sensitive access or action. |
| AC-5 — Separation of Duties | Dual approval is a direct separation-of-duties control for high-impact actions. | |
| CM-3 — Configuration Change Control | Four-eyes approval commonly governs changes to production systems and configurations. | |
| Recommendation — Enforce independent approval before granting or executing sensitive access changes. Separate request and approval duties for privileged or high-risk actions. Require independent review before implementing material configuration changes. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Four-eyes approval is a practical access-control governance measure for sensitive requests. |
| A.5.3 — Segregation of duties | The term is a direct segregation-of-duties mechanism used to prevent single-actor misuse. | |
| Recommendation — Define approval rules for sensitive access requests and enforce them consistently. Split request, approval, and execution duties for sensitive actions. | ||
Practitioner Guidance
Why practitioners should care: Four-eyes approval is most valuable where the business consequence of a single bad action is high and the decision cannot be safely left to one person. Treat it as a control design choice, not just an approval step in a ticketing tool.
Common misunderstanding: Two names on a workflow do not automatically mean effective dual control. Practitioners should verify that the approvers are independent, that self-approval is blocked, and that the process is meaningful for the specific risk being controlled.
Practitioner takeaway: Use four-eyes approval where independence matters most, then make the control real with policy, workflow enforcement, and review evidence that stands up to audit.