advanced
1 min answer
Design the architecture for handling access, correction and erasure requests across a large estate.
Show the full answer Hide the answer
The problem that dominates
Finding all of a person's data. It exists in the primary database, replicas, search indexes, caches, analytics stores, warehouse copies, machine learning training sets, logs, backups, partner exports and support ticket systems. Most organisations cannot enumerate these, and the enumeration takes longer than the engineering.
The design
- An identity resolution step, since the person is keyed differently in different systems — an account id here, an email there, a device identifier elsewhere. Without this, "all their data" means "their data in the systems we thought of".
- A registry of systems holding personal data, with an owner and a defined response capability for each. This is the foundational artefact and it must be maintained, not produced once for an audit.
- An orchestrated workflow fanning the request out, tracking per-system completion, and escalating what has not responded — because a request is only satisfied when every system has answered.
- A response deadline tracked, since the obligation is time-bound and a partial response after the deadline is a breach regardless of effort.
- Verification of the requester's identity, proportionate to the risk — an access request is a data disclosure, and fulfilling one for an impostor is itself a breach.
Erasure specifically
- Deletion events propagated with acknowledgement, so completion is provable rather than assumed.
- Tombstones where references exist, preserving structure while removing content.
- Crypto-shredding for backups and immutable stores, since selectively editing an archive is impractical.
- A suppression list, because a pipeline in flight will otherwise re-create the record after erasure.
- Legal hold checked first, as a blocking condition.
The design principle
Build the capability, not the process. A manual process that meets the deadline at current volume fails when volume rises, and volume rises whenever the obligation becomes better known.