Automating GDPR Data Subject Requests and Data Exports in SaaS

Data mapping is the prerequisite

You cannot export or erase what you cannot find. A personal data inventory records, for each data category, which system holds it, the purpose of processing, the lawful basis, the retention period and which processors receive it.

The inventory must include the places teams forget: application logs, error trackers, analytics events, message queues, search indexes, caches, data warehouses and backups. Personal data in logs is the most common gap and the most common source of an incomplete response.

Keep the inventory as a maintained artefact tied to architectural change, not as a document produced once for a compliance project. A mapping that diverges from reality is worse than none, because it creates false confidence.

• Record system, purpose, lawful basis, retention and processors per data category.
• Include logs, analytics, queues, caches, indexes and backups.
• Update the inventory when architecture changes.
• Assign an owner to each data category.

The request workflow

A workable workflow has five steps: intake and logging, identity verification, data assembly, review, and delivery with an audit record. The statutory deadline is short, so intake must log the request immediately so the clock is measurable.

Identity verification must be proportionate. For a low-sensitivity request within an authenticated session, the session itself may be sufficient. For a request made by email or covering sensitive data, stronger verification is needed, and the verification evidence should be recorded.

Where a request involves data about the requester that also contains information about other people, redaction is required. Design the export to support redaction rather than producing a document that must be manually edited.

One export pipeline

Access, portability and internal investigations all need the same underlying capability: given a subject identifier, collect everything about that subject from every store and produce a structured document. Build that once and reuse it.

Design the export to be machine-readable and human-readable. Structured formats such as JSON or CSV satisfy portability, while a summary document makes the response usable. Include metadata describing what was included, what was excluded and why.

Make the pipeline asynchronous with progress tracking, because assembling data from many stores is slow and occasionally partially fails. Record per-store success or failure so an incomplete export is visible rather than silently truncated.

• Build one subject-data assembly capability and reuse it.
• Produce both structured and human-readable output.
• Record what was included and excluded, with reasons.
• Track per-store completion and surface partial failures.

Erasure and provable deletion

Erasure must cover primary data, derived data, search indexes, caches and analytics, and it must contend with backups where immutability prevents individual deletion. The usual approach is documented retention: backups are excluded from per-subject deletion, expire on a defined schedule, and restore procedures reapply the deletion list.

Provable deletion means recording that deletion occurred, when, and by which mechanism, without retaining the deleted data. A deletion ledger keyed by a pseudonymous identifier gives you evidence without reintroducing the personal data you removed.

Finally, propagate deletion to processors. A deletion that removes data from your systems but leaves it with an analytics or email provider is not deletion, and the processor list from the data inventory is what makes propagation possible.

• Cover derived data, indexes, caches and analytics in deletion.
• Document a retention exception for immutable backups.
• Reapply deletion lists on restore.
• Maintain a deletion ledger and propagate to processors.