Erasure Domain

Overview#

A former employee of a financial services firm submits a GDPR Article 17 right-to-be-forgotten request, citing that the firm retains personal data that is no longer necessary for the original processing purpose. The firm's data protection officer needs to verify the request, check that no active legal hold prevents erasure, remove the individual's personal data from user records, and issue a tamper-evident receipt proving the erasure was completed. The Erasure domain handles every step of that workflow.

GDPR Article 17(3)(e) creates a specific tension: the right to erasure must be balanced against the obligation to maintain audit trail integrity for legal proceedings. The domain resolves this by anonymising actor fields in audit records rather than deleting rows, preserving the evidential integrity of the audit trail while removing personal identifiers.

Key Features#

GDPR Article 17 erasure request submission with identity verification
Legal hold checking before erasure execution to prevent deletion during active proceedings
PII anonymisation across user records and audit events using deterministic placeholders
Tamper-evident erasure receipt generation for compliance documentation
Deterministic anonymisation placeholders for data consistency across related records
Blind index-based email lookup for subject identification without exposing raw PII
Audit trail preservation through field anonymisation rather than row deletion
Erasure lifecycle management (request, verification, execution, receipt)

Use Cases#

Processing GDPR right-to-be-forgotten requests end to end, from identity verification through tamper-evident receipt issuance
Anonymising PII across user records while preserving audit trail row integrity per Article 17(3)(e)
Generating tamper-evident receipts that demonstrate completed erasure operations to data protection authorities
Managing the complete erasure lifecycle with legal hold checking to prevent premature erasure of records subject to active proceedings

Industry Context#

Financial services firms, healthcare providers, and government agencies operating in EU jurisdictions must demonstrate compliance with data subject erasure requests. Telecommunications companies handle high volumes of erasure requests from subscribers after contract termination. Legal technology platforms must balance erasure obligations against the need to retain court filing records. Intelligence agencies operating under national data retention frameworks use similar anonymisation patterns to satisfy oversight requirements while preserving operational audit trails.

Integration#

Integrates with user management, audit trail, and legal hold systems for GDPR-compliant data erasure workflows. PostgreSQL stores all erasure request records and receipts. Blind index lookups enable subject identification without exposing plaintext email addresses in query logs.

Open Standards#

GDPR Article 17 (EU Regulation 2016/679): The domain implements the full right-to-erasure lifecycle mandated by Article 17, including request submission, identity verification, legal hold checking, PII removal, and issuance of a tamper-evident receipt.
GDPR Article 17(3)(e), Audit Trail Exception: Rather than deleting audit event rows, the domain anonymises actor identifiers in place, satisfying the Article 17(3)(e) carve-out that permits retention of records held under a legal obligation or for reasons of public interest in security.
FIPS 180-4, SHA-256: SHA-256 is used for blind-index email lookup (avoiding plaintext PII in query logs), for the canonical tamper-evident receipt hash, and as the basis for deterministic anonymisation placeholder tokens.
RSASSA-PKCS1-v1_5 / RS256 (RFC 3447, PKCS#1 v2.2): Erasure receipts are signed with an RS256 key sourced from the platform key-rotation manager, producing a verifiable signature over the canonical receipt JSON to prove receipt authenticity to data protection authorities.
JSON Web Token (RFC 7519) and Bearer Token Usage (RFC 6750): Cross-service erasure dispatch to the auth service is authorised via a scoped service JWT presented as a Bearer token, with the gdpr:erasure scope limiting the credential to that single operation.
ISO 8601 / RFC 3339, Date and Time: All request lifecycle timestamps (requested_at, started_at, completed_at) and receipt fields are stored and serialised in UTC ISO 8601 format, enabling interoperability with compliance tooling and data protection authority reporting systems.
GraphQL (June 2018 specification): The erasure API surface, submitting requests, executing erasure, and retrieving receipts, is exposed as a typed GraphQL schema with mutations and queries, providing a self-documenting interface for integrating data protection workflows.
JSON (RFC 8259): Canonical receipt payloads, cross-service dispatch bodies, and per-table erasure manifests are serialised as RFC 8259 JSON with sorted keys, ensuring deterministic representation for hashing and signature verification.

Last Reviewed: 2026-02-24 Last Updated: 2026-04-14