Answer a GDPR data-subject request within 30 days

When to use

Any person — customer, ex-employee, job applicant, website visitor — asks what data the company holds on them, or asks to correct, delete, restrict, export it, or objects to processing. Not for a suspected personal-data breach — use tech.security-audit. Not for maintaining the register of processing activities itself — use company.gdpr-register. A request may arrive addressed to anyone in the company; once recognized, this playbook takes over.

Before you start

• The date the request was received is known (any channel counts; a phone call is logged the same day).
• The company knows its role: controller for its own customer/employee data, processor for client data —
• The requester's identity can be checked if there is reasonable doubt (Art. 12(6)) — but no new data may be

What a run requires2

The trail8 steps

1. S1

   Log the request the day it is seenagent

   Record: requester, date received, channel, which right is invoked (access, rectification, erasure, restriction, portability, objection), verbatim text. Compute the deadline: one month from receipt; if the month has no equivalent day, the last day of that month.

   Done when the request log entry exists with the received date and the deadline date. ⛔ "Received" is when it reached any company mailbox, not when support opened it.

2. S2

   Find every place the data livesagent

   Search mail (bc mail search), documents, CRM, invoicing, spreadsheets, website forms, backups, and list systems held by processors (payroll, hosting, mail provider).

   Done when a written inventory names each system, what it holds, and who controls it — including "checked, nothing found" per system.

3. S3

   Verify identity if there is doubtagent

   If the requester is not already known to the channel they wrote from, ask for confirmation through a channel already on file.

   Done when identity is confirmed, or the doubt is written down and the answer notes it.

4. S4

   Prepare the answer packagent

   For access: a copy or structured export of the personal data, plus purposes, categories, recipients, retention period and the source if not collected from the person. Draft the response letter; if the company intends to refuse or to extend by up to two months, draft the reasons and the complaint information.

   Done when the draft letter and the data export exist and are dated.

5. S5

   Decideownerneeds approval · owner

   Approval · S5 · owner — the run stops until a named person records the decision

   Review the pack: grant in full, grant in part, refuse (name the specific ground), or extend with the reason sent within the first month. Check erasure against retention duties — invoice and payroll data the company must keep by law is restricted, not deleted.

   Done when the owner has named the decision in writing.

6. S6

   Send the answeragentneeds approval · owner

   Approval · S6 · owner — the run stops until a named person records the decision

   Send the approved letter with the export (a password-protected archive or a secure link, never a plain attachment of a full export to an unverified address).

   Done when the sent message is in the mail record with its date, within the deadline.

7. S7

   Execute the decision. `[irreversible for erasure]`agent

   Rectify, erase, restrict or export as approved — in every system from S2, including the mail provider's deletion, and note where data survives in immutable backups and when those age out.

   Done when each system from S2 shows the change or a written note why it cannot (legal retention, backup lifecycle).

8. S8

   Record and closeagent

   Write the outcome in the GDPR register's request log: what was asked, decided, sent, changed, and the dates. Set a task to confirm erasure/restriction propagated (a check two weeks out).

   Done when the log entry is complete and the follow-up task exists.

Checks — how we know it worked

• Read the sent letter back against the request: every right invoked is answered, yes or no, with reasons.
• The sent date is on or before the deadline (or the extension notice went out within the first month).
• A spot-check in one system from S2 shows the data actually changed or is gone — "we sent the order" is not a check.
• The request log entry would let a stranger reconstruct the whole run.

If it goes wrong

What each step leaves behind

1. S1the request log entry exists with the received date and the deadline date. ⛔ "Received" is when it reached any company mailbox, not when support opened it.
2. S2a written inventory names each system, what it holds, and who controls it — including "checked, nothing found" per system.
3. S3identity is confirmed, or the doubt is written down and the answer notes it.
4. S4the draft letter and the data export exist and are dated.
5. S5the owner has named the decision in writing.
6. S6the sent message is in the mail record with its date, within the deadline.
7. S7each system from S2 shows the change or a written note why it cannot (legal retention, backup lifecycle).
8. S8the log entry is complete and the follow-up task exists.

Evidence to keep

The request verbatim with received date · the S2 inventory · identity check (or the reason none was needed) · the approved decision (who, when) · the sent letter and export checksum · per-system confirmation of the S7 change · the final log entry. Keep for the retention period the GDPR register defines.

How this playbook improves

After every 5 requests ask: how many days from receipt to answer, and which step consumed the wait? Did S2 find a system holding the data that nobody knew about? Was any decision reversed after the answer went out? A new version changes the step that caused the wait or the miss, and says so in its change note.