Handling GDPR Data Subject Requests with AI: 30-Day SLA Pattern

When a head of ops at a 70-person SaaS company told me they'd received their first GDPR data subject access request on a Friday afternoon and panicked through the weekend trying to figure out the right process, my reaction was: this is the most predictable compliance event in your business, and you have no playbook for it. GDPR gives you 30 days. The pattern fits on one page.

Why do SMB founders fear DSRs?

Because the consequence of a wrong answer is concrete (GDPR fines up to €20M or 4% of global turnover, EU AI Act up to €35M or 7%), the deadline is short, and most SMBs have no written process. The first DSR feels like an emergency because it actually is — without a process, you're improvising against a regulator-watched clock.

Definition: Data subject request (DSR) — a formal request from an individual exercising their GDPR rights, typically access, deletion (right to be forgotten), portability, correction, or objection to processing.

The companies that handle DSRs well receive the same volume; they just receive them into a process. The first one of the year is identical in shape to the twentieth. The process is the asset.

The 5-step DSR pattern

Five steps, target SLA shown for each. The whole pattern sits inside the 30 calendar days GDPR allows.

Step 1: Acknowledge (target: 48 hours)

A written acknowledgement to the requester, confirming receipt, stating the legal SLA, and listing the identity-verification documents required. This step is not a placeholder — it's the legal trigger that starts the clock visibly.

AI helps here as a template-fill: pulls the request type from the inbound message, fills the acknowledgement template, sends a draft to the DSR owner for approval. Median work: under 5 minutes. The mistake to avoid: never let AI auto-send a DSR acknowledgement without human review — this is the first regulator-visible touch.

Step 2: Verify identity (target: 5 business days from acknowledgement)

Confirm the requester is who they claim to be. For account holders, a logged-in session plus the email on file is usually sufficient. For deleted accounts or unidentified requesters, ID documents or a defined verification flow are needed. The verification standard is documented before the request arrives — not improvised during it.

AI doesn't do identity verification. People do — and the standard is approved by counsel once, not per request.

Step 3: Pull data (target: 10 business days)

For access and portability requests, pull every piece of personal data tied to the verified identity across all systems in the inventory. This is where SMBs lose days without preparation: which CRM record, which support tickets, which analytics events, which AI-tool transcripts, which backups.

Definition: Data pull — the operational process of identifying, extracting, and consolidating all personal data tied to a verified data subject across every system in the data-flow inventory.

AI accelerates this layer significantly. With a data-flow inventory in place (see the privacy policy update pattern), AI can generate the pull-list — which systems to query, what export format to use, what to consolidate. The ops lead executes the pulls; AI organizes the output into a single deliverable.

Step 4: Review for exclusions (target: 5 business days)

Not every piece of data tied to the requester is in scope. Excluded categories include data that would identify third parties (other customers in support transcripts, other employees in HR systems), data covered by legal professional privilege, data subject to retention obligations under other laws (tax, anti-money laundering), and trade-secret-protected operational data.

This is where AI helps and counsel decides. AI can produce a flagged version of the data set — "this entry contains a third-party name, this email contains protected legal advice, this record is subject to a 7-year tax retention" — and counsel reviews the flags. The human signs off on what gets released.

Step 5: Respond (target: by day 28-29)

Send the response, with the data package for access/portability requests or the deletion confirmation for erasure requests. Document everything in the DSR log: date received, date acknowledged, identity verification method, systems queried, exclusions applied, date sent, requester sign-off if any. The log is what you show a regulator who asks.

The two-day buffer before the 30-day deadline is deliberate — it gives you time to fix a final review issue without missing the SLA.

Copy/paste DSR runbook

DSR LOG ENTRY — REQUEST #[N]
Received: [DATE / CHANNEL]
Request type: [ACCESS / DELETION / PORTABILITY / CORRECTION / OBJECTION]
Owner: [NAME]
SLA deadline: [DATE = received + 30 days]

STEP 1 — ACKNOWLEDGE (target: +48h)
Acknowledgement sent: [DATE]
Method: [EMAIL / PORTAL]
ID-verification docs requested: [LIST]

STEP 2 — VERIFY IDENTITY (target: +5 business days)
Method used: [LOGGED-IN / ID-DOC / OTHER]
Verified: [Y/N — DATE]
If N: refusal sent with reason: [TEXT]

STEP 3 — DATA PULL (target: +10 business days)
Systems queried (from inventory):
- [LIST]
Pull complete: [DATE]
Format: [JSON / CSV / PDF]

STEP 4 — EXCLUSIONS REVIEW (target: +5 business days)
Third-party data flagged: [N items]
Legal-privilege flagged: [N items]
Retention-obligation flagged: [N items]
Trade-secret flagged: [N items]
Counsel review: [DATE / NAME]

