When the regulator asks you to prove the data is unrecoverable, "we deleted it" is no longer the right answer.
The right-to-erasure question used to be procedural. The data subject asked. The records team ran a delete query. The system returned a confirmation. The audit log showed the deletion. The case was closed.
3 regulatory shifts changed the question:
- GDPR Article 17 moved the burden of proof to the data controller — you have to demonstrate the data is unrecoverable, not just that you intended to delete it.
- Schrems II raised the bar on cross-border data residency — the question of whether data is recoverable in another jurisdiction matters now.
- The Indian DPDP Act, the EU AI Act, the US state-level privacy regimes all converge on the same standard: cryptographically verifiable destruction.
The architectural answer is to make the data unreadable by destroying the key it was encrypted with. The encrypted bytes can persist in backup tapes, in log files, in offline archives — and remain mathematically unrecoverable.
Talk to the privacy solutions team · Read the GDPR Article 17 overlay · See the Crypto-Shred capability
What "cryptographic shredding" actually means.
Most platforms treat erasure as a deletion operation. The data is removed from the production database. The backup tapes still hold a copy. The offline archive still holds a copy. The audit log shows "deleted" but the data is recoverable from any of those secondary stores.
Crypto-shred is structurally different. The data was encrypted at write time with a tenant-specific key. When the erasure event fires, the key is destroyed. The encrypted data, wherever it persists, becomes mathematically unreadable.
| Stage | What crypto-shred requires |
|---|---|
| Per-tenant encryption | Each tenant has its own envelope encryption key |
| Key custody | Keys held in HSM-backed key custody, with two-person ceremony for destruction |
| Encrypted persistence | Data persists encrypted in production, backups, and archives |
| Erasure as key destruction | Erasure event triggers key destruction; data becomes unrecoverable everywhere it exists |
| Cryptographic proof | The destruction event is anchored to the audit ledger; proof is verifiable |
The difference between a deletion confirmation and a cryptographic proof is the difference between "we believe it's gone" and "the math proves it's gone."
Where this matters most.
The crypto-shred pattern is decisive for 3 categories of regulatory engagement.
| Regulatory pattern | What crypto-shred answers |
|---|---|
| GDPR Article 17 right-to-erasure | The data subject asks for erasure; the cryptographic proof closes the request defensibly |
| Cross-border data residency (Schrems II) | When data has to be unrecoverable in a specific jurisdiction, key destruction in that jurisdiction is the answer |
| Tenant offboarding | When a customer leaves a multi-tenant platform, the tenant's data becomes unrecoverable — a contractual and regulatory commitment that's actually verifiable |
| PHI right-to-erasure | HIPAA and the state-level privacy regimes converge on the same standard |
| Mandatory crypto-key escrow regimes | The customer-controlled-key option (CMK) lets the customer hold the key |
What changes for the privacy and security teams.
| Activity | Before crypto-shred | With TeamSync |
|---|---|---|
| Right-to-erasure response | Procedural delete + audit log | Cryptographic key destruction + proof |
| Backup-tape recovery risk | Real, persistent | Eliminated by key destruction |
| Cross-border data residency proof | Procedural | Cryptographic |
| Tenant-offboarding proof of destruction | "Trust our procedures" | "Verify the math" |
| Audit defensibility under GDPR Article 17 | Argument | Proof |
What's already in the architecture.
The crypto-shred capability is not an add-on. It's the consequence of the per-tenant envelope encryption that the platform uses by default.
| Architectural choice | What it enables |
|---|---|
| Per-tenant envelope encryption | Each tenant's data is encrypted with its own key |
| HSM-backed key custody | Keys held in hardware security modules, accessible only via attested operations |
| Two-person key destruction ceremony | No single operator can destroy a key unilaterally; the ceremony is anchored to the audit ledger |
| Customer-controlled keys (CMK) option | Customer holds the master key; TeamSync cannot decrypt without customer authorisation |
| BYOK / HYOK for sovereign deployments | For workloads with regulator-mandated key custody requirements |
How customers compare TeamSync.
The crypto-shred capability is uncommon in the regulated-content space. The closest comparisons:
- Microsoft Purview Customer Lockbox + Customer Key — strong inside M365; the cryptographic-proof argument is partial
- AWS KMS + S3 server-side encryption — strong on the cloud-storage layer; the document-platform integration and the right-to-erasure workflow need to be built
- In-house envelope encryption — most flexible; the operational ceremony, the audit anchoring, and the regulator-acceptance argument need to be built
For specific comparisons: - TeamSync vs SharePoint + M365- TeamSync vs Box
Read further.
- GDPR Article 17 overlay — the regulator-specific pack
- HIPAA overlay — the PHI right-to-erasure application
- RBAC + Backup capability — the underlying capability
- Why TeamSync — tamper-evident audit — the chain that anchors the destruction event