GUIDE

The four-eyes
principle.

A control old enough to predate computing, and still one of the most effective things you can apply to a modern production environment.

What the four-eyes principle is

The four-eyes principle requires that at least two people review and agree to a significant action before it takes effect. The name refers to the four eyes involved. It is also called dual control, the two-person rule, or two-person integrity, with small differences in emphasis between fields.

It originates in banking and government, where it governs payment release, safe access, and the handling of classified material. The reasoning is not that individuals are untrustworthy. It is that any single person represents a single point of failure — for honest mistakes, for coercion, for compromised credentials, and occasionally for deliberate misuse. Requiring two independent agreements means all of those have to happen twice, to two different people, at the same moment.

Four eyes, maker-checker, and separation of duties

These terms overlap and are frequently used interchangeably, but the distinctions are worth keeping straight.

Four-eyes / dual control — two people must agree to the same action. Both are peers with respect to the decision.
Maker-checker — asymmetric: one person prepares, a different person reviews and releases. Common in finance, and structurally the same as a pull-request review.
Separation of duties — broader and organisational: no single role holds every step of a sensitive process. Four eyes is one way of enforcing it at a specific point. See the separation of duties guide.
Two-person rule — usually the strictest reading, from nuclear and military contexts, where two people must act simultaneously and neither can proceed alone. Covered in more detail here.

Where it belongs in a technical organisation

The principle is only useful where it is applied selectively. Applied everywhere it becomes a formality that people click through, which is worse than not having it, because it produces an audit trail that looks like oversight while providing none.

The test worth applying: is this action hard to reverse, and is it rare? Both must hold. Merging code is reversible. Restoring a database over live data is not. Deploying is frequent; deleting an environment is not.

Production data destruction — restores, drops, bulk deletes.
Emergency and break-glass access to production systems.
Destructive infrastructure changes.
Changing the security controls themselves — audit logging, retention, alerting, key rotation.
Large or unusual payments.
Adding or removing administrators.

Implementing it so that it holds

Most software implementations record approvals as application state — a row saying that user A and user B approved. That is fine against honest mistakes, which is the majority of what you are defending against. It is weak against anyone who can write to that state, and it produces evidence that cannot be checked by an outside party.

The stronger construction is to make each approval a cryptographic signature, produced on the approver's own device, over a canonical description of the exact action. Verification then depends only on the signatures and the approvers' public keys. Nobody can manufacture an approval by editing a database, and the record stays checkable long after the fact.

This is how TeamSigner is built: keys are generated on each member's phone and never leave it, the server only ever holds public keys, and the webhook we deliver to your system contains the exact signed pre-image so you can verify it yourself without trusting us.

Common questions

Is the four-eyes principle the same as the two-person rule?

They are closely related and often used as synonyms. The two-person rule usually implies a stricter form, where two people must act together and neither can proceed alone, while four-eyes more broadly means two people must agree before an action takes effect.

Do compliance frameworks require it?

Frameworks such as SOC 2, ISO 27001, and PCI DSS generally require separation of duties and controlled change management rather than naming the four-eyes principle specifically. Dual approval on high-risk actions is a common and well-understood way to satisfy those requirements.

Does a pull-request review count?

It is a maker-checker control and a good one, but it governs code entering a branch, not actions taken against production. Deploys, database operations, and emergency access happen outside it.