A single person should not be able to make a sensitive change, approve it, and execute it without anyone else looking. That is the idea behind the four-eyes principle. Two sets of eyes, not one, sign off before something risky goes live.
The principle shows up under several names across governance, banking, change management, and security operations. You may have seen it called dual control, the two-person rule, or maker-checker. The mechanics differ slightly from one context to another, but the core control is always the same. One person proposes, a different person reviews and approves, and the system refuses to let those two roles collapse into one.
This article is a plain definition of the four-eyes principle. It covers what the principle is, the family of terms it belongs to, how it connects to segregation of duties, and why self-approval has to be structurally blocked rather than discouraged. It does not walk through how to configure approvals in any specific product. For the operational mechanics of four-eyes approval inside vulnerability workflows, see our deeper piece on how four-eyes approval works in vulnerability workflows.
What Is the Four-Eyes Principle?
The four-eyes principle is a control that requires two qualified, distinct people to authorize a sensitive action before it takes effect. The name is literal. Two people, four eyes. One person alone cannot complete the action.
In practice the principle splits a single decision into two roles. The first role creates or proposes the change. The second role reviews that proposal and either approves it or rejects it. The change only becomes effective after the second role approves. If the second role rejects, the change goes back to the proposer with a reason.
The strength of the control comes from one strict rule. The approver must be a different person from the proposer. A control that lets the same person play both roles is not a four-eyes control at all. It is a single-approver workflow wearing a label it has not earned.
The four-eyes principle is most valuable for actions that are hard to reverse, easy to abuse, or wide in blast radius. Examples include releasing a payment, changing access permissions, modifying a production configuration, or altering a security policy that governs how thousands of records are treated. For routine, low-risk actions, four-eyes adds friction without proportional benefit, so most mature programs apply it selectively rather than everywhere.
Four-Eyes, Dual Control, and Maker-Checker
The four-eyes principle has several aliases. They describe the same underlying control with slightly different emphasis, and you will hear them used interchangeably in audits and policy documents.
Dual control is the term you see most often in banking and physical security. It emphasizes that two parties must both act for the operation to complete. The classic image is two keys turning at once to open a vault. Neither key opens it alone.
The two-person rule comes from high-assurance environments such as nuclear weapons handling and certain military and intelligence operations. It stresses physical co-presence and the deliberate removal of any single point of unilateral action. The emphasis is less on review and more on the impossibility of a lone actor completing the task.
Maker-checker, sometimes written maker-checker-approver, is the term favored in finance, accounting, and enterprise software. The “maker” creates the transaction. The “checker” verifies and approves it. Maker-checker maps almost exactly onto four-eyes, and the two phrases are often used in the same breath.
The differences are mostly about tradition and tone. Dual control leans toward simultaneous joint action, the two-person rule leans toward physical co-presence, and maker-checker leans toward sequential propose-then-verify. For digital approval workflows, including security platforms, the maker-checker framing is usually the closest fit because the proposal and the review happen in sequence inside the same system.
When you encounter any of these terms, you can safely read them as expressions of the four-eyes principle. The question to ask is always the same. Can one person complete the sensitive action without a second, distinct person signing off? If yes, the control is not in force regardless of what it is called.
How It Relates to Segregation of Duties
Four-eyes is a specific implementation of a broader control objective called segregation of duties, sometimes called separation of duties. The two are related but not identical, and the distinction matters.
Segregation of duties is the principle that no single individual should control all phases of a sensitive process. The goal is to prevent fraud and error by ensuring that critical tasks are divided among multiple people, so that no one person can both commit and conceal a problem. A classic accounting example splits the person who creates a vendor from the person who pays that vendor, so a single employee cannot invent a fake supplier and route money to it.
Four-eyes is one of the cleanest ways to enforce segregation of duties on a discrete action. Where segregation of duties asks “are these conflicting responsibilities held by different people?”, four-eyes answers it for a single approval gate by requiring that the person who proposes and the person who approves are not the same.
This control objective is embedded in widely referenced frameworks. ISO/IEC 27001:2022 addresses segregation of duties in its Annex A controls on access management, calling for conflicting duties and areas of responsibility to be separated to reduce opportunities for unauthorized or unintentional modification. The NIST SP 800-53 control catalog defines separation of duties as control AC-5, which requires organizations to identify duties that need separating and to implement that separation through access authorizations. ISACA’s COBIT framework treats segregation of duties as a core governance practice across IT processes.
The takeaway is that four-eyes is not an arbitrary best practice. It is a concrete, auditable mechanism for satisfying a control objective that recognized standards expect mature organizations to address. When an auditor asks how you enforce segregation of duties on sensitive changes, a four-eyes approval gate is a direct, demonstrable answer.
Why Self-Approval Must Be Blocked
The single most important property of a four-eyes control is that self-approval is impossible. Not discouraged, not flagged after the fact, but structurally impossible. If the system allows a person to approve their own proposal, the control has a hole large enough to walk through.
Consider what self-approval would mean. An operator proposes a sensitive change, then clicks approve on their own proposal, and the change goes live with the full appearance of having passed review. The audit trail would show an approval, but that approval verified nothing. The proposer reviewed their own work, which is exactly the situation four-eyes exists to prevent.
This is why robust implementations enforce the distinct-approver rule at the system level rather than relying on policy or good intentions. The check is simple to describe. The identity of the approver must not equal the identity of the proposer. If they match, the system rejects the approval attempt and returns an error.
In PMAP, this rule is enforced on sensitive finding-rule changes. When a rule is submitted for review, the platform refuses any approval where the approver is the same person who created the rule. The attempt fails with a dedicated self-approval error rather than silently passing. This is the structural guarantee that turns a nominal approval step into a genuine four-eyes control. The proposer and the approver are always two different people, and the system enforces that boundary on every approval.
Blocking self-approval also closes a subtle gap in segregation of duties. Without it, a privileged user could satisfy the letter of an approval requirement while violating its intent. The distinct-approver check ensures that the spirit and the letter stay aligned.
The Four-Eyes Approval State Machine
A four-eyes control is usually modeled as a small state machine. A proposal moves through a defined sequence of states, and each transition is an explicit, recorded action by a specific person. Modeling it this way makes the workflow auditable. Every step has a who, a when, and an outcome.
The general flow has three or four states. A proposal starts in a draft state, where the proposer builds and edits it freely. When ready, the proposer submits it, which moves the proposal into a pending review state. At that point editing typically stops and the proposal waits for a second person. The reviewer then either approves it, moving it to an approved and active state, or rejects it, sending it back with a reason.
A well-designed flow makes rejection meaningful. A reject action should require a non-empty reason so that the proposer understands what to fix and the audit trail records why the change was turned down. An approval with no record of who approved, and a rejection with no stated reason, both weaken the evidentiary value of the workflow.
PMAP models its four-eyes approval gate this way for finding rules. A rule advances through draft, then pending after submission, then either approved or rejected. Rejection requires a reason string, and an empty reason is refused. Until a rule reaches the approved state, the rule engine skips it entirely, so an unapproved policy never mutates a single finding. The state machine is not cosmetic. It is what makes the approval gate enforceable.
What Counts as a “Sensitive Change”
Not every action needs four-eyes. The principle is reserved for changes whose blast radius or reversibility justifies the added friction. The hard part of applying the principle well is deciding what counts as sensitive enough to gate.
In a vulnerability management context, the sensitive changes are usually the ones that mutate policy rather than data. Consider a rule that overrides the severity of matching findings, a rule that marks findings as accepted risk, or a rule that auto-assigns findings to teams. A change to a policy like this does not touch one record. It can reshape how the platform treats every matching finding, now and going forward. That is exactly the kind of wide-reaching mutation that benefits from a second reviewer.
In PMAP, a finding rule can opt into a mandatory approval gate. When that gate is enabled, the rule cannot take effect until a second person approves it. The operator decides which rules carry the approval requirement, which keeps four-eyes targeted at the policy changes that warrant it rather than slowing down every routine edit. For more on how that gating decision plays out in practice, see how four-eyes approval works in vulnerability workflows.
Where Four-Eyes Applies in Vulnerability Workflows
Vulnerability management is full of decisions that look small but scale wide. A single policy can touch thousands of findings. That makes it a natural home for four-eyes on the right actions.
The clearest example is automated triage policy. Modern platforms let operators encode triage decisions as rules so that incoming findings are mutated automatically instead of one at a time. A rule might downgrade a critical finding with no known exploit, accept the risk on a known false-positive pattern, or escalate anything internet-exposed to a specific team. Each of these is a policy decision with org-wide consequences, which is why a four-eyes gate on the rule itself is worth the friction.
The enforcement matters most at the moment of effect. An approval gate is only as strong as what the engine does with an unapproved policy. The right behavior is for the evaluation engine to skip any rule that has not been approved. In PMAP, the rule evaluator does exactly this. Rules that require approval and have not reached the approved state are left out of evaluation, so a draft or pending policy cannot quietly start mutating findings before a second person has signed off. The control is enforced where it counts, at the point where the policy would otherwise take effect.
Other parts of a vulnerability workflow can benefit from four-eyes as well, such as bulk risk-acceptance decisions or changes that affect reporting and compliance posture. The common thread is the same. When an action sets policy or changes the meaning of data at scale, a second reviewer is a proportionate control.
Four-Eyes vs a Single Approver
It is worth being precise about what separates four-eyes from a single-approver workflow, because the two can look similar on a diagram. The difference is not the presence of an approval step. It is who is allowed to perform it.
A single-approver workflow requires one approval before an action takes effect. That sounds like a control, and it does add a checkpoint. The problem is that nothing in a naive single-approver design prevents the approver from being the same person who made the change. If the proposer can also approve, the checkpoint is theater. The action still passes through one person’s hands end to end.
Four-eyes adds the one constraint that closes the gap. The approver must be distinct from the proposer. That single rule is the difference between a workflow that genuinely distributes trust and one that only appears to. A single approver who is allowed to approve their own work provides documentation, not control.
There are tradeoffs. Four-eyes costs more time and requires that a second qualified reviewer be available, which can create bottlenecks if approver coverage is thin. A single approver is faster and simpler, and for low-risk actions that speed is the right call. The decision is not “four-eyes is always better.” It is “match the control to the risk.” For a fuller comparison of the two models in change control, including when each is the right choice, see four-eyes vs single approver in change control.
If you want to see the four-eyes model applied to a concrete product surface, our overview of four-eyes approvals on sensitive finding changes walks through how the control attaches to individual policy changes.
Bringing It Together
The four-eyes principle is one of the most durable controls in security and governance because it is simple to state and hard to subvert when implemented correctly. Two distinct people must authorize a sensitive change. The proposer cannot approve their own work. The system enforces that boundary rather than trusting people to respect it.
Read the principle through its different names and you find the same control each time. Dual control, the two-person rule, and maker-checker all describe the practice of splitting a sensitive decision across two people. Trace it up to its parent objective and you find segregation of duties, a control that ISO/IEC 27001, NIST SP 800-53 AC-5, and COBIT all expect organizations to address.
In a vulnerability management platform, the principle earns its keep on policy changes that mutate findings at scale. PMAP enforces four-eyes on sensitive finding-rule changes with a real state machine, a mandatory distinct approver, and an evaluator that refuses to run unapproved policy. To see how that approval gate is captured as audit evidence, explore how PMAP records approval history in the audit trail and compliance evidence datasheet.
Frequently Asked Questions
What is the four-eyes principle in simple terms?
It means two different people must approve a sensitive action before it takes effect. One person proposes the change and a second, distinct person reviews and approves it. The name refers to the two pairs of eyes required, and the point is that no single person can complete a risky action alone.
Is four-eyes the same as dual control?
They describe the same control with slightly different emphasis. Dual control stresses that two parties must both act for an operation to complete, and is common in banking and physical security. Four-eyes stresses that a proposal is reviewed by a second person. In digital approval workflows the two terms are effectively interchangeable.
How is four-eyes related to segregation of duties?
Segregation of duties is the broad objective that no single person should control all phases of a sensitive process. Four-eyes is a concrete way to enforce that objective on a single approval gate by requiring the approver to be different from the proposer. Frameworks such as ISO/IEC 27001, NIST SP 800-53 AC-5, and COBIT all treat segregation of duties as an expected control.
Why can’t someone approve their own change under four-eyes?
Because self-approval defeats the entire purpose. If the proposer can also approve, no independent review happened and the control is only cosmetic. Robust implementations block self-approval at the system level, so an approval attempt by the proposer is rejected with an error rather than silently allowed.
What kinds of changes should require four-eyes approval?
Changes that are hard to reverse, easy to abuse, or wide in blast radius. In vulnerability management that usually means policy changes, such as a rule that overrides severity, accepts risk, or auto-assigns findings across many records. Routine, low-risk edits generally do not need four-eyes, since the friction would outweigh the benefit.
What happens to a change that has not been approved yet?
In a correctly built four-eyes workflow, an unapproved change has no effect. In PMAP, a finding rule that requires approval is skipped by the rule evaluator until it reaches the approved state, so a draft or pending policy cannot mutate any findings before a second person signs off.
Is four-eyes always better than a single approver?
No. Four-eyes is stronger for sensitive actions but costs more time and requires a second available reviewer. For low-risk, routine actions a single approver is often the right balance of control and speed. The goal is to match the strength of the control to the risk of the action rather than apply four-eyes everywhere.
