Data Subject Rights
Access, correction, portability and erasure across systems that never planned for them.
4 to work through
-
intermediate
A regulator asks how long after an erasure request the data is genuinely gone. Production deletes in seconds; backups are daily with 35-day retention; the warehouse is fed by change data capture; the search index rebuilds weekly; three processors hold copies. Roughly what number do you give and what does it rule out?
2 min answer -
advanced
Design the architecture for handling access, correction and erasure requests across a large estate.
1 min answer -
advanced
You receive a subject access request. Legal says you have 30 days to produce everything you hold about this person. What does your architecture need to make that possible?
2 min answer -
advanced
Your organisation receives its first subject access request. Nobody knows where the person's data is. How do you respond within thirty days?
2 min answer
4 terms in this topic
Data Subject Access Request
An individual's request for a copy of the personal data an organisation holds about them, which must be fulfilled completely within a statutory deadline.
metricDeletion Horizon
The elapsed time after an erasure request until the last copy of the record is gone or unreadable, set by the longest-lived derived copy rather than …
practiceSubject Access Fulfilment
The operational path from a request to a complete, verified, delivered response within the statutory period, across systems that were never designed …
patternSuppression List
A durable record of identifiers that must not be re-ingested, preventing an in-flight or replayed pipeline from recreating data that was just erased.
Neighbouring topics
Regulatory & Data Protection Architecture
General material on designing under legal and regulatory obligation.
Privacy by Design
Data minimisation, default protection and purpose binding as structural decisions.
Lawful Basis & Purpose Limitation
Why you may hold the data, and why that forbids the second use somebody proposed.
Consent Architecture
Capturing, versioning and propagating consent to every system that acts on the data.
Data Residency
Keeping data within a jurisdiction, including backups, logs and support access.
Digital Sovereignty
Control over data, operations and the operator, beyond where the bytes physically sit.
Cross-Border Transfer
The legal mechanism that permits data to leave, and the architecture that respects it.
PCI-DSS Scoping
Segmentation and tokenisation to shrink what is in scope, because scope is the cost.
Healthcare Data Protection
PHI handling, minimum necessary access, and audit expectations in clinical systems.
Financial Services Regulation
Operational resilience, payment rules and supervisory expectations as design inputs.
Records Retention & Legal Hold
Keeping what must be kept, deleting what must go, and freezing both on demand.
Erasure vs Immutability
Deletion obligations against event logs, backups and ledgers designed never to forget.
Pseudonymisation
Separating identity from record, and the re-identification risk that remains.
Privacy-Enhancing Technologies
Differential privacy, secure enclaves and federated computation, and what each buys.
Regulatory Reporting Pipelines
Submissions with fixed deadlines, fixed formats, and a regulator who audits the lineage.
Sector Cloud Rules
Regulator expectations for cloud use, exit plans and material outsourcing notification.
Exit & Concentration Risk
Being able to leave a provider, and what the regulator asks when you cannot.
Third-Party Risk
Assessing, contracting and monitoring the vendors your architecture now depends on.
Geo-Restriction & Sanctions
Blocking access by jurisdiction, and the accuracy and evasion problems that come with it.