Fulfills erasure from a system inventory, pauses work under legal hold, lets backups expire, and records fulfillment evidence, treating GDPR Article 17 as jurisdiction scope rather than a certification claim.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
Erasure is inventory-driven, not a single user-row delete. The operator walks store classes in system-inventory.yaml and records per-class erased, anonymized, retained-under-exception, or blocked-by-legal-hold. An active legal hold pauses fulfillment. Backups are not surgically edited; they age out under documented retention. Evidence lists class, method, time, and actor. This block covers personal data of an identified subject in the EU/EEA under GDPR Article 17. It is not certification, adequacy, or legal advice.
Scope
- Intake, identity verification, inventory sweep, hold checks, and evidence.
- Store classes that must be covered before
fulfilled. - Backup expiry versus live-store erasure.
- Jurisdiction: EU/EEA GDPR Article 17 as adopted by this program.
Outside this block
- Generic soft-delete grace, except erasure may shorten grace when required.
- Audit-log internals except named retain exceptions.
- How log redaction is implemented beyond listing logs as a class.
Contract
- A request cannot become
fulfilledwhile any inventory class isnot-startedorin-progress. - An active hold for the subject sets
paused-legal-holdand skips live erasure of contested records. - Primary data, search, object storage, caches, queues, replicas, analytics extracts, and subprocessors each have an explicit outcome.
- Backups record
expire-by; live fulfillment may complete while backup expiry is pending only if evidence states restores will re-apply erasure. - Evidence is append-only after fulfill, with a digest of the inventory version.
- The package claims no ISO or GDPR certification and no supervisory approval.
Implementation
Verify the subject, then run an idempotent worker per class. Ticket subprocessors and store the ticket id. Restore runbooks must re-apply open or fulfilled erasure lists. Named Article 17 exceptions are retain reasons, not silent skips.
Failure handling
Class API failure keeps the request open. Failed identity verification starts no erasure. Hold release resumes remaining classes. A backup restore after fulfill opens a re-apply task. Evidence must not email identity documents.
Verification
Every inventory class must appear on a fulfilled fixture. Fulfill during hold must pause. Staging tenants must contain no real personal data. Human DPO review is required before production policy use. Execute the packaged scenarios.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.