The channel is also a compliance event.
Article 30 processing records, Article 33 breach notifications, Article 35 DPIA supporting evidence — audit logs often contain the personal data they were created to document. When a Data Protection Authority opens an investigation, or when an external auditor requests evidence, those logs have to travel. Email is the default. Email is also a second data controller, a stored copy outside your retention schedule, and a new Article 32 risk surface.
The problem compounds when you need to demonstrate to the investigator that the evidence they received is the evidence you sent — that it hasn't been tampered with in transit. Standard email provides no such assurance. A breach on the transmission channel would be both an evidentiary problem and a second notifiable incident.
Burn-on-read delivery with a cryptographic receipt.
Paramant encrypts the audit package with ML-KEM-768 + AES-256-GCM. After the investigator or auditor downloads, the relay wipes its copy from RAM. The ML-DSA-65 signed receipt records the file hash, the recipient, and the delivery timestamp. That receipt is the chain-of-custody record: this package, this hash, delivered once, to this recipient, at this time.
The relay holds only ciphertext. It cannot read what it carries. EU/DE hosting means no US CLOUD Act production orders apply. The transmission does not create a second data controller for the audit evidence.
From export to evidence.
GDPR requirements satisfied.
| Requirement | Paramant control |
|---|---|
| GDPR Art. 32 — Appropriate technical measures | ML-KEM-768 + AES-256-GCM in transit; relay cannot decrypt; EU/DE hosting |
| GDPR Art. 5(1)(e) — Storage limitation | Burn-on-read: relay holds ciphertext only until first download, then wipes |
| Evidence integrity | ML-DSA-65 signed receipt with SHA-256 file hash; tamper-evident by construction |
| GDPR Art. 28 — Processor agreement | Pre-signed DPA available; relay does not process personal data (holds only ciphertext) |