GDPR Article 17: Managing the Right to Erasure
GDPR Article 17, often called the Right to Erasure or Right to Be Forgotten, gives individuals the right to request the deletion of their personal data in certain circumstances
For organizations, responding to these requests involves more than deleting records from production systems. Data may also exist in backups, archives, snapshots, and other storage locations. Demonstrating that personal data has been appropriately handled is an important part of meeting regulatory expectations.
TeamSync helps organizations manage erasure requests, maintain audit records, and support compliance workflows across the data lifecycle.
What Article 17 Requires
GDPR Article 17 (the right to erasure, or "right to be forgotten") allows for erasure on six grounds. The architectural requirements are similar across all of them:
Ground for erasure | What it means in practice |
No longer necessary | The personal data is no longer needed for its original purpose |
Withdrawn consent | The data subject withdrew the consent the processing relied on |
Objection to processing | An Article 21 objection that overrides legitimate interest |
Unlawful processing | The processing was unlawful from the start |
Compliance with legal obligation | EU or member-state law requires erasure |
Child consent revocation | Personal data of a child collected under Article 8 |
The controller must act "without undue delay", and must be able to demonstrate compliance, not just claim it.
What "Demonstrating Erasure" Actually Requires
Supervisory authorities now expect evidence covering more than just the primary system:
Evidence type | What it actually requires |
Production-system erasure | Standard and well established |
Backup-tape erasure | Either deletion at next restoration, or cryptographic erasure |
Offline-archive erasure | Procedural deletion is often impossible here; cryptographic erasure is the practical answer |
Snapshot-system erasure | Same challenge as archives |
Cross-jurisdiction erasure | Deletion needs to extend across every region where data was processed |
Third-party-processor erasure | Deletion needs to be coordinated across the full processor chain |
Verification by the data subject | The individual can request proof of erasure |
Verification by the supervisory authority | The DPA can request the same |
Most procedural deletion systems handle production-system erasure well, the next four only partially, and rarely address verification at all.
How TeamSync Covers Each Requirement
Requirement | TeamSync implementation |
Production-system erasure | Native, at the per-document or per-data-subject level |
Backup-tape erasure | Cryptographic — the encryption key is destroyed, making backups unreadable |
Offline-archive erasure | Same cryptographic mechanism applied to archives |
Snapshot-system erasure | Same mechanism, with snapshot-specific encryption keys destroyed |
Cross-jurisdiction erasure | Per-region key destruction with a per-region audit trail |
Third-party-processor coordination | A sub-processor coordination workflow with audit anchoring |
Verification | Cryptographic proof that a DPA's own tooling can verify |
Audit trail | Every erasure event is anchored to the audit chain |
How The Mechanism Works
TeamSync uses per-tenant envelope encryption by default. Each tenant's data — and within a tenant, each data-subject category — is encrypted with its own key. Erasure works by destroying that key through a two-person process:
Stage | What happens |
1. Erasure request received | A workflow opens and the request scope is documented |
2. Scope validated | The data subject's data is identified across the platform |
3. Two-person process | Key destruction requires two operators with separate authorities |
4. Key destruction | The data-encryption key is mathematically destroyed |
5. Audit anchor | The destruction event is anchored to the cryptographic chain |
6. Verification artifact | A generated artifact that both the data subject and the DPA can verify |
The encrypted data can remain wherever it exists; it's simply unreadable, and the proof of that is mathematical rather than procedural.
What Changes For The Privacy Team
Activity | Before | With TeamSync |
Right-to-erasure response | Procedural deletion + audit log | Cryptographic key destruction + verifiable proof |
Backup-tape recovery risk | Real and persistent | Eliminated by key destruction |
Cross-region erasure proof | Procedural | Cryptographic |
DPA inquiry response | Procedural narrative | Mathematical proof |
Sub-processor erasure coordination | Spreadsheet | Workflow with audit anchor |
Annual erasure-program audit | Multi-week project | Generated artifact |
What Else Runs On The Same Platform
Capability | Role inside Article 17 compliance |
RBAC + Backup | The crypto-shred mechanism |
Intelligent Repository | The records platform the erasure operates on |
Audit ledger | The chain that anchors the destruction event |
Business Process Automation | The erasure workflow, including the two-person process |
eDiscovery | The hold mechanism that respects active legal holds preventing erasure |
This matters because the erasure mechanism has to work correctly alongside active legal holds (data under litigation hold can't be erased), the audit chain (the destruction itself is logged as an event), and the workflow engine (which enforces the two-person process).
How TeamSync Compares
When evaluating Article 17 solutions, TeamSync is typically compared with:
Microsoft Purview Customer Lockbox + Customer Key — strong within M365, though the cryptographic-proof story is only partial
AWS KMS / Azure Key Vault with manual erasure workflows — strong at the key-management layer, but the document-platform integration and workflow need to be built separately
In-house envelope encryption — the most flexible option, though the operational process, audit anchoring, and regulator-facing proof still need to be built from scratch
For specific comparisons: TeamSync vs SharePoint + M365