Dsar Intake System

Building a Universal DSAR Intake System

Overview

A universal DSAR intake system centralises the receipt, verification, routing, and tracking of all data subject rights requests across multiple channels. This skill provides the architectural design, identity verification framework, routing logic, SLA management, and response generation capabilities needed to operate a compliant and efficient rights request management programme.

System Architecture

Multi-Channel Intake

The intake system must accept requests from all channels through which data subjects may contact the organisation:

Central Request Register

All requests from all channels feed into a single central register with the following record structure:

Identity Verification Framework

Tiered Verification

Verification Workflow

[Request Received]
         │
         ▼
[Determine Verification Tier]
   │
   ├── Authenticated channel? ──► Tier 1 (auto-verified)
   ├── Known identifier matches? ──► Tier 2 (request 2 data points)
   └── Unknown channel / third party? ──► Tier 3 (request ID + authorisation)
         │
         ▼
[Verification Request Sent (within 3 business days)]
         │
         ▼
[Verification Response Received?]
   ├── Yes ──► [Data Points Match?]
   │             ├── Yes ──► Mark Verified, start clock
   │             └── No ──► Request additional info (one retry)
   │                          ├── Second attempt matches ──► Verified
   │                          └── Second attempt fails ──► Close as Unverified
   │
   └── No response (30 days) ──► Close as Abandoned

Routing Logic

Automated Request Classification

Upon intake, the system classifies and routes requests based on:

1. Request type (extracted from web form selection or email keywords):

   • Access/DSAR → DSAR team
   • Erasure/Deletion → Erasure team
   • Portability/Export → Portability team
   • Marketing opt-out → Marketing Operations (immediate processing)
   • CCPA requests → US Privacy team
   • Regulatory complaint → DPO + Legal

2. Complexity assessment:

   • Standard: single request type, single jurisdiction, < 5 data systems
   • Complex: multiple request types, cross-border, > 5 data systems, or involving exemptions
   • Urgent: regulatory enquiry, legal deadline, or data subject facing imminent harm

3. Jurisdiction detection:

   • UK/EU data subject → GDPR workflow (30-day deadline)
   • California resident → CCPA workflow (45-day deadline)
   • Other US state → Applicable state privacy law workflow
   • Other jurisdiction → Assess applicable law, default to GDPR standard

Routing Matrix

SLA Tracking

Dashboard Metrics

Escalation Rules

Response Generation

Automated Response Components

The system generates responses by assembling modular components:

1. Cover letter: Standard header, addressee, reference number, opening paragraph.
2. Right-specific content: Template paragraph for each right type.
3. Data compilation: System-generated data extract (for access requests).
4. Supplementary information: Art. 15(1)(a)-(h) information block (for access requests).
5. Redaction log: Automatically generated from redaction flags (for access requests with exemptions).
6. Third-party notification log: Recipients notified under Art. 19 (for erasure/rectification/restriction).
7. Rights information: Standard block listing the data subject's other rights and complaint mechanisms.
8. Sign-off: DPO name and contact details.

Quality Assurance Checklist

Before any response is sent, the QA reviewer verifies:

• Response addresses all elements of the relevant GDPR article
• Data extract is complete (all identified systems queried)
• Redactions are legally justified and documented
• Response deadline has been met (or extension properly communicated)
• Response is in clear, plain language per Art. 12
• Delivery method is secure (encryption, secure portal, or registered post)
• DPO sign-off obtained