Regulatory Data Request Handler
Process CCPA, GDPR, and other data subject access requests (DSARs) within legally mandated timeframes. Manage intake, identity verification, data collection, review, and response.
On this page
Visual Flow
Rendering diagram…
When to Use This Pattern
Use a regulatory data request handler when:
- Your organisation is subject to CCPA, GDPR, or similar privacy regulations
- You receive data subject requests (access, deletion, correction, opt-out)
- Requests have legally mandated deadlines (GDPR: 30 days, CCPA: 45 days)
- You need an auditable, repeatable process that demonstrates compliance
How It Works
| Phase | SLA | Key Activities |
|---|---|---|
| 1. Intake | Day 0 | Receive request, log it, assign ID |
| 2. Verify Identity | Day 1–5 | Confirm the requestor is who they claim to be |
| 3. Classify | Day 3–7 | Determine request type and scope |
| 4. Collect Data | Day 7–25 | Gather data from all systems where the subject's data exists |
| 5. Review | Day 25–35 | Legal/privacy team reviews response for completeness |
| 6. Respond | Day 35–45 | Deliver response to the data subject |
| 7. Close | Day 45 | Archive the request with full documentation |
Implementation Guide
Step 1: Request Intake
Create a multi-channel intake system:
| Channel | Implementation |
|---|---|
| Web form | Self-service form on your privacy page |
| Dedicated mailbox (privacy@company.com) | |
| Phone | Agent creates request in the system |
| In-person | Agent creates request in the system |
Each request gets:
- Unique tracking ID (DSAR-2025-0042)
- Requestor's verified contact info
- Request type (access, delete, correct, opt-out)
- Data categories requested
- Receipt timestamp (SLA clock starts now)
Step 2: Identity Verification
Before disclosing or deleting any data, verify the requestor's identity:
| Verification Method | When to Use |
|---|---|
| Email verification | They have a known account |
| Government ID | High-risk requests (deletion) |
| Account security questions | They're a known customer |
| Notarised affidavit | Agent/authorised representative requests |
If identity cannot be verified within 5 days, respond requesting additional verification. The SLA may be paused in some jurisdictions during verification.
Step 3: Classify and Scope
| Request Type | Action Required | Complexity |
|---|---|---|
| Right to Know | Compile all personal data held | High — search all systems |
| Right to Delete | Delete from all systems (with exceptions) | High — coordinate across teams |
| Right to Correct | Update specified inaccurate data | Medium — locate and update |
| Right to Opt-Out | Remove from marketing/selling lists | Low — flag in systems |
| Right to Portability | Export in machine-readable format | Medium — structured export |
Step 4: Data Collection Across Systems
Create a task for each system that holds the subject's data:
| System | Team | Data Held | Task |
|---|---|---|---|
| CRM | Sales Ops | Contact info, interaction history | Export records, screenshot of profile |
| Marketing platform | Marketing | Email lists, campaign engagement | Export subscriber data |
| HR system | HR | Employee data (if applicable) | Export employee record |
| Support system | Support | Tickets, chat transcripts | Export case history |
| Analytics | Data team | Behavioral data, cookies | Export/delete tracking data |
| Backups | IT | All of the above (archived) | Note: backup deletion may be deferred |
Use Fan-Out / Fan-In to assign all collection tasks in parallel, then wait for all teams to respond.
Step 5: Legal Review
Before responding to the data subject:
- Privacy officer reviews the compiled data package
- Check for exemptions (legal hold, ongoing investigation, contractual necessity)
- Redact any third-party personal data that shouldn't be disclosed
- For deletion requests: confirm all deletions are technically feasible and legally permitted
- Draft the response letter
Step 6: Deliver Response
| Response Type | Delivery Method |
|---|---|
| Data package | Secure download link (encrypted, time-limited) |
| Deletion confirmation | Email with specifics of what was deleted |
| Correction confirmation | Email confirming the updates made |
| Partial denial | Email explaining the exemption with legal basis |
Step 7: Archive and Report
Store the complete case file:
- Original request
- Identity verification documentation
- All data collected
- Legal review notes
- Response delivered
- Timeline of all actions
- Total elapsed time vs SLA
Tips & Best Practices
Never miss a DSAR deadline. GDPR fines can reach €20 million or 4% of global revenue. Use the Escalation with SLA Timeout pattern aggressively — escalate at 50%, 75%, and 90% of the deadline.
- Pre-map your data. Maintain a data inventory (what personal data is in which systems). Without this, every DSAR requires an ad-hoc discovery process.
- Automate collection where possible. For major systems (CRM, marketing), build automated data export workflows. Manual collection doesn't scale.
- Template your responses. Create response letter templates for each request type (approval, partial denial, identity verification needed). Legal reviews go faster with consistent formatting.
- Track metrics. Average response time, requests by type, exemptions invoked, near-misses on SLA. Report to privacy leadership quarterly.
Related patterns
Access Review & Recertification
Periodically review who has access to what, confirm it's still needed, and revoke what isn't. Kills the slow-drip accumulation of stale permissions that turn into audit findings.
Immutable Audit Trail
Record every significant action to an append-only log that can be inspected but not altered. Essential for compliance, incident response, and answering 'who changed this and when?'
Decision Table
Externalize complex branching logic — pricing tiers, eligibility rules, routing decisions — into a readable table that business users can maintain without a developer in the loop.