# Obligations as code paths, not PDFs

> A GDPR email API posture built in code: crypto-shred erasure, retention windows, consent and DPA tracking, EU residency tagging, and legal hold.

Canonical: https://emailfast.dev/features/compliance

## Compliance machinery, not compliance theater

For teams that need a GDPR email API, the obligations here are mechanical: erasure,
retention, consent, audit, and hold are code paths with defined behavior, not
policies asserted in a document and hoped about in production.

## How it works

| Obligation | Mechanism |
|---|---|
| Erasure | GDPR erasure by crypto-shred: destroying a key destroys the data it protected, without corrupting the tamper-evident audit ledger |
| Retention | Retention windows that age data out on schedule |
| Consent | Consent records tracked in-product, alongside DPA and subprocessor tracking |
| Residency | Data residency tagging — EU today |
| Audit | Tamper-evident hash-chained audit trails |
| Legal hold | Supersedes erasure while active; normal rules resume when it lifts |

Operator access is part of the record too: a vendor-access transparency log: a tamper-evident chain that records operator access, so “we never looked” is checkable, not promised.

## The evidence

:::panel The erasure/audit conflict, resolved
Erasure and auditability pull in opposite directions: one wants data gone, the other
wants history intact. Crypto-shred resolves the conflict — destroying a key destroys
the data it protected, while the audit chain keeps its integrity. You get a provable
"it's gone" and a provable "here's what happened," at the same time, about the same
events.
:::

## Honest limits

:::tradeoffs Scope, stated plainly
Residency tagging covers the EU today — we won't sell you regions that don't exist
yet. Legal hold beats erasure only while a hold is active, and that precedence is
documented rather than discovered. And no feature list makes you compliant: these
are mechanisms your process can rely on, not a substitute for having one.
:::

## Where to go next

The contractual side lives in the [DPA](/legal/dpa) and the
[privacy policy](/legal/privacy). Erasure and custody rest on the
[encryption layer](/features/encryption); the [enterprise door](/enterprise) has the
complete control picture. Comparing compliance-focused vendors? The
[Paubox comparison](/compare/paubox-alternative) draws the boundary honestly.

## How can you erase data and keep an audit trail at once?

GDPR erasure by crypto-shred: destroying a key destroys the data it protected, without corrupting the tamper-evident audit ledger. The record of events survives, and the personal data inside them doesn't.

## Do you offer a DPA?

Yes — the data processing agreement is published, and DPA status is tracked in-product alongside consent records and subprocessor tracking, so the paperwork and the system agree.

## Where does data live?

Data residency tagging covers the EU today. We state the region that exists rather than selling regions that don't yet.

## What wins: legal hold or an erasure request?

Legal hold, while it's active — held records survive deletion requests for as long as litigation requires, and normal erasure resumes when the hold lifts. The precedence is deliberate and visible, not a quiet exception.