A data subject request is a small project with a legal deadline: find one person's data everywhere it lives, do something to it, prove you did, and reply on time. Automation helps with most of that, but not all of it, and knowing where the line sits is most of the work.
We build the tooling behind this workflow. Opsware designs and implements request intake, identity checks, data lookups and reply tooling as part of its Python and Node development work.
This guide walks through the request lifecycle in the order a request actually moves: intake, verification, locating data, fulfilment by request type, packaging the reply, and record keeping. Then it covers what is worth automating, what should stay with a human, and how to decide between building and buying. It is vendor-neutral. For the rights-by-law detail, see the companion working guide to handling data subject requests, which has a full matrix.
What counts as a request
The terminology varies by law, but the request types reduce to a short list:
- Access (GDPR "right of access", CCPA "right to know"). Confirm whether you hold data about the person, and give them a copy plus information about how it is used. "DSAR" strictly means this request type, though people use it for everything.
- Deletion (erasure, "right to be forgotten"). Remove the person's data, subject to exceptions such as legal retention duties.
- Correction (rectification). Fix inaccurate data.
- Portability. Hand over data the person provided in a structured, machine-readable format.
- Opt-out or objection. Stop selling or sharing data, stop targeted advertising or certain profiling (US state laws), or stop processing based on legitimate interests and direct marketing (GDPR Article 21).
- Restriction, consent withdrawal, appeals and newer rights such as California's requests about automated decisionmaking technology.
Each type has different fulfilment mechanics, and most automation projects underestimate how different. An access request is a read across every system; a deletion is a write across every system with exceptions; an opt-out is a change in downstream data flows that may not touch your databases at all.
The deadlines that set the pace
Every design choice below is ultimately about meeting these clocks with room to spare.
| Law | Response deadline | Extension | Notes |
|---|---|---|---|
| GDPR (Art. 12(3)) | Without undue delay, at most one month from receipt | Two further months, for complexity or volume; tell the person within the first month | Runs from receipt; the EDPB accepts a pause while you wait for ID, if you asked for it without undue delay |
| UK GDPR (Art. 12A, from 5 Feb 2026) | One month from the latest of receipt, receipt of ID, or fee | Two further months | Clock stops while you wait for clarification you reasonably need |
| CCPA regulations (11 CCR 7021, 7026) | Confirm receipt within 10 business days; respond within 45 calendar days | Another 45 calendar days with notice and reasons | Opt-out of sale/sharing: as soon as feasible, no later than 15 business days |
| Virginia and most US state laws | 45 days | Once, by 45 days, with notice | Appeals process required; Virginia gives 60 days to decide an appeal |
| Brazil LGPD (Art. 19) | Access: simplified reply immediately, or a complete statement within 15 days | None in the statute | Deadlines for other rights are left to regulation |
| Quebec (s. 32) | 30 days from receipt, for access and rectification | None | No reply within 30 days is treated as a refusal |
Two practical consequences. First, under the CCPA the 45 days run from receipt "regardless of time required to verify the request," so slow verification eats your fulfilment time. Second, if you serve several jurisdictions, the simplest internal rule is to work to the shortest applicable clock and treat the longer ones as slack.
Intake: get every request into one queue
Requests arrive wherever people can reach you. The job of intake is to turn all of them into one structured record with a received timestamp, because that timestamp starts the clock.
Web form. The best channel for you, because it captures structured fields: request type, jurisdiction, email, account identifier. Keep it short. Ask only for what you need to locate and verify; a form that demands a passport scan for a newsletter unsubscribe will draw complaints. The CCPA requires at least two designated methods, including a toll-free number, unless you operate exclusively online with a direct relationship to the consumer, in which case an email address is enough (Cal. Civ. Code 1798.130(a)(1)).
Email. The privacy mailbox will receive requests no matter what your form says, along with spam, vendor questionnaires and misdirected support tickets. Someone, or something, has to triage it daily. A request sent to a general support address or to an employee is still a request under the GDPR; the EDPB's access guidelines expect controllers to handle requests that reach them through their usual contact points.
Authorized agents and agent services. Consumer apps now send requests in bulk on people's behalf. California's regulations let you ask for proof of the agent's signed permission and ask the consumer to verify or confirm directly, but not to resubmit the request themselves (11 CCR 7063). These need their own routing; see requests from Mine, Privacy Bee and other agent services.
Opt-out preference signals. In California and several other states, a browser signal such as Global Privacy Control is itself a valid opt-out request. It never reaches a queue; it has to be handled in the site's consent and tag-management layer.
Whatever the channel, the intake record should hold: received timestamp and channel, request type as stated and as interpreted, claimed jurisdiction, identifiers supplied, whether an agent is involved, and the computed due date.
Identity verification, proportional to risk
Verification is a balance between two failure modes: refusing a legitimate request because the bar is too high, and handing someone's data to an impostor. Sending data to the wrong person is a breach in its own right.
The rule of thumb in both GDPR guidance and the California regulations is the same: match the strength of verification to the harm a wrong answer could cause. The California standards cited below (11 CCR 7062) are the ones for people without a password-protected account; account holders can generally be verified through their existing login (7061).
| Request | Risk if fulfilled for the wrong person | Typical verification |
|---|---|---|
| Opt-out of sale/sharing, marketing objection | Low | None beyond what you need to find the record. California prohibits requiring a verifiable request for opt-outs (11 CCR 7026(d)). |
| Access to categories of data | Low to moderate | California: "reasonable degree of certainty," which may mean matching two reliable data points (7062(b)) |
| Access to specific pieces of data | High | California: "reasonably high degree of certainty," which may mean three data points plus a signed declaration under penalty of perjury (7062(c)) |
| Deletion or correction | Varies with the data | Scaled to sensitivity; deleting family photos needs more than deleting browsing history (7062(d)) |
For account holders, the strongest and cheapest check is usually the account itself: ask them to log in, or send a confirmation link to the email on file. The EDPB says it is disproportionate to demand an identity document from someone you have already authenticated, and that ID copies should generally not be the default method. Collecting passport scans also creates a new store of sensitive data that you then have to secure and delete.
For people without accounts (prospects, former customers, people in a data broker's files), you have fewer data points to match on, and the honest answer is sometimes that you cannot verify them to the required standard. California requires you to say so and explain why (7062(g)).
Locating the data across systems and vendors
This is where most of the time goes, and it depends almost entirely on how good your data map is. You cannot search systems you do not know exist.
For each system that holds personal data, the DSR process needs four facts: which identifiers it can be searched by (email, customer ID, phone, device ID), how to export a person's records, how to delete or suppress them, and who owns it. Systems fall into roughly four groups:
- Your own databases and warehouse. Fully under your control, often the hardest to automate well because schemas sprawl and the same person appears under several keys. Usually handled with scripted queries or an internal service that each team maintains.
- SaaS tools with APIs (CRM, support desk, marketing automation, billing). Most expose search, export and delete endpoints; the quality varies. This is where commercial connectors earn their price.
- SaaS tools without useful APIs. Someone logs in and does it by hand, or you email the vendor.
- Processors and contractors. Your data processing agreement should oblige them to help. Under the CCPA you must notify service providers and contractors to delete, and they must pass the instruction to their own sub-contractors (11 CCR 7022(b)-(c)). Your sub-processor list is the checklist.
Identity resolution is the subtle part. The requester gives you an email address; the analytics system knows them by a cookie ID and the payments system by a customer number. Your process needs a lookup step that expands the supplied identifiers into every key you hold for that person before fanning out to systems. Get this wrong and access responses come back incomplete, and deletions leave orphans.
Fulfilment by request type
Access
Collect, then review. An automated pull across systems produces raw material, not a response. Before it goes out, someone needs to remove other people's personal data (third parties in support tickets, co-account holders), withhold anything covered by an exemption such as legal privilege, and check that what remains is readable. Under the CCPA, the access response covers data collected on or after January 1, 2022 beyond the 12-month lookback unless that is impossible or involves disproportionate effort. In the UK, since the Data (Use and Access) Act 2025, you are expected to make a "reasonable and proportionate search" (s. 78), which codifies what the ICO already expected.
Deletion
Deletion is never a single command. Each system needs a decision: delete, de-identify, or retain under an exception (tax records, fraud prevention, an open dispute). Keep a suppression record, the minimum identifiers needed to stop the person reappearing from a future import; both the California regulations and Virginia's statute expressly allow this. Backups are the classic problem: California lets you delay deletion on archived or backup systems until that data is restored or next used (7022(d)), and the practical rule everywhere is the same: if a backup is restored, the deletion has to be re-applied. Write that rule into your restore procedure, not just your privacy policy.
Correction
Mostly manual in practice, because someone has to decide whether the person is right. Route the corrected value to the system of record and let normal sync push it downstream, rather than editing six copies.
Opt-out of sale, sharing or targeted advertising
This is a flow change, not a data change. Set a flag in the system of record, propagate it to your ad-tech and data-sharing integrations, and under California's rules notify the third parties you sold or shared the data with (7026(f)(2)). The 15-business-day deadline makes this the request type most worth fully automating.
Packaging the response
An access response is a document a regulator may one day read, so treat it like one:
- A cover letter that answers the questions the law requires (purposes, recipients, retention, sources, the person's other rights), not just a data dump. GDPR Article 15(1) lists them.
- The data itself in a format a non-engineer can open. CSV or JSON for portability, a readable summary for everyone else. Brazil's LGPD lets the person choose electronic or printed form (Art. 19).
- Secure delivery: an expiring download link behind the same verification used at intake, not an email attachment.
- A record of exactly what was sent, retained with the request.
For deletions, the response confirms what was deleted, what was kept and why. California requires a detailed explanation of any denial, not a bare statement that an exception applies.
Audit logs and records
When a regulator or plaintiff asks how a request was handled, the log is your evidence. For each request, record the timestamps of every state change, who verified and how, which systems were searched and what each returned, what was sent or deleted, and any extension notice with its reasons. California requires businesses to keep records of consumer requests and how they responded for at least 24 months (11 CCR 7101), and businesses handling the data of 10 million or more consumers a year must also compile and publish annual request metrics (7102).
Keep the log lean on content. It should prove what happened without becoming a second copy of everyone's personal data; store references and hashes, not the exported files, once the delivery window has passed.
Non-digital records
Paper files, signed forms, call recordings on an old phone system, archived email on tape: if it is in a filing system and relates to the person, it is usually in scope. Automation cannot search a filing cabinet, but it can track one. Treat each offline repository as a system in your data map with a named owner, and have the workflow generate a task to that owner with the same due date as the automated steps. The task record becomes the evidence that the search happened.
What to automate and what to keep manual
| Step | Automate? | Why |
|---|---|---|
| Intake, deduplication, due-date calculation | Yes | Rules-based, high volume, and errors here are pure loss |
| Email confirmation and account-based verification | Yes | Cheap, fast, and the strongest signal you have for account holders |
| Opt-out propagation | Yes | Short deadline, no judgment involved |
| Data retrieval from systems with APIs | Yes | The time saving is largest here |
| Deletion in systems with APIs | Yes, with guardrails | Run retention exceptions first; log every call |
| Review and redaction of access packages | Assist, don't decide | Third-party data and privilege calls need a person |
| Correction decisions, exemption calls, denials | No | Legal judgment, and the most likely to be challenged |
| Agent and high-risk verification | Partly | Automate the checks, escalate the doubtful cases |
A useful test: if a step goes wrong, does someone get hurt or does a deadline slip? Automate the deadline steps aggressively. Put people on the harm steps.
Build or buy
Building on your existing ticketing system works well at low volume with a small, stable set of systems: a form, a ticket template with due dates, scripted queries for your own databases, and a checklist for SaaS tools. Its weak points are SaaS connectors, which you end up maintaining yourself, and audit evidence, which is easy to neglect.
Buying makes sense when volume is high, the system count is large or churning, or you need to show regulators a clean audit trail. The questions that separate tools are covered in how privacy request automation tools work, and the privacy software buyer's checklist turns them into a scoring sheet. Whichever way you go, the bottleneck is usually the data map, not the workflow engine, so budget for that first. The data map cost calculator estimates what the manual version costs, and the privacy tech stack, layer by layer shows where DSR tooling sits relative to consent, discovery and vendor management.
Common questions
Can we charge a fee?
Generally no. The GDPR allows a reasonable fee or refusal only for manifestly unfounded or excessive requests, or a fee for additional copies. Virginia lets consumers make requests free of charge up to twice a year.
Does the clock stop while we verify identity?
Under the CCPA, no: the 45 days run from receipt. Under the UK GDPR as amended, the month runs from when you receive the ID you reasonably asked for. Under the EU GDPR, the EDPB's access guidelines say the period starts on receipt but can be suspended while you wait for information needed to confirm identity, provided you asked for it without undue delay. In every case, ask on day one.
What if the person isn't in our systems at all?
Say so. A clear "we searched these systems and found no data associated with the identifiers you gave us" is a complete answer to an access request, and logging the search protects you later.
Do employees and job applicants count?
Under the GDPR, UK GDPR, LGPD, Quebec's law and the CCPA, yes. Most other US state laws exclude employment data. Employee requests tend to be the most complex, because the data sits in email and HR files rather than tidy databases, and they often arrive alongside a dispute.
Need this built?
If you would rather have this implemented than read about it, tell us about your project and we will reply with questions or a rough plan.