Most teams do not pick a change-control model on purpose. They inherit one. A tool ships with a single approval field, an analyst gets the power to push changes through, and that becomes the de facto policy. The decision was never debated. It was simply the path of least resistance.
That works until an auditor asks a harder question. Who approved the decision to mark this critical finding as accepted risk? Was that the same person who proposed it? Can you prove the two were different people? At that moment the difference between two approval models stops being academic. It becomes the difference between a clean audit and an open finding on your own program.
This article compares two models for approving sensitive changes in vulnerability workflows. The first is single-approver change control, where one person can authorize a change on their own. The second is four-eyes change control, also called dual approval or maker-checker, where the person who proposes a change cannot be the person who approves it. The goal here is not to rehearse the principle behind four-eyes in the abstract. That ground is covered in our companion piece on the four-eyes principle in vulnerability workflows. The goal is narrower and more practical. Given a real vulnerability management program, which model belongs where, what does each cost, and what evidence does each one leave behind.
We will hold both models against six comparison criteria, then look at how PMAP implements four-eyes for finding change rules so the comparison stays concrete rather than theoretical. Throughout, the focus stays on decisions that change a finding’s severity, status, or disposition, because those are the changes auditors and risk owners care about most.
Two Models for Approving Sensitive Changes
A vulnerability management platform does not just store findings. It changes them. Severity gets overridden when context shows a scanner was too aggressive. Findings get marked as accepted risk when a business owner signs off on a known exposure. Whole categories of findings get auto-assigned or downgraded by policy rules that run unattended. Each of these is a mutation, and each mutation is a decision someone is accountable for.
The single-approver model treats that decision as one signature. A person with the right permission makes the change, and the change takes effect. There is no second party in the loop. This is fast and it is simple. For low-consequence changes it is also entirely reasonable. Nobody needs a second reviewer to fix a typo in a finding title.
The four-eyes model splits the decision into two roles. One person proposes the change and submits it for review. A second, different person approves or rejects it. The change does not take effect until that second signature lands. The principle has a long history in financial controls and operations, where it is also called the two-person rule or two-person integrity. In a vulnerability program it maps cleanly onto policy automation. The author of a rule that mutates findings is the maker. The approver who reviews that rule before it can run is the checker.
PMAP encodes this directly in its rule engine. A rule is a named, prioritized policy that matches active findings against a criteria tree and applies an action such as a severity override or a risk-acceptance status change. Most rules are operational and run without ceremony. But any rule can opt into a mandatory approval gate by setting requires_approval. Once that flag is on, the rule moves through a controlled lifecycle before it is ever allowed to touch a finding. That opt-in design is the hinge of this whole comparison, because it means a single platform can run both models side by side and apply the heavier one only where it earns its cost.
Comparison Criterion 1: Who Can Approve a Change
The first and most decisive criterion is the one most tools get wrong. Who is allowed to approve a change, and specifically, can the person who proposed it approve it themselves.
Single-Approver: One Person Can Self-Authorize
In a single-approver setup the answer is yes by default. The person who proposes the change is the person who commits it. There is no structural barrier between proposing and approving because the model collapses both into one action.
In PMAP terms, a rule with no approval gate behaves this way. When requires_approval is not set, the evaluator applies the rule’s mutation directly as part of normal finding processing. No second party is consulted. For a rule that, say, appends a tag or normalizes a title, this is exactly right. The change is low-stakes, reversible, and not the kind of thing a separation-of-duties control is meant to police.
The risk appears when the same one-signature path is used for high-consequence changes. If a single analyst can author and activate a rule that downgrades every critical finding on a class of assets, or that marks a population of findings as accepted risk, then one person holds the entire decision. There is no independent check, and from the outside the record cannot distinguish a sound judgment from a mistake or an abuse. The control gap is not that the person is untrustworthy. It is that the model produces no evidence that anyone other than the proposer ever looked.
Four-Eyes: Self-Approval Is Blocked by Design
Four-eyes closes that gap structurally rather than relying on people to remember a policy. The rule cannot reach the approver and the proposer being the same person, because the system refuses it.
PMAP enforces this at the approval gate. When a rule carries requires_approval, the approver’s user identity must differ from the rule’s created_by. If they match, the platform rejects the approval with ErrSelfApproval. This is not a configurable preference or a setting an admin can quietly turn off for convenience. It is a property of the approval path itself. The maker cannot also be the checker.
That distinction is what separates a real separation-of-duties control from a cosmetic one. Many tools have an approval field. Fewer can prove that the approval came from a second human being. The self-approval block is the difference between a workflow that looks governed and one that is governed. For the principle behind why this matters at a control-design level, our deep dive on the four-eyes principle walks through the reasoning. For this comparison the practical takeaway is simple. Single-approver permits self-authorization; four-eyes forbids it at the system layer.
Comparison Criterion 2: The Approval State Machine
A second criterion is whether the model has explicit states at all. Single-approver effectively has one transition. A change is either not made or made. There is no intermediate state where a proposed change sits, visible, waiting for review.
Four-eyes needs a state machine because it has to represent the gap between proposed and approved. PMAP models a rule’s approval lifecycle as draft → pending → approved | rejected. A rule starts as a draft. The author submits it for review, which moves it to pending. From pending it lands in either approved or rejected. Each transition has its own endpoint, which means each one is a distinct, recorded action rather than an implicit side effect of saving a form.
Submit, Approve and Reject With a Mandatory Reason
The three transitions correspond to three operations. Submit advances a rule from draft to pending. Approve grants the approval, subject to the self-approval block described above and the appropriate approval permission. Reject sends the rule back, and here PMAP adds a control that matters for audit quality. A rejection requires a non-empty reason. Attempting to reject without one returns ErrRejectionReasonRequired.
The mandatory reason is easy to overlook and important in practice. A rejected change with no explanation tells a future reviewer nothing. A rejected change that records why it was rejected becomes part of the institutional memory of the program. It documents the judgment, not just the outcome. Single-approver workflows have no equivalent, because there is no rejection step to attach a reason to. The decision either happened or it did not, and the reasoning lives only in someone’s head.
This is one place where four-eyes is not merely more cautious. It is more informative. The state machine forces the program to articulate decisions it would otherwise leave implicit.
Comparison Criterion 3: What the Evaluator Does Before Approval
A subtle but critical question is what the automation does with a change that has been proposed but not yet approved. A weak implementation might let the change leak through, treating approval as advisory. A strong one treats the unapproved state as a hard stop.
PMAP takes the hard-stop position. The rule evaluator skips any rule that requires approval until its approval state is approved. An unapproved rule does not run against findings. It does not partially apply. It is simply absent from evaluation until the second signature lands. This is a fail-closed posture, and the engine reinforces it elsewhere too. A rule with empty or all-blank criteria is rejected at creation, and the evaluator also returns no match for an empty tree, so a malformed rule can never mass-mutate findings by accident.
The comparison here is stark. Under single-approver there is nothing to hold back, because the change applies as soon as the one approver acts. Under four-eyes the change is held back by default and released only on approval. The default direction is what counts. A control that fails open is not really a control. PMAP’s evaluator fails closed, which means the absence of approval is treated as a refusal, not as a gap to be filled later.
Comparison Criterion 4: Audit Evidence Each Model Produces
For a compliance officer this is often the deciding criterion. Setting aside which model is safer in principle, which one leaves behind evidence you can hand to an auditor without a week of reconstruction.
PMAP produces two complementary trails, and the distinction between them is worth understanding because they answer different questions. The first is the rule audit log. Every successful rule application writes a rule_audit_log row that captures the action snapshot plus a before summary and an after summary of the affected finding’s severity, status, and vuln type. This trail answers what changed. It shows the exact effect of a rule on each finding it touched, with the prior state preserved alongside the new one.
The second trail is the security audit. PMAP records high-consequence security actions, including access and role lifecycle events, as typed events in the access_audit_events table. This trail answers who did what under which authority. Together, the change record and the security record let a reviewer reconstruct both the mutation and the human context around it.
Single-approver workflows can produce a change log too. What they structurally cannot produce is evidence of independent review, because no independent review occurred. The before-and-after of the change exists, but there is no record of a second party because there was no second party. Four-eyes produces the same change evidence and adds the approval lineage on top of it. That added lineage is precisely what frameworks for separation of duties expect to see.
Tamper-Evident Ordering in the Security Audit Trail
One technical property of the security audit trail deserves a closer look, because it affects how much an auditor can trust the record. PMAP writes the security audit events synchronously, directly on the request path, rather than handing them to a background worker that might reorder them. The consequence is that event ordering is preserved. There is no goroutine scheduling that could shuffle the sequence of recorded actions.
Ordering integrity matters when the question is sequence. Did the submission come before the approval. Did the approval come from a session that was authorized at the time. A trail whose ordering can drift makes those questions hard to answer with confidence. A synchronous, ordered trail makes the timeline dependable. The activity-level log, which carries far higher volume, is batched for throughput, and that division of labor is deliberate. The high-consequence security events get strict ordering; the high-volume operational events get scale. The point for this comparison is that four-eyes approval decisions land in the trail that prioritizes integrity over throughput, which is the right place for them.
Comparison Criterion 5: Blast Radius and Reversibility
Approval models are not only about stopping bad changes before they happen. They are also about limiting and undoing the ones that do. A policy rule can touch many findings at once, so the question of blast radius is real.
PMAP gives the approver a way to see the blast radius before approving. A rule supports a dry-run preview that evaluates it against up to 500 active findings without writing anything to the database, returning the before-and-after severity and status for each finding it would affect. A separate live view can scan a larger window of recent active findings and show which ones currently match, with a change summary per row. In a four-eyes flow these tools turn approval from a rubber stamp into an informed decision. The checker can look at what the rule would actually do before letting it run.
Reversibility is the other half. Every rule application is recorded with its before summary, which means a rule’s effects can be revoked by walking the audit log and restoring each finding’s prior state. PMAP offers two revoke modes. Safe mode restores only those findings whose current state still matches what the rule set, which protects later manual edits from being clobbered. Force mode restores unconditionally. Larger reversals run as an asynchronous job so a big blast radius does not stall a request.
Single-approver can technically have preview and undo features too. The difference is who exercises them and when. In four-eyes the preview is consumed by an independent reviewer at the approval moment, before the change runs, by someone other than the author. That is the moment when a second perspective is most valuable. Pairing blast-radius preview with the approval gate is what turns dual approval from a ceremony into a genuine safeguard.
Comparison Criterion 6: Operational Cost vs Control
No honest comparison ignores cost. Four-eyes adds a step. Someone has to review and approve, which means a change waits on a second person’s attention. At scale that latency is not free, and pretending otherwise would be dishonest.
This is where the opt-in design earns its keep. PMAP does not force every rule through approval. Approval is per-rule, set by requires_approval. Rules that do not need a gate run in priority order, unattended, the moment a finding is created or imported. The review gate is reserved for the rules that warrant it. A program can therefore tune the cost. Apply four-eyes to the policies that downgrade severity, accept risk, or sweep across large finding populations, and leave the low-consequence policies on the fast path.
The right framing is not four-eyes everywhere versus single-approver everywhere. It is matching the control to the consequence. A high-consequence change deserves the cost of a second signature because the downside of getting it wrong is large and the change is hard to walk back cleanly. A low-consequence change does not, because the review cost would exceed the risk it offsets. The mistake teams make is uniformity in either direction. Gating everything buries reviewers in trivial approvals until they approve without looking. Gating nothing leaves the consequential decisions unguarded. The cost-versus-control criterion is really an argument for selectivity, and selectivity is exactly what an opt-in gate enables.
When Single-Approver Is Acceptable and When It Is Not
It is worth stating plainly where single-approver is the correct choice, because four-eyes is a tool, not a religion. Single-approver is acceptable when the change is low-consequence, easily reversible, and not the subject of a separation-of-duties requirement. Tagging, title normalization, routine assignment, and similar housekeeping fit this description. Forcing a second approver onto these changes adds friction without adding meaningful protection, and it trains reviewers to approve reflexively, which quietly weakens the gate on the changes that do matter.
Single-approver stops being acceptable at the point where one of three things becomes true. The change reduces the apparent risk of a finding, for example a severity downgrade or a move to accepted risk. The change affects a large population of findings at once. Or the change falls under a control framework that requires segregation of duties for that class of action. When any of those holds, one signature is no longer enough, because the decision now carries consequences that a single person should not be able to make and conceal in the same motion.
The clean way to operate is to draw that line explicitly and let the platform enforce it. In PMAP that means turning on requires_approval for the rule modules that override severity or accept risk, and leaving it off for the operational ones. The line is then not a matter of discipline that erodes under pressure. It is a property of the configuration, applied the same way every time.
How PMAP Implements Four-Eyes for Finding Change Rules
Pulling the threads together, here is the full shape of four-eyes in PMAP, end to end, for a rule that mutates findings.
An author creates a rule and sets requires_approval. The rule starts as a draft. Before submitting, the author can dry-run it against up to 500 active findings to confirm it does what they intend, with no database writes. When ready, the author submits the rule, moving it from draft to pending. While it sits in pending, the evaluator ignores it entirely. The rule cannot touch a single finding, because unapproved rules are skipped, fail-closed.
A second person with approval permission reviews the pending rule. They can inspect the live affected-findings view to see the real blast radius before deciding. If they approve, the system first verifies that their identity differs from the rule’s creator. A match is rejected with ErrSelfApproval, so the maker can never be the checker. If the reviewer rejects instead, they must supply a reason, enforced by ErrRejectionReasonRequired, and that reason becomes part of the record.
Once approved, the rule enters normal evaluation. From then on, each time it applies to a finding it writes a rule_audit_log row with the action snapshot and the before-and-after summary, so every mutation is accountable. If the rule turns out to be wrong even after approval, its effects can be revoked in safe or force mode by restoring the recorded prior states. The same approval-gate pattern extends to sensitive finding status changes, where PMAP’s finding domain supports an approval workflow for changes that should not happen on one person’s say-so.
That is the concrete answer to which model belongs in vulnerability workflows. Both do, on different changes. The platform’s job is to make the heavier model cheap to apply exactly where it is warranted and invisible everywhere else. For a step-by-step look at configuring approvals inside the product, see our walkthrough on four-eyes approval in security operations. For how all of this ties into audit readiness across the wider program, start from our pillar on vulnerability management compliance and audit.
Several established frameworks describe the separation-of-duties expectation that four-eyes satisfies. The control AC-5 in NIST SP 800-53 addresses separation of duties for access and change. ISACA’s guidance on segregation of duties frames it as a core governance control, and the access-control requirements in ISO/IEC 27001:2022 point in the same direction. Auditors assessing against the AICPA SOC 2 Trust Services Criteria routinely look for exactly the kind of independent-approval evidence that four-eyes produces and single-approver cannot.
