Four-Eyes, Audit Trails and the Retry Nobody Plans For

The four-eyes principle — vierogenprincipe — requires that a second person checks or approves an action before it takes effect. It is the oldest control in administration and the one most quietly weakened by automation, because automation removes the incidental second pair of eyes that used to be there by accident.

This is about designing controls that survive automation: where four-eyes genuinely belongs, what an audit trail must contain to be worth anything, and the failure mode that catches almost every integration project.

Where four-eyes actually belongs

Applied everywhere, four-eyes becomes ceremony: a second person clicking approve on things they cannot evaluate. That is worse than no control, because it produces a record showing scrutiny that did not occur.

It earns its cost in a small number of places, and the test is simple — could one person, acting alone, cause an irreversible loss or conceal one?

Changing supplier bank details. The highest-value fraud target in most organisations, and the change most easily disguised as routine maintenance.
Creating a supplier or customer combined with the ability to approve transactions for it. The combination is the risk, not either half.
Payment release above a threshold, and specifically release, not approval of the underlying invoice.
Changing the rules themselves — approval limits, tolerances, routing. This is the one most often forgotten, and it is the control that protects every other control.

That last point deserves emphasis. If one person can change the threshold above which four-eyes applies, then four-eyes does not really apply to anything. The configuration is part of the control surface, and in many systems it is edited without any of the scrutiny applied to transactions.

Segregation of duties is what four-eyes assumes

Four-eyes only works if the two people are genuinely independent. In a small finance team they frequently are not: the same person raises the order, receives the goods and approves the invoice, because there are four people in the department and one is on holiday.

This is a real constraint rather than negligence, and the honest response is compensating controls rather than pretending. Where you cannot separate duties, you can:

Make the record after the fact reviewable by someone outside the process — a monthly sample reviewed by a manager who did not participate.
Use system-enforced limits so that the unavoidable concentration of duties applies only below a value that caps the exposure.
Log and report the cases where one person did perform two roles, so it is visible and countable rather than invisible and routine.

What an audit trail must actually contain

Most systems log something. Far fewer log enough to answer the question an auditor or an investigator will ask, which is always some version of why did this specific thing happen, and who could have prevented it?

Who — the individual, not a service account, and not a shared login. A trail that ends at "system" or "admin" ends.
What changed — the before and after value, not just the fact of a change. "Bank details updated" is not an audit trail.
When, with a timezone, and ideally the sequence relative to other events rather than only wall-clock time.
On what authority — which rule, limit or delegation permitted it.
Immutability. If the trail can be edited by the people it records, it is documentation rather than evidence.

Two practical additions that are usually missing. Log the attempts that were refused, not only the actions that succeeded — a pattern of refused attempts is the most useful early signal you will get. And log configuration changes in the same trail as transactions, because separating them makes it impossible to reconstruct what the rules were at the moment an action was taken.

Retention, and the tension with data protection

Audit trails and data-minimisation obligations pull in opposite directions, and the resolution is to be deliberate rather than to keep everything forever.

Log the decision and its metadata rather than the full content of what was processed. For most controls, knowing that a specific user approved a specific transaction at a specific time under a specific rule is sufficient; retaining the personal data inside the document is usually not necessary and creates an obligation you did not need. Set a retention period per log type, deliberately, and make sure your logs are inside the scope of your deletion processes — logs are a common place where personal data survives a deletion request nobody thought to apply there.

The failure mode nobody plans for: the retry

Here is the automation-specific problem, and it catches almost everyone eventually. Systems retry. A network timeout, a queue redelivery, a user pressing submit twice — and the same instruction arrives at your system more than once.

If the receiving process is not idempotent — if executing it twice does not produce the same result as executing it once — a retry becomes a duplicate payment, a double order, a twice-applied credit note. The transaction was authorised once and executed twice, so every control upstream passed, and the audit trail records two legitimate-looking actions.

The defence is a stable identifier per logical operation, checked before execution. The sender generates it, the receiver stores it, and a second arrival with the same identifier is acknowledged and discarded rather than processed. It is not difficult, but it has to be designed in — and it is the specific question to ask a supplier building an integration for you: "how do you detect a duplicate, and on which key?" An answer that involves timestamps or content comparison is not an answer.

Designing controls that survive automation

Automated decisions need a sampling regime

A human making the same judgement fifty times a day gets some of them wrong, in scattered and uncorrelated ways. An automated rule making that judgement gets them wrong identically, every time, until someone notices. That is the trade automation makes: fewer errors, but errors that arrive in bulk and share a cause.

The control that matches this risk is periodic sampling — pull a small number of automated decisions each month and have a person check them properly. Not the exceptions, which already get attention; the ones the system handled cleanly and nobody looked at.

Sample across the range, not just the largest values. A systematic misclassification usually lives in a segment, not at the top.
Record the review itself in the audit trail. An undocumented review provides assurance to nobody later.
When you find an error, ask how long it has been happening before asking how to fix it. The answer determines whether this is a correction or a restatement.
Decide which actions are irreversible, and put the human checks there rather than distributing them evenly.
Treat configuration as part of the control surface, with the same scrutiny as transactions.
Log refusals and configuration changes alongside successful actions.
Require idempotency in every integration contract, with the key named.
Sample-review a small number of automated decisions monthly. Automation makes errors systematic rather than occasional, and a systematic error found late is much more expensive than the review.

How we approach it

Our €2,500 audit maps which actions in a process are irreversible, where duties genuinely cannot be separated, and what your current logs would and would not answer. That frequently changes the design before anything is built. Where a build follows, idempotency and the audit-trail contract are specified in the €20,000 proof of concept rather than discovered afterwards, and production starts from €50,000.

Frequently asked questions

What is the four-eyes principle?

A control requiring a second, independent person to check or approve an action before it takes effect. The point is that no single person can cause or conceal an irreversible loss on their own.

Applied everywhere it becomes ceremony — a second click by someone who cannot evaluate the item, which records scrutiny that did not happen.
It earns its cost on bank-detail changes, supplier creation combined with approval rights, payment release above a threshold, and changes to the rules themselves.
It assumes segregation of duties. In a four-person finance team that assumption often fails, and compensating controls are the honest answer.

What should an audit trail record?

Enough to answer why a specific thing happened and who could have prevented it: who did it, what changed from and to, when, and on what authority — and it must not be editable by the people it records.

"Bank details updated" is not an audit trail. The before and after values are the record.
Log refused attempts as well as successful ones; a pattern of refusals is the best early signal available.
Log configuration changes in the same trail as transactions, or you cannot reconstruct what the rules were at the time.

What is idempotency and why does it matter in automation?

An operation is idempotent when performing it twice produces the same result as performing it once. It matters because systems retry — timeouts, queue redeliveries, a user submitting twice — so the same instruction will eventually arrive more than once.

Without it, a retry becomes a duplicate payment or a double order, authorised once and executed twice.
Every upstream control passes, and the audit trail shows two legitimate-looking actions, so it is hard to detect after the fact.
The fix is a stable identifier per logical operation, stored by the receiver and checked before execution. Ask any integration supplier how duplicates are detected and on which key.

How do small teams handle segregation of duties?

By accepting the constraint and adding compensating controls rather than pretending the separation exists.

Have someone outside the process review a monthly sample — a manager who did not participate is enough.
Use system-enforced limits so the unavoidable concentration applies only below a value that caps exposure.
Log and count the cases where one person filled two roles, so the exception is visible rather than routine.
Keep the highest-risk change — supplier bank details — dual under all circumstances, even if it means involving someone from outside finance.