A vulnerability management program lives and dies by the trust placed in its records. A finding that is silently downgraded, a risk that is quietly accepted, an auto-assignment policy that quietly reroutes critical work, each of these is a decision with consequences. When one person can make that decision and commit it in the same motion, the program has no defense against a mistake, a rushed judgment, or a deliberate abuse. The four-eyes principle exists to close that gap. It says that a sensitive change should pass under a second set of eyes before it takes effect.
This article is about the principle, not a single button. It explains what four-eyes approval means, where single-approver change control breaks down, which vulnerability decisions genuinely deserve a second reviewer, and how an approval gate is built so that it cannot be bypassed. Throughout, it grounds the abstract control in concrete behavior from the PMAP rule and finding engines, because a principle that is not enforced in code is only a policy slide.
If you are mapping this to a compliance program, four-eyes approval is one expression of a broader separation-of-duties requirement that appears across ISO/IEC 27001:2022, the NIST SP 800-53 AC-5 control, and the change-control expectations in audit frameworks. For the larger picture of how approvals, audit trails, and evidence fit a compliance posture, the pillar on vulnerability management compliance and audit is the companion to this piece.
What the Four-Eyes Principle Means
The four-eyes principle is a control that requires at least two people to authorize a sensitive action before it is executed. The name is literal. Two pairs of eyes review the change. One person proposes or drafts the action, a second person reviews and approves it, and only then does the action become live. The same idea is sometimes called the two-person rule, dual control, or in financial and manufacturing contexts the maker-checker model. The label varies. The mechanic is the same. Authorship and authorization are split between distinct people.
The control is deliberately narrow in scope. It does not slow down every routine action, and it is not meant to. A four-eyes gate is applied selectively to the decisions where a single mistake or a single act of bad faith carries real consequence. The discipline is to identify those decisions precisely, attach the gate only there, and let everything else flow.
What separates a real four-eyes control from a cosmetic one is enforcement. A gate that politely asks for a second reviewer but lets the author click approve themselves is not four-eyes. It is single-approver change control wearing a costume. The genuine article makes self-approval impossible, records who approved what, and refuses to let the change take effect until the approval exists. In PMAP, a rule that opts into the approval gate sets requires_approval = true, and the evaluator skips that rule entirely until its approval_state reaches approved. The control is not a suggestion in the interface. It is a precondition for the rule ever running.
Where Single-Approver Change Control Breaks Down
To understand why the gate matters, look at what happens without it. PMAP’s rule engine is, by design, a self-governing system. Instead of an analyst manually triaging every imported finding, an operator encodes a triage decision once as a rule, and the engine applies it automatically at finding creation and during bulk re-evaluation sweeps. That is enormous leverage. A single rule can rewrite the severity of thousands of findings, accept the risk on an entire class of vulnerabilities, or reroute assignment for a whole tenant.
Leverage cuts both ways. The same property that makes a rule powerful makes a bad rule dangerous. Consider a rule that downgrades scanner-reported critical findings to high when no known exploit is recorded. That can be a perfectly reasonable triage policy. It can also be a quiet way to make a backlog look healthier than it is. With single-approver control, the person who writes that rule is the same person who decides it is acceptable, and the same person who commits it. There is no moment where an independent party can ask whether the policy is sound, whether the criteria are too broad, or whether the timing is suspicious.
The breakdown is not only about malice. Most of the harm in change control comes from ordinary error. An operator means to scope a rule to one project and forgets the filter, so it matches every tenant. An analyst accepts the risk on a finding that, on a second read, clearly should have stayed open. A severity override that looked right at 6 p.m. on a Friday looks wrong on Monday morning. A self-governing engine executes these decisions faithfully and fast, which means a single-approver model gives a tired or mistaken person a very short path from intention to irreversible effect. The whole point of a second reviewer is to insert a deliberate pause and an independent judgment between the two.
There is also an accountability dimension that pure technical controls miss. When one person owns the entire lifecycle of a sensitive change, the audit record can only ever say that one person did it. When authorship and approval are split, the record captures two distinct human decisions, which is exactly what an auditor wants to see when they ask who authorized a policy that affected the risk register.
The Sensitive Changes That Deserve a Second Set of Eyes
Four-eyes is a scalpel, not a blanket. Applying it to everything would grind a program to a halt and train people to rubber-stamp. The skill is identifying the changes whose blast radius or risk impact justifies the friction. In a vulnerability workflow, a few categories stand out.
The first is policy that mutates findings at scale. A rule in PMAP can override severity, set a finding to accepted risk, auto-assign work, normalize titles, append tags, or set a vulnerability type. Of these, the changes that move risk are the ones that most deserve review. A severity override reshapes how the rest of the program perceives urgency. An accepted-risk action takes a live vulnerability off the active worklist. Because a rule applies across the whole population it matches, the consequence of getting it wrong is multiplied by the size of that population. That is precisely the profile a four-eyes gate is meant to guard.
The second category is sensitive status changes on individual findings. The finding domain treats certain status transitions as significant enough that they can require approval through a dedicated approval gate. Moving a finding to accepted risk, for example, is a terminal decision in the status state machine. It is not a step toward remediation. It is a declaration that the organization will live with the risk. A decision that ends a finding’s active life and feeds the risk register is a natural candidate for a second reviewer, especially in a regulated environment where someone will later be asked to justify why a known vulnerability was left in place.
The third category is anything that touches the integrity of the record itself. Bulk operations, risk acceptance, and severity adjustments all change what the program reports to leadership and to auditors. If those numbers can be reshaped by one person acting alone, the reports built on them inherit that fragility. A four-eyes gate on the decisions that move the numbers is, in effect, a control on the trustworthiness of every downstream dashboard and export.
What does not belong behind a four-eyes gate is just as important. Routine triage, ordinary assignment, note-taking, and the day-to-day movement of a finding through its workflow do not need a second approver. Gating them would create approval fatigue, which is its own security failure, because reviewers who approve everything by reflex provide no real review at all. The principle works only when it is reserved for changes that earn it.
How a Four-Eyes Gate Works in Practice
A control is only as good as its mechanics. The four-eyes principle becomes real when there is a defined lifecycle that a sensitive change must travel, a hard rule that the approver cannot be the author, and a requirement that a rejection carries a reason. PMAP’s rule approval workflow implements all three, and looking at it shows what a robust gate needs.
The Approval State Machine
A four-eyes gate needs more than a flag. It needs states, because the change has to move through distinct phases that everyone can see and the system can enforce. In PMAP, a rule that requires approval moves through a small, explicit state machine. The states are draft, pending, approved, and rejected. The transitions are deliberate.
A rule begins as a draft. While it is a draft, it is not live, and the evaluator does not run it. When the author is satisfied with the policy, they submit it for review, which advances the state from draft to pending. A pending rule is in the queue for a second reviewer. It still does not run. A reviewer then either approves it, moving the state to approved, or rejects it, moving the state to rejected. Only an approved rule is eligible to be applied to findings.
This structure matters because each state has a clear meaning and a clear set of permitted next moves. A draft can be submitted. A pending rule can be approved or rejected. There is no path that lets a rule skip from draft straight to live, and there is no ambiguity about where a given rule stands. The state itself is the record of how far the change has progressed and who is responsible for the next move. Modeling sensitive change as a state machine, rather than a single yes-or-no field, is what makes the gate auditable and what makes its enforcement reliable.
Why the Approver Must Differ From the Author
The single most important rule in any four-eyes implementation is the one that prevents self-approval. Without it, the entire control collapses, because the author can simply approve their own change and the second pair of eyes never exists. PMAP enforces this at the engine level. When an approval is attempted, the approver’s identity is compared against the rule’s creator, and if they match, the action is rejected with ErrSelfApproval. The author of a rule cannot be its approver. Full stop.
This is the difference between a control and a hope. A workflow that merely displays an approve button to everyone, including the author, is trusting people not to take the obvious shortcut. The four-eyes principle does not trust. It enforces. By comparing the approver UUID against the created_by UUID and refusing the action when they are equal, the system guarantees that two distinct people were involved, no matter what the interface offers or how the author behaves. This is the direct technical expression of separation of duties as described in NIST SP 800-53 control AC-5, which calls for dividing roles so that no single individual can both initiate and complete a sensitive action.
Who is allowed to play the approver role is governed separately, by access control. Approval is a privileged action, and only callers holding the appropriate approve grant may take it. The self-approval block and the permission requirement work together. The permission decides who may approve at all, and the self-approval block decides that, among those people, it cannot be the one who authored the change. Both conditions must hold.
Rejection Needs a Reason
A four-eyes gate is not only about saying yes. A meaningful review can also say no, and a no that comes without explanation is almost useless to the people who have to act on it. PMAP requires that a rejection carry a non-empty reason. An attempt to reject a rule with no explanation is refused with ErrRejectionReasonRequired.
The requirement does real work. It forces the reviewer to articulate why the change was not acceptable, which gives the author something concrete to fix rather than a silent dead end. It also creates a record. The rejection reason becomes part of the change’s history, so a later reader can see not just that a proposed policy was turned down but on what grounds. In an audit context, that trail of reasoned rejections is as valuable as the trail of approvals, because it demonstrates that review was substantive rather than ceremonial. A gate where the only recorded outcome is approval tells you nothing about whether anyone was ever willing to say no.
What Happens to Unapproved Policies
The clearest test of whether an approval gate is real is what the system does with a change that has not been approved. A cosmetic gate lets the change run and simply notes that approval is pending. A real gate refuses to let the change have any effect until the approval exists.
PMAP takes the strict path. The rule evaluator skips any rule whose requires_approval is set until its approval_state is approved. A draft rule does not run. A pending rule does not run. A rejected rule does not run. Only an approved rule enters the evaluation pipeline that PMAP executes after every finding create or import. This means there is no window in which an unreviewed policy quietly mutates findings while it waits for a reviewer to get around to it. The default state of a sensitive change is inert. It does nothing until a second person has explicitly authorized it.
This default-inert behavior is what makes the gate trustworthy rather than advisory. The burden is placed in the right direction. A change does not run until it is approved, instead of running until someone notices it should not have. For a self-governing engine that can rewrite thousands of findings, fail-closed is the only safe default, and four-eyes approval is the human gate that turns that default into a deliberate, reviewed decision.
It is worth noting how this interacts with the rest of the engine. PMAP evaluates active rules in priority order, and a rule that is awaiting approval is simply absent from that ordered run. It does not occupy a slot, does not partially apply, and does not leave findings in a half-mutated state. Its absence is total until the moment approval lands. After that, it takes its place in the evaluation order like any other active rule.
Approver Resolution: Who Can Sign Off
A four-eyes gate raises an operational question that is easy to overlook. The system blocks the author from approving, but it still has to know who the legitimate approvers are. If the gate cannot identify the right second reviewers, it either traps changes forever or invites people to route around it.
PMAP answers this through its access-control model. Approval is one of the actions that the permission system can grant, and the right to approve is checked when an approval is attempted. For findings, the platform resolves the set of users who are allowed to approve a given change based on who holds the relevant approve grant, so that a sensitive status change is routed to people with the authority to sign off rather than to anyone with a login. For rules, the approve and reject endpoints require the rule approve permission, which is distinct from the permission to create or edit a rule in the first place.
That distinction is the quiet heart of separation of duties. Authoring a policy and approving a policy are different privileges. A person might be trusted to draft rules all day and never be granted the approve permission, while a smaller set of senior reviewers holds approval authority and rarely authors anything. Splitting the permissions is what lets an organization model its real governance, where the people who design controls and the people who sign off on them are not the same. The self-approval block is the last line of defense for the cases where one person happens to hold both grants, but the cleaner design is to keep the two privileges in different hands from the start.
Four-Eyes as Audit-Ready Evidence
The final reason four-eyes belongs in a vulnerability workflow is that it produces exactly the kind of evidence an audit asks for. Separation of duties is not only a security practice. It is an explicit expectation in ISO/IEC 27001:2022, and it sits behind the change-control and access-control criteria in most assurance frameworks. When an auditor asks an organization to demonstrate that conflicting duties are separated, the most convincing answer is a record showing that sensitive changes were authored by one person and approved by another.
A four-eyes gate generates that record as a byproduct of doing its job. Because the approval workflow is a state machine, every transition is a discrete, attributable event. The submission, the approval, and the identities behind each are captured for the rule. The rejection reason, when a change is turned down, is captured too. The result is a chain of evidence that says, for a given policy, here is who proposed it, here is who reviewed it, here is when each happened, and here is why a rejected version was sent back. That is not a report someone assembled after the fact to satisfy an auditor. It is the natural output of the control operating normally.
This is the connection back to compliance. An organization that runs four-eyes approval on its sensitive vulnerability changes is not only reducing the chance of a bad change. It is continuously manufacturing the proof that its change control works. For a deeper treatment of how those approval events join finding history, status changes, and access events into a complete compliance picture, the vulnerability management compliance and audit pillar covers the full evidence chain.
If you want to see this principle as a concrete product behavior rather than a concept, the operational walkthrough of approving sensitive finding changes shows the gate from the operator’s seat. If you are weighing this control against the alternative, the comparison of four-eyes versus single-approver change control lays the two models side by side. This article stays on the principle so that those two have a foundation to build on.
Frequently Asked Questions
What is the four-eyes principle in security?
The four-eyes principle is a control that requires a sensitive action to be authorized by at least two distinct people before it takes effect. One person proposes or drafts the change, a second person independently reviews and approves it, and only then does the change become live. In a vulnerability workflow, PMAP applies this to rules that can mutate findings at scale and to sensitive finding status changes. A rule that opts into the gate does not run until a second person has approved it. The control is sometimes called dual control, the two-person rule, or the maker-checker model.
Can someone approve their own change?
No. Self-approval is blocked at the engine level. When an approval is attempted, the approver’s identity is compared against the change’s author, and if they are the same person the action is refused with ErrSelfApproval. This is the load-bearing rule of any four-eyes implementation, because without it the author could simply approve their own work and the second reviewer would never exist. Enforcing it in code, rather than relying on people not to take the shortcut, is what separates a real control from a cosmetic one.
What happens to a rule that is awaiting approval?
It does nothing. PMAP’s rule evaluator skips any rule that requires approval until its approval_state is approved. A draft rule, a pending rule, and a rejected rule are all absent from the evaluation run that fires after every finding create or import. There is no window in which an unreviewed policy quietly mutates findings while it waits for a reviewer. The default state of a sensitive change is inert, which means the burden sits in the right place. A change runs only once it is approved, instead of running until someone notices it should not have.
Who is allowed to approve a finding change?
Approval is a privileged action governed by access control. Only callers who hold the relevant approve grant may approve, and for findings the platform resolves the set of users authorized to approve a given change rather than offering the button to anyone with a login. The permission to approve is kept distinct from the permission to author a change, which lets an organization put policy design and policy sign-off in different hands. The self-approval block then ensures that even a person holding both grants cannot approve their own change.
Why does a rejection need a reason?
Because a no without an explanation is almost useless to the person who has to act on it. PMAP refuses a rejection that carries no reason, returning ErrRejectionReasonRequired. The requirement forces the reviewer to state why the change was unacceptable, which gives the author something concrete to fix, and it adds the explanation to the change’s history. In an audit context, a trail of reasoned rejections demonstrates that review was substantive rather than ceremonial, because it shows reviewers were genuinely willing and able to say no.
Should four-eyes approval apply to every change?
No, and applying it everywhere would weaken it. Gating routine triage, ordinary assignment, and day-to-day workflow movement would create approval fatigue, where reviewers approve everything by reflex and provide no real review. The principle works only when it is reserved for changes whose blast radius or risk impact justifies the friction. In a vulnerability workflow, that means policies that mutate findings at scale, risk acceptance, severity overrides, and the sensitive status changes that move a finding off the active worklist or into the risk register.
How does four-eyes approval relate to separation of duties?
Four-eyes approval is one practical expression of separation of duties, the broader principle that no single individual should be able to both initiate and complete a sensitive action. Separation of duties appears in ISO/IEC 27001:2022 and as control AC-5 in NIST SP 800-53. A four-eyes gate implements it by splitting authorship from approval, by keeping the two permissions distinct, and by blocking self-approval. The state-machine record it produces is exactly the evidence an auditor expects when they ask an organization to demonstrate that conflicting duties are separated.
