Four-eyes per flow: what a second approver actually changes — and when a single-admin tenant may switch it off

The control everybody claims and few systems enforce

“Approved by a second person” appears in every ISMS policy, every DORA governance chapter, every NIS2 accountability slide. ISO/IEC 27001 Annex A 5.3 asks for conflicting duties to be segregated; DORA Article 5 puts the ICT risk framework under the management body’s approval; NIS2 Article 20 makes that body approve the risk-management measures and holds it liable. The control is universal. Its enforcement, in most tools, is a checkbox labelled “reviewed” that the author ticks.

Segregation of duties is only real when the system refuses the self-approval — not when a policy says it should not happen.

If the person who wrote the document can also mark it approved, you have a workflow, not a control.

Three flows, one rule

Not every action needs a second pair of eyes; the ones that change what the organisation asserts do. Three flows carry that weight in a compliance workspace:

1. Governance document approval — a policy, a framework document, a plan moves from draft to approved. What is being asserted: “this is what we do”.
2. Risk acceptance — a risk owner asks to accept a risk rather than treat it, for a period. What is being asserted: “we know, and we live with it until this date”.
3. Asset lifecycle — retire — an asset leaves the inventory. What is being asserted: “nothing depends on this any more”, which silently changes every compliance link and risk that pointed at it.

Each of these has a requester and a decider, and the rule is simply that they may not be the same person. Everything else — how many stages, which roles, what happens on rejection — is configuration on top of that one invariant.

What “approver” should mean

The second failure mode, after self-approval, is the over-privileged approver: to let someone approve a policy, the admin grants them full admin. Now the reviewer can also edit the document, change the risk score, delete the asset — and the segregation is gone in the other direction.

An approver role should be able to decide and nothing else: read the object, record the decision. No write, no delete, no user management. That is a deliberately small role — “approvers decide, never administer” — and it lets an organisation put a compliance officer, a legal reviewer or a CISO on the approval step without handing them the keys.

Two ideas that are easy to conflate: permission (may this role approve documents at all?) and assignment (is this person one of the approvers named on this request?). Both must be true. Permission without assignment is how a well-meaning admin approves something that was routed to someone else.

The single-admin problem — and the honest way out

Enforce requester ≠ decider absolutely and the very first tenant with one administrator dead-ends: every approval they raise, nobody may decide. Pretending that tenant does not exist helps nobody; silently letting them self-approve destroys the control for everyone.

The honest design is a per-flow toggle, on by default, that the tenant may switch off — with three properties that keep the exception from becoming a hole:

• It is per flow: relaxing risk acceptance does not relax document approval.
• The self-decision is still gated by assignment: the toggle never widens who may approve; it only permits the requester to be one of them.
• Every self-decision is audited as such: a distinct event, with a reason code saying four-eyes was disabled, so an auditor can list every approval that had one pair of eyes.

The residual risk is obvious and should be stated: the admin who wants to self-approve can flip the toggle themselves. It is compensated by the audited toggle write and the secure default, and it is a lot better than either absolute alternative.

Why this matters for the frameworks

• DORA — the management body “approves, oversees and is accountable”; the framework, the strategy and the third-party policy are governance documents that need a decision record with a decider distinct from the author. Risk acceptances with an expiry are exactly the “documented decision” supervisors ask about.
• NIS2 Article 20 — approval and oversight by the management body, with liability. A self-approved measure is not oversight.
• ISO/IEC 27001 A.5.3 and clause 9.3 — segregated duties and management review; the auditor will pick a document and ask who approved it and whether that person could also have written it.

In Secantra

The workflow engine enforces requester ≠ decider on the three flows above (governance document review, risk acceptance, asset retire); a self-approval attempt is refused, not merely warned about. Three built-in approver roles — governance-approver, risk-approver, asset-approver — carry only read plus the approve permission for their domain, and a decision also requires an approver assignment on the request. Four-eyes is a per-tenant, per-flow setting, on by default; a permitted self-decision writes a distinct audit event with the reason code. Governance documents can run multi-stage approvals (a legal, a security and an executive stage in sequence), each stage bound by the same rule.

Checklist

• Every approval flow names a requester and a decider, and the system refuses when they coincide
• Approver roles can decide and read — nothing else
• Permission to approve and assignment on the specific request are both required
• The single-admin exception is a per-flow, audited, secure-by-default toggle — never a silent bypass
• Every self-decision is distinguishable in the audit trail