STEP 5 — RESPOND (target: ≤ day 28)
Response sent: [DATE]
Method: [SECURE PORTAL / ENCRYPTED EMAIL]
Requester acknowledgement: [Y/N / DATE]

POST-RESPONSE
Internal incident report: [Y/N]
Process improvement noted: [TEXT]

Tool tip (AIAdvisoryBoard.me): DSR handling is exactly the kind of operational compliance work where the difference between "handled in 8 hours" and "panic for 28 days" is whether you have a Plan → Fact → Gap view of your data flows before the request arrives. The 7-day diagnostic lays the foundation: what data is processed where, by which system, with what retention. When the DSR arrives, the pull list is already drafted. See https://aiadvisoryboard.me/?lang=en for how this works across compliance, vendor, and ops workflows.

Manager scan (2-minute digest example)

• Plan: every DSR is acknowledged within 48 hours
• Fact: median acknowledgement time last quarter was 14 hours
• Gap: hold the line — the gap to watch is what happens when the DSR owner is on holiday
• Plan: identity verification standard is documented and counsel-approved
• Fact: standard exists, last reviewed 9 months ago
• Gap: schedule the annual review with counsel
• Plan: data-pull list is generated from inventory, not assembled from scratch
• Fact: last DSR took 4 days of pulls because inventory was stale
• Gap: inventory hasn't been refreshed (see privacy quarterly process)
• Plan: exclusions are reviewed by counsel before response
• Fact: counsel reviewed 3 of 4 DSRs last quarter — one slipped through ops-only
• Gap: counsel-review checkbox is missing from the runbook for low-volume requests
• Plan: zero DSRs miss the 30-day SLA
• Fact: SLA met on all DSRs this year
• Gap: not yet — but the inventory drift is the leading indicator that will break it

Micro-case (what changes after 7-14 days)

A 110-person B2B SaaS company received its first GDPR access request from a deleted account holder and spent 19 days assembling the response — three different team leads were pulled in, the data spanned six systems, and counsel reviewed the exclusions on day 26. After writing the 5-step runbook against their data-flow inventory, training one DSR owner, and pre-drafting the acknowledgement and response templates, the next three DSRs in the following quarter took 8, 6, and 5 days of elapsed time respectively. The third one involved a partial deletion request — counsel reviewed the exclusion list in 25 minutes, the owner sent the response on day 7, and the regulator audit log was complete and clean. The runbook itself was a single page; the inventory work that fed it was the actual investment.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

Tool tip (AIAdvisoryBoard.me): The DSR pattern is one of many operational compliance flows where the cost of being unprepared compounds quietly until a regulator forces visibility. The Plan → Fact → Gap discipline applied to compliance, vendor management, customer obligations, and data flows is what keeps the 30-day SLA from feeling like an emergency. See the 7-day diagnostic at https://aiadvisoryboard.me/?lang=en for how the pattern works across the whole operational stack.

FAQ

What if the requester is a former employee, not a customer? Same process, different inventory subset. HR systems, performance records, payroll, internal communications — all in scope, with their own retention and exclusion considerations. Counsel signs off on the employee-DSR exclusion template separately, because employment law adds layers.

What about requests that are clearly excessive or vexatious? GDPR allows refusal or a fee in cases of "manifestly unfounded or excessive" requests, but the threshold is high and the regulator will second-guess you. Refusals must be documented, sent in writing within the SLA, and ideally reviewed by counsel before sending. Don't refuse without counsel.

Can AI auto-respond to simple DSRs? Not the response itself. AI drafts the response and the data package; humans review and send. The two failure modes — over-disclosing third-party data and under-disclosing in-scope data — are exactly what humans catch and AI doesn't.

What if a sub-processor needs to be involved in the pull? Your DPA with each sub-processor should already include a DSR-cooperation clause with response SLAs. If it doesn't, this is the gap to fix before the next DSR — not during one. Add it to the vendor-risk framework for renewals.

How do we handle DSRs across multiple regimes — GDPR plus CCPA plus EU AI Act? Same 5-step pattern, different exclusion criteria and response timing per regime. Counsel maps which regimes the requester falls under at acknowledgement, the data pull is shared, the review and response are regime-specific. The runbook is a tree, not a single path.

Conclusion

The first DSR is an emergency; the twentieth is paperwork. The difference is a written 5-step process tied to a current data-flow inventory, an AI-assisted data pull, and counsel sign-off on exclusions. Thirty days is plenty if you don't lose the first ten panicking.

This is not legal advice — your counsel signs off on the runbook, the exclusion criteria, and the response templates. The pattern just gives you the operational structure to feed them.

If you want a system that surfaces the Plan → Fact → Gap automatically — including the data-flow drift that makes DSRs harder than they should be — see how the 7-day diagnostic works at https://aiadvisoryboard.me/?lang=en.