DSAR Surge: Batch Processing for GDPR Compliance
GDPR Article 12 sets a one-month deadline. Organizations must reply to Data Subject Access Requests within 30 days. Complex cases get a 60-day extension. The clock starts on receipt. There is no grace period. Missing the deadline is a violation on its own.
In 2024, DPA fines made data rights widely known. The Irish DPC fined LinkedIn €310 million for using behavioral advertising without valid consent. It fined Meta €251 million for failing to notify a data breach on time. Each fine brought an awareness campaign. More people learned they had rights. DSAR volumes went up.
The EDPB's 2024 Coordinated Enforcement Framework targeted right-of-access failures. Organizations that cannot show clean DSAR records now face more scrutiny.
See our compliance overview and security practices for how we support GDPR obligations.
The Third-Party PII Problem
DSAR responses create one specific problem: third-party PII.
A data subject requests all records about them. Those records may name other people. A support note may include another customer's phone number. An email thread may show a colleague's address. A complaint record may mention a third party. Sending those records out exposes other people's data. That is a separate violation of their rights.
You must review every document. You must remove third-party references before sending. A telecom with 300 DSARs per month has about 50 documents per request. That is 15,000 documents each month — just for DSAR compliance.
A team of three cannot do that. Manual review does not fit in a one-month window at that scale.
Batch Processing Architecture
A DSAR-response preset solves this. The preset scans each document. It finds all person names, contact details, and other identifiers. It anonymizes every match except those belonging to the requesting person. You enter that person's name and account number at the start of the job.
Other customers named in records are anonymized. Employees cited in service notes are anonymized. Third parties in emails are anonymized. All of this happens before the document package is assembled.
Processing 50 documents takes minutes — not hours. The compliance team checks the output for edge cases. Response time drops from weeks to days.
Visit our entities page to see which data types the preset detects by default.
What Matters for a Defensible Workflow
Three things make a DSAR workflow defensible.
Speed. Batch tools remove the bottleneck that causes delays at volume.
Accuracy. The preset must remove third-party PII without touching the data subject's own records. A well-configured preset handles this distinction.
Audit trail. Article 5(2) requires proof of compliance. Batch runs log which documents were processed, which preset was used, and when. That log is your evidence.
When This Approach Has Limits
Separating the requester's own data from third-party PII at batch speed is the right way to keep DSAR responses on time and compliant. But limits remain worth stating plainly.
Batch scale magnifies a systematic miss. A preset that mishandles one name pattern does not fail once — it fails across all 15,000 documents in the same way. A surname that the model reads as a place, an unusual contact format, or a third party referred to only by role rather than name can slip past every run identically. The volume that makes batch processing valuable is the same volume that turns one detection blind spot into a leak repeated across an entire month of responses. Spot-check a representative sample, and pay closest attention to the documents with free-text notes rather than structured fields.
Telling apart two people is harder than finding them. The preset must keep the requester's data while removing everyone else. When records mention several people with similar or shared names, when the requester appears under a nickname, or when an account number is missing from a document, that distinction gets unreliable. Removing the wrong party harms the response; keeping the wrong party leaks third-party data. A human still has to confirm the boundary on ambiguous documents before the package goes out.
The tool supports the deadline but does not satisfy it. Article 12 obligations sit with the controller, not the software. A clean batch run is evidence of effort, not proof that the response is complete or correctly scoped. Deciding which documents are in scope, whether redactions are proportionate, and whether an exemption applies remains a judgment call that a compliance officer must make and be able to defend. Treat the log as input to that decision, not a substitute for it.