Anyone who has ever lived through an ISO 27001 or NIS-2 audit knows two recurring finding classes: "segregation of duties not demonstrable" and "evidence preservation in incidents not systematically regulated". Both can be solved technically and elegantly – with a four-eyes approval flow for security-critical mail releases and an immutable forensic archive.
Four-Eyes Approval: What It Means Technically
A quarantined mail contains, say, a sandbox threat detection or a DLP hit. Instead of an admin clicking "release" and the mail going out, the process runs as follows:
- Operator A opens the quarantine, reviews the verdict, and requests a release.
- Operator B (different user, different account) receives an approval entry in their queue.
- B reviews independently, sees the same verdict, the same attachments, the same CTI hits – and approves or rejects.
- Only after approval is the release possible; without approval the gateway returns 403.
Which verdicts trigger a four-eyes approval is configurable (default: virus, sandbox_threat, policy_violation). Approvals expire – default 24 hours – so "old" approvals cannot be recycled for later, independent releases.
What This Brings in an Audit
- ISO 27001 A.6.1.2: Segregation of duties – technically enforced, instead of merely documented in a policy.
- NIS-2 Art. 21 (2)(d): Measures for supply chain security and business continuity – release approvals are a logged control point.
- BSI IT-Grundschutz ORP.1.A14: Dual control on security-critical actions – gut feeling vs. demonstrably documented.
Forensic Archive: WORM with Object Lock
Quarantine is short-lived: mails disappear after 30–90 days. What remains for forensics 12 months later? Answer: a forensic archive with real compliance properties:
- S3-compatible with object lock COMPLIANCE mode: Once written, nothing and no one can delete the object before retention expires – not even the storage account's root user.
- DB index parallel to blob storage: search by sender, recipient, subject, connection ID, verdict – without deserializing the blob.
- Pre-signed URLs for download: an auditor receives a 60-minute link that becomes useless after expiration.
- Default retention: 365 days, configurable per verdict class (phishing suspicion: 6 months; virus: 24 months).
Interaction with the Audit Log
Both building blocks feed into the same audit_log table. Who read which quarantined mail when? Who requested which release approval, who approved? Who downloaded which mail from the archive? All seamless, all queryable in the UI – and, when needed, exportable as CSV to hand to the auditor.
Why You Don't Just "Build It Yourself"
The temptation is great: a few SQL tables, a Trello board for approvals, an S3 bucket with a lifecycle policy. In practice, this fails on race conditions (two approvers at once), on silent data mutation (S3 without object lock allows overwrites), and on missing UI integration with the quarantine workflow. An integrated solution like SecTepe.Comm saves the 200 person-hours the in-house project ends up demanding.
Conclusion
Four-eyes principle and audit-proof forensic archive are the two building blocks that surface in nearly every audit report as improvement potential. Solving them in a clean, usable way is possible – when they are planned as part of the mail security platform, not as an afterthought bolt-on. The effort for activation in SecTepe.Comm: two clicks and a storage backend configuration. The auditor says thank you.