What is the four-eyes principle?

The four-eyes principle is a control that requires a second person to review and approve a sensitive action before it executes. No single individual can carry out a high-risk change alone. The name comes from the idea that four eyes – two people – must see something before it proceeds.

Where does the four-eyes principle apply?

It applies wherever a mistake or an abuse of access would be difficult or impossible to reverse. Dropping a production database table, modifying an IAM trust policy, disabling a security alert, approving a large financial transfer – these are the categories that warrant a second pair of eyes. The common thread is that undoing the action requires significant effort, or cannot be undone at all.

It does not apply to routine work. Deploying a small bug fix to staging, reading logs, running a query against read-only data – none of these need an approval gate. The overhead would outweigh the protection.

Does requiring approval slow teams down?

It adds latency for the specific actions that require it, which is the point. Pausing before deleting production data is not a cost – it is the desired behavior. The question is whether that pause is measured in seconds or in hours.

Teams that feel bottlenecked by four-eyes are usually applying it too broadly, or routing approvals through slow channels. When every deploy requires approval, or every config change needs a ticket, the process becomes friction that people work around. That undermines the control entirely.

Applied narrowly to genuinely high-risk actions, the real-world latency is small. Most approval requests in a well-designed system are answered in under two minutes.

How do you apply four-eyes without creating a bottleneck?

Three things help. First, decide in advance which actions require approval and write the list down. If engineers have to guess whether something needs a second pair of eyes, they will guess wrong under pressure.

Second, keep the list short. A realistic list for a mid-sized engineering team might include: dropping or truncating production tables, changing IAM trust relationships, modifying or disabling security controls, rotating root credentials, and making changes to billing configurations. Ten to fifteen items at most.

Third, route approvals through a channel people already watch. Slack works well because it is asynchronous enough to not interrupt the approver, but fast enough that the requester does not sit idle. A Slack message with approve and deny buttons takes seconds to act on and leaves a record automatically.

What is the most common mistake?

Two opposite mistakes, equally common.

Applying four-eyes to everything. Teams that require approval for low-risk routine work train engineers to treat approval as bureaucracy. When the gate is always there, people stop thinking about whether it matters. They either route around it or approve things reflexively without reading them.

Applying it to nothing. Teams without any approval requirement for sensitive actions are one disgruntled engineer or one compromised account away from a serious incident. The absence of a control is not just a compliance gap – it means there is no moment where a second person could catch an error or question an intent.

The right calibration is a short, specific list, enforced automatically, reviewed occasionally to check whether the list still reflects where the real risk lives.

How is four-eyes different from audit logging?

Audit logging records what happened after the fact. It is valuable for forensics and compliance: when an incident occurs, logs tell you who did what and when. But a log cannot prevent an action from happening – it only makes the action visible in retrospect.

Four-eyes is a preventive control. It stops an action from executing until a second person has seen and agreed to it. The two controls complement each other: four-eyes reduces the chance of a harmful action happening at all, and audit logging ensures that if something does happen, there is a clear record.

Running both together is the standard approach for sensitive infrastructure actions. Korvalis applies this combination automatically for actions classified as destructive or high-impact, so teams get the protection without building the approval workflow themselves.