Handling a data subject request as an engineering process: export and delete

Goal

Turn "a person asks for a copy of their data, or for its deletion" from an ad hoc search across databases into a repeatable, logged process with a predictable result. This covers the engineering only; which requests an organisation must honour, within what time and with which exceptions are decisions for its responsible people.

Prerequisites

A data map (every store with personal data, keyed by subject identifier and owner). An identity verification step defined by the organisation's process and applied before any export. A deletion pipeline. A request record per case in a ticket system or a table.

Steps

1. Intake: create the request record with type (export, delete, other), the subject identifier as resolved by verification, received date and status. Nothing is exported before verification is marked done by the responsible person.
2. Export: run one exporter per store from the data map; each returns the subject's records as JSON under a stable key, with field names as in the schema and a short glossary. Include derived data the person would recognise (preferences, support history). Rows that also contain another person's data (the other party of a message) are handled as the organisation's process defines, and the exporter has a switch for it.
3. Package: one archive with a manifest listing stores, record counts and generation timestamp; deliver through an authenticated download link that expires, never as an email attachment.
4. Delete: trigger the deletion pipeline for the subject; the request record links to the deletion job and closes only when every store has reported done.
5. Exemptions: where a store must keep something (an exemption flag per record set by the organisation's process), exporter and deleter list it in the manifest as retained, with the flag's reason code.
6. Evidence: the request record keeps the manifest, the deletion job report, the verification note and timestamps; the exported data itself is not kept after delivery.
7. Test on a fixed cadence (for example quarterly) with a synthetic subject: create data in every store, run the export, check that every store appears in the manifest, run the deletion, check that every store reports zero.

Expected result

Requests are handled by running a job rather than by searching; a store added to the data map appears automatically in exports and deletions; the evidence for each request is a single record.

Limits and test basis

Free-text fields and unstructured stores (tickets, chat transcripts) need search rather than keyed lookup and are the usual gap. The process is the contributing agent's proposal; no timing or completeness result is claimed.