GDPR DSAR: end-to-end automation

Automation closes the DSAR cycle — from receiving the request to delivering a completed report with the subject's personal data. The processing involves structured systems (CRM, data warehouse) and unstructured sources (contracts, correspondence, tickets, document scans), where the bulk of PII resides. The lawyer remains in the decision-making loop for disputed cases, but manual search, copying, and stitching of data are removed from their area of responsibility. Example use case: an e-commerce platform customer requests all their data — automation collects the profile from CRM, order history from data warehouse, support correspondence from the ticketing system, and returns a unified report within hours instead of weeks of manual work.

Process steps

1. Receiving the request via web form, email, or customer portal with automatic registration in the DSAR log and setting a 30-day timer.
2. Verifying the requester's identity against CRM data — email, phone, customer ID, contract number.
3. Parallel queries to all systems containing PII: CRM, data warehouse, billing, ticketing system, file storage, email archive.
4. RAG search across file storage — contracts, signed documents, PDF forms, ticket attachments, document scans.
5. LLM extraction of structured fields from unstructured documents: names, addresses, dates of birth, payment details, contractual terms.
6. Automatic redaction of third-party references — other customers, company employees, counterparties, third-party services.
7. Assembly of a unified report in the required format: PDF for human readability and machine-readable JSON/CSV for portability.
8. Audit log of all collection and redaction steps for subsequent regulatory inspections and internal control.
9. Delivering the report to the requester via a secure channel (protected portal, encrypted email) with delivery confirmation.

What automation does NOT do

• Does not make the legal decision to deny data provision — disputed cases (trade secrets, third-party rights, legal exceptions) are escalated to the DPO with a ready-made dossier.
• Does not handle other subject rights: erasure (RTBF), rectification, portability to third-party systems, objection to processing — these are separate processes with their own logic.
• Does not replace the DPO or the lawyer. Responsibility for the correctness of the response, interpretation of GDPR exceptions, and the final signature remains with the human. Automation is a preparation tool, not a decision-making one.

Technically, DSAR automation is built as an orchestrator on top of the company's existing systems. The core is a workflow engine (or equivalent) that manages the stages and state of each request, stores checkpoints between steps, and resumes execution after failures. Around the core, connectors to PII sources and specialized components for working with unstructured data are connected. The architectural principle is minimal privileges for all integrations and a full audit trail for subsequent regulatory review.

Flow Architecture

1. The input channel receives the request (a web form on the site, a dedicated email inbox, a customer portal) and normalizes it into a structured object: applicant identifier, request type, attached documents, contact channel.
2. Identity verification checks the provided data against the CRM and triggers additional verification on mismatch — a one-time code sent to phone or email.
3. The orchestrator sends parallel requests to structured systems — SQL to the data warehouse, REST to the CRM, a request to billing — and collects the responses into an intermediate buffer.
4. The RAG layer processes the file storage: a vector index over documents allows finding relevant files even when they contain no explicit applicant identifier (a name mentioned in the contract body, an email in a ticket attachment).
5. The LLM extractor analyzes each found document and extracts structured fields: names, dates, addresses, details, subject matter of the contract. An AI model or a comparable model with function calling is used for a strict JSON output schema.
6. The redaction layer applies masking rules: mentions of other clients, employees, and counterparties are replaced with [THIRD PARTY]. Rules are defined declaratively and go through legal review before deployment.
7. The report builder assembles a single document in two formats: PDF for human readability and machine-readable JSON/CSV for portability under GDPR Article 20.
8. The audit log records each step with a timestamp, data source, and applied redaction rules — material for the regulator during an inspection.

Solution Components

Implementation Stages

1. Discovery — an inventory of all systems containing PII, classification by sensitivity, a map of data flows between systems.
2. Data mapping — for each source, it is described which fields of which entities are included in the DSAR report, how they are located by applicant identifier, and which fields belong to third parties.
3. Configuring connectors and service accounts with read-only access on the principle of minimal privileges. Standard integrations (SQL, REST, GraphQL) are used, and, where necessary, custom connectors for legacy systems.
4. Building a RAG index over file storage: text extraction (OCR for scans), chunking, embeddings, incremental updates when new files are added.
5. Developing extraction prompts with a strict JSON output schema and validation on a sample of real documents — precision and recall metrics of extracted fields against human ground truth.
6. Defining redaction rules together with DPO and legal counsel: a list of third-party categories, a whitelist of applicant identifiers, a policy for edge cases (client's family, company employee).
7. A report template in two formats and an applicant notification policy at each stage.
8. A pilot run on 3–5 historical DSARs and comparison with manual results: checking the completeness of collected data, correctness of redaction, and format compliance.
9. Production launch with SLA 30-day monitoring, alerts on connector failures, and regular audit trail checks.

Before starting implementation, the company collects a set of input data and aligns on roles. Without these prerequisites, the project drags on or delivers a low-quality result.

Data and access

• Inventory of all systems containing personal data: CRM, data warehouse, billing, ticket system, file storage, email archive, legacy databases.
• Service accounts with read-only access to each system and a whitelist of orchestrator IP addresses.
• Requestor identification policy — which fields are considered sufficient for verification and when additional checks are required.
• Retention policies for each data source to correctly account for already-deleted records.
• DSAR report template and format requirements: PDF branding, section structure, response language.

Team and roles

• DPO or senior legal counsel as process owner and handler of disputed cases.
• IT architect for aligning access permissions and integration architecture.
• Data engineer for configuring connectors and the RAG index.
• COO- or CTO-level sponsor to unblock access between departments.

Timeline

Implementation takes 6-10 weeks at average complexity:

1. Discovery and data mapping — 2 weeks.
2. Building connectors, RAG index, and extraction logic — 3-4 weeks.
3. Redaction rules and report template — 1-2 weeks.
4. Pilot run and adjustments — 1-2 weeks.

With a large number of legacy sources or complex multilingual requirements, the timeline shifts toward the upper bound.