Two-Person Approval for Sensitive Actions

Two-person approval, sometimes called the four-eyes principle, means a sensitive action does not take effect until a second, independent person agrees to it. It protects against mistakes, against a compromised account and against the rare insider who wants to do something they should not. It also has a cost: every approval is a delay. The skill is choosing which actions need it.

Which actions deserve a second person

A useful test is: would this be hard or impossible to undo, and would the damage be large if it were wrong? Typical candidates:

• Payments and refunds above a threshold, and any change to a supplier's or client's bank details.
• Permanent deletion of records, especially in bulk.
• Bulk exports of personal or client data.
• Access changes: granting admin rights, adding someone to a restricted matter, turning off a security setting.
• Outbound commitments: sending a formal notice, a settlement figure, a price change.

Everything else should flow without friction. If staff approve twenty trivial things a day, they will stop reading what they approve.

Design the check so it means something

1. The approver must be independent. Not the requester, and ideally not their direct report.
2. The approver sees what they are approving. "Approve change?" is useless. "Change payee account for Supplier X from ending 4411 to ending 9037, requested by Sam" is a real decision.
3. Verification uses a separate channel. Bank-detail changes requested by email are confirmed by phoning a number already on file, not the one in the email.
4. The decision is recorded: who asked, who approved or refused, when, and why.
5. There is a path when the approver is away. A named deputy, not a shared login.

Built-in safeguards help

Where software can enforce a pause, let it. In Herarx, Deletion Protection (Settings, Security) requires a confirmation code before anything is permanently deleted from Trash, and in an organisation turning it off is subject to a waiting period, so a single compromised session cannot quietly erase records. Organisation roles control who may delete, export or share outside at all, and a template rule can route a change to a named person to decide before it applies. The case timeline records what happened either way.

Tooling does not replace the design questions above, though. It enforces a rule; people still have to choose sensible rules. We covered the broader access picture in insider risk and access control for small teams.

Small teams can do this too

With three people, true independence is hard. Practical adjustments: the owner approves anything the owner did not request; the owner's own sensitive actions are reviewed after the fact by a colleague or an outside bookkeeper; and the log of those actions is reviewed monthly. Designing roles around tasks rather than seniority makes this easier; see roles, not plans.

Keep it from becoming a rubber stamp

• Review the list of approval-required actions twice a year and remove any that never catch anything.
• Track refusals. If nothing is ever refused, ask whether approvers are really checking.
• Occasionally test with a deliberate, harmless error and see whether it is caught.