Handle a Privacy Request
Before you start
dsr.create to record a request and dsr.update to fulfil one — fulfilment is
an update, not its own permission. Add dsr.read to review the queue. You also
need the subject identified as an entity.
1. Record the request
Capture its type, its subject, and when it arrived. The arrival date starts your statutory clock, so record it accurately even if you act immediately.
2. Identify the subject correctly
Identify the subject by searching before recording anything against them.
Resolve the request to one entity, not to a source record.
If the person still exists as several unmerged records, acting on one leaves the others untouched — and you will have told a regulator you erased data you did not.
Search before fulfilling. If duplicates exist, resolve them first. The whole purpose of mastering is that a privacy request has one target.
3. Fulfil it
Data subject requests, with the status and the clock each one is running against.
For an erasure request, fulfilment revokes every consent-based permission on the subject and retains those held under a basis that does not permit erasure.
The response records exactly what was revoked, what was retained, and the basis for each retention.
4. Read the outcome carefully
The retained items are not a failure. Data held under legal obligation or contract cannot be erased on request — erasing it would itself be a violation.
This record is what you show a regulator: erasure honoured to the extent the law requires, with each retention individually justified.
5. Close the request
Record the outcome and the date. The audit log carries the full trail independently, append-only, so the evidence does not depend on the request record alone.
Verify
- The subject resolved to a single entity.
- Consent-based records are revoked.
- Records under other bases are retained, each with its basis.
- The audit log carries the fulfilment.