Four-Eyes Principle and Forensic Archive: Two Building Blocks Almost Every Audit Asks About

If you have been through an ISO 27001 or NIS-2 audit, you know two findings that come up again and again: "segregation of duties not demonstrable" and "evidence preservation in incidents not systematically regulated". Both have a clean technical fix. The first is a four-eyes approval flow for releasing high-risk mail. The second is a forensic archive that no one can change.

Four-Eyes Approval: How It Works

Say a mail sits in quarantine because of a sandbox threat or a DLP hit. An admin does not just click "release" and send it out. Instead, the process runs like this:

1. Operator A opens the quarantine, checks the verdict and asks for a release.
2. Operator B (a different user with a different account) gets an approval entry in their queue.
3. B checks on their own. B sees the same verdict, the same attachments and the same CTI hits, then approves or rejects.
4. The mail can only be released after approval. Without it, the gateway returns 403.

You choose which verdicts need a four-eyes approval (default: virus, sandbox_threat, policy_violation). Approvals expire after 24 hours by default. So no one can reuse an "old" approval for a later release that has nothing to do with it.

What This Gives You in an Audit

• ISO 27001 A.6.1.2: Segregation of duties. The system enforces it, so it is more than a line in a policy.
• NIS-2 Art. 21 (2)(d): Measures for supply chain security and business continuity. Each release approval is a logged control point.
• BSI IT-Grundschutz ORP.1.A14: Dual control on high-risk actions. You can prove it in writing instead of relying on gut feeling.

Forensic Archive: WORM with Object Lock

Quarantine does not last. Mails are gone after 30 to 90 days. So what is left for forensics 12 months later? The answer is a forensic archive with real compliance features:

• S3-compatible with object lock in COMPLIANCE mode: Once an object is written, no one can delete it before the retention period ends. That includes the root user of the storage account.
• DB index next to the blob storage: Search by sender, recipient, subject, connection ID or verdict. You do not need to unpack the blob.
• Pre-signed URLs for download: An auditor gets a link that works for 60 minutes. After that, it is useless.
• Default retention: 365 days. You can set it per verdict class (suspected phishing: 6 months; virus: 24 months).

How It Ties into the Audit Log

Both features write to the same audit_log table. It answers questions like these:

• Who read which quarantined mail, and when?
• Who asked for which release approval, and who approved it?
• Who downloaded which mail from the archive?

You can search all of it in the UI with no gaps. When needed, you can export it as CSV and hand it to the auditor.

Why You Don't Just "Build It Yourself"

It is tempting. A few SQL tables, a Trello board for approvals, an S3 bucket with a lifecycle policy. In practice, this fails for three reasons:

• Race conditions, when two approvers act at the same time.
• Silent changes to data, because S3 without object lock lets you overwrite files.
• No link in the UI to the quarantine workflow.

A built-in solution like SecTepe.Comm saves you the 200 person-hours that a home-grown project ends up costing.

Conclusion

The four-eyes principle and an audit-proof forensic archive show up in almost every audit report as areas to improve. You can solve both in a clean way that people can actually use. The key is to plan them as part of the mail security platform, not to bolt them on later. Turning them on in SecTepe.Comm takes two clicks and setting up a storage backend. Your auditor will thank you.