What is the Four-Eyes Principle?
The Four-Eyes Principle is a control principle in which critical actions only take effect once a second, independent person has reviewed and approved them. Originally known from finance, it is now a standard building block of security-critical IT processes: one person requests or prepares a change, another decides whether to approve it. That reduces careless mistakes, makes unauthorised or malicious changes harder, and produces a documented approval record as a side effect. In IT operations, the principle is typically implemented as an approval workflow: request, review, approval or rejection, each with a timestamp and justification. For how a requested rule change is automatically checked against real usage patterns before approval, watch our video on the preview feature.
The Four-Eyes Principle in detail
Technically, the Four-Eyes Principle needs three things: an enforced separation between the requester and the approver (the same person cannot be both), a workflow that holds the change back until approval, and logging that links the request, the decision and the implementation. What matters is enforcement within the system itself: an approval given verbally or over chat only appears to satisfy the principle, because it is neither enforced nor provable.
The principle should be distinguished from general segregation of duties, which permanently distributes tasks across roles. The Four-Eyes Principle applies on a per-case basis and can be scoped deliberately to the changes that carry real potential for harm: new grants, deletions, policy changes. For emergencies, a defined exception path belongs alongside it, reviewed after the fact.
Why the Four-Eyes Principle matters in Zscaler operations
In Zscaler operations, policy changes take effect immediately and globally: a wrongly set block rule hits every user within minutes, an overly broad grant opens up access unintentionally. Changes exactly like these are the classic use case for a second review. The principle also enables a sensible division of labour: the helpdesk or 2nd Level can prepare and request changes without holding privileged rights themselves; the decision stays with a small number of authorised people.
There is also the evidence angle: NIS2 and DORA require controlled, provable processes for security-relevant changes. A Four-Eyes Principle enforced by the system delivers this evidence as a side effect, because every critical change documents who requested it, who reviewed it, and when it took effect. The relevant national implementation and supervisory practice remain decisive for the details.
Common sources of error
- Approval as a formality: confirming without reading satisfies the principle only on paper. The approver needs context and time.
- Request and approval by the same person: shared accounts or overly generous roles undermine the separation.
- Approvals outside the system: agreements made by email or chat are neither enforced nor traceably logged.
- Making everything subject to approval: requiring review for every small thing creates fatigue and rubber-stamped approvals. Better to cover only critical changes, plus a defined emergency path.
The Four-Eyes Principle in practice: what CentaurNexus contributes
CentaurNexus implements the Four-Eyes Principle as an optional approval workflow for write actions in Zscaler operations: the helpdesk requests a change, an authorised person reviews and approves it, and only then is it carried out; every step lands in the append-only audit trail. With Change Effect Preview, a requested policy change can also be checked in advance against real usage patterns before it is approved and activated. That lets even teams without Zscaler admin rights contribute safely, without control being lost. For how analysis, approval and clean-up work together, see the guide Finding and cleaning up unused Zscaler rules.
Related terms
Frequently asked questions about the Four-Eyes Principle
Critical actions such as policy changes, grants or deletions are only carried out once a second, independent person has reviewed and approved them. This is implemented as an approval workflow in the system: request, review, approval, each logged. That reduces errors and misuse, while producing a solid approval record.
Neither framework mandates the principle by name, but both require controlled access and change processes with evidence. A Four-Eyes Principle enforced by the system is a recognised, easily provable way to meet these requirements for critical changes. The relevant national implementation and the expectations of the responsible supervisory authority are decisive.
Through a workflow that holds changes back until approval, an enforced role separation between requester and approver, and unbroken logging of the request, the decision and the execution. Deputy rules and a defined emergency path also matter, so urgent fixes stay possible and get reviewed after the fact.
Segregation of duties permanently distributes tasks across different roles, for example administration and control. The Four-Eyes Principle applies per case: a specific change needs a second decision before it takes effect. In practice, the two work together; segregation of duties supplies the roles, and the Four-Eyes Principle supplies the review step for each individual case.
Barely, if scoped correctly. What matters is making only changes with genuine potential for harm subject to approval, and integrating the workflow into the tool people already work in, so review and approval take minutes rather than days. A defined emergency path with after-the-fact review makes sure urgent interventions are never blocked.
- Directive (EU) 2022/2555 (NIS2), requirements for risk management and access control - eur-lex.europa.eu
- Regulation (EU) 2022/2554 (DORA), ICT risk management in the financial sector - eur-lex.europa.eu
- BSI IT-Grundschutz, module ORP.4 identity and access management - bsi.bund.de/.../ORP_4
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners.