Know what’s on your site before a plaintiff’s firm does
A free privacy audit shows which cookies, pixels and trackers are running — and which ones commonly appear in privacy claims.
Companies struggle with data subject request management for a handful of predictable reasons: requests arrive in too many places, the legal clock starts before anyone notices, identity checks are handled inconsistently, personal data lives in more systems than anyone has mapped, deletion has to reach vendors and backups, and nobody keeps proof that the work was done. The good news is that each of those problems has a practical fix, and most of them are about process before software.
This guide explains why request volumes keep rising, what the deadlines are, the eight failure points we see most, what a workable process looks like, and when it makes sense to automate.
What is data subject request management?
Data subject request management is the process of receiving, verifying, fulfilling and documenting requests from individuals who want to exercise their privacy rights. Those requests include access requests, often called DSARs, deletion or erasure, correction, portability, and opt-outs of the sale or sharing of personal data. Privacy laws such as the GDPR and the California Consumer Privacy Act set the rights, the deadlines and the penalties for getting it wrong.
Why request volumes keep rising
More people know their rights, and more laws give them rights to use. Cisco’s 2024 Consumer Privacy Survey, as reported by privacy vendors, found that 36 percent of internet users worldwide had exercised their data subject rights, up from 24 percent in 2022. About twenty U.S. states now have comprehensive privacy laws, browsers and extensions send automatic opt-out signals, and some regulators are adding new channels. California’s Delete Act, for example, began requiring registered data brokers to process deletion requests through the state’s DROP system on August 1, 2026. More channels and more laws mean more requests arriving in more forms.
The deadline problem
Every request has a clock, and the clock starts when the request arrives, not when someone on your team notices it. A request sitting unread in a shared inbox for two weeks has already used up half a GDPR month.
| Law | Standard deadline | Extension | Notes |
|---|---|---|---|
| GDPR (EU) | Without undue delay, within one month of receipt | Up to two more months for complex or numerous requests, with notice and reasons inside the first month | Access is generally free. Fines for violating individuals’ rights can reach 20 million euros or 4 percent of worldwide annual turnover |
| CCPA and CPRA (California) | 45 days from receipt of a verifiable request | Up to 45 more days with notice, for 90 total | Opt-out requests have their own rules and do not require identity verification |
| Other U.S. state laws | Many use a 45-day window | Often a further 45 days with notice | Details, cure periods and exceptions vary by state, so confirm each law that applies to you |
Eight reasons companies struggle, and the fix for each
1. Requests arrive everywhere
People send requests through web forms, email, customer support chat, social media, phone calls and postal mail. If your team only watches one channel, the clock runs on the rest. Fix: publish one clear intake form and address, but route anything that looks like a request from any channel into the same queue, and log the date of receipt automatically.
2. Identity verification that is too heavy or too light
Verification protects people from imposters, but too much friction becomes its own violation. California’s regulator has repeatedly acted on this. In August 2026, CalPrivacy fined a data broker 116,490 dollars partly for requiring part of a Social Security number before someone could opt out, in what was reportedly its fourth action over improper verification of opt-outs, and it fined Ford 375,703 dollars in 2026 for unnecessary friction in the opt-out process. Fix: verify access and deletion requests with the least information that works, use data you already hold, and do not require verification for opt-outs of sale or sharing.
3. Not knowing where personal data lives
Every request depends on finding the data. If you do not have a current map of systems, you rely on whoever remembers the old CRM, the analytics export or the support tool. Fix: keep a data inventory with system owners, and use it as the checklist for every request. Our guide to data privacy and data sharing challenges covers how to build one.
4. Too many systems and manual searching
Searching each system by hand is slow and error-prone. A widely cited estimate, attributed to Gartner, puts the cost of manually handling a single access or deletion request at roughly 1,524 dollars. Treat that as a rough benchmark, since actual costs vary widely with request type and company size, but the direction is clear: manual work scales poorly. Fix: connect the systems that hold most of your customer data to your request workflow first, and automate searches and deletions there.
5. Deletion that does not reach everything
Deleting from your primary database is the easy part. Copies live in backups, analytics tools, advertising audiences, email platforms and vendor systems, and some data must be kept for legal reasons. Fix: define what deletion means for each system, record retention exceptions and the reason, send deletion instructions to processors and partners, and keep confirmation.
6. Opt-outs and signals handled outside the workflow
Opt-out requests and automatic signals such as Global Privacy Control are rights requests too, yet they often sit with the marketing team, in a different tool, with a different process. California’s 2026 settlement with Disney involved opt-outs that did not apply across all of a customer’s devices and services. Fix: treat opt-outs as part of the same system, tie them to your consent platform, and make them apply to the person, not just the browser.
7. Exceptions, redactions and refusals
Not every request can be answered in full. Responses may need to remove other people’s data, protect legally privileged material, or decline requests that are manifestly unfounded or excessive. Regulators set a high bar for relying on those exceptions. Fix: use a documented review step with named approvers, standard wording for partial responses and refusals, and a record of the reasoning.
8. No audit trail and no metrics
When a regulator or a complainant asks what happened, you need dates, decisions, systems searched and confirmations. Without them, even a correctly handled request is hard to defend. A German authority reportedly fined a recruitment agency more than 35,000 euros in September 2025 for ignoring access and erasure requests, confirming deletion to people and then continuing to contact them. Fix: log every step and report on volume, time to complete, overdue requests and exceptions every month.
What a workable request process looks like
The steps below are the same for every request type. The internal targets are suggestions to adapt, not legal requirements, and your legal deadlines remain the outer limit.
| Step | Goal | Suggested owner | Suggested internal target |
|---|---|---|---|
| 1. Receive and log | Capture every request and start the clock | Privacy operations | Same business day |
| 2. Classify | Identify the request type, the law that applies and the deadline | Privacy operations | Within two business days |
| 3. Verify | Confirm identity with minimum necessary information | Privacy operations | Within five business days |
| 4. Locate | Search or instruct every system and vendor that holds the data | System owners | Within ten business days |
| 5. Review | Apply redactions, exceptions and retention rules | Legal or privacy lead | Within five business days |
| 6. Respond | Send the response or a reasoned refusal in the required form | Privacy operations | Well before the legal deadline |
| 7. Record | Close the request with confirmations and keep the record | Privacy operations | Same day as response |
What does a request really cost you?
Instead of relying on a benchmark, estimate your own. Take the number of requests you receive in a year, the average hours each one takes across privacy, legal, IT and system owners, and your loaded hourly cost. As an illustration only, 120 requests a year at six hours each and 60 dollars an hour is about 43,200 dollars, or 360 dollars a request. Most organizations find a small share of complicated or disputed requests consumes a large share of the hours, so track those separately. That figure becomes your business case for fixing the process.
Manual process or automation: how to decide
| Situation | What usually works |
|---|---|
| A few requests a month, few systems | A well-run manual process with a shared tracker, templates and a named owner |
| Dozens of requests a month or many systems | A request workflow tool with intake, deadline tracking and audit logs |
| Deletion across many systems and vendors | Workflow plus connectors that act directly on key systems |
| Heavy opt-out and signal volume | Consent management tied to the request workflow so choices apply across systems |
| Operating in the EU without an establishment | Confirm whether you need an EU representative, and make sure requests reach you promptly |
Metrics worth tracking every month
- Requests received, by type and by law.
- Median and longest time to complete.
- Requests nearing or past their deadline.
- Share of requests with exceptions, refusals or extensions.
- Systems and vendors that cause the most delays.
- Opt-outs and signals received, and how quickly they took effect.
Common mistakes to avoid
- Starting the clock late. Log the date of receipt, not the date someone read it.
- Collecting too much to verify. If you ask for more data than you need, you may create a new privacy problem.
- Sending the easy data. A response that omits systems you forgot about is an incomplete response.
- Confirming deletion you did not complete. Tell people only what you can prove.
- Forgetting the signals. An automatic opt-out is a request, and it needs to flow through the same process.
Where Captain Compliance fits
Captain Compliance is a privacy compliance software and consulting company, not a law firm, and none of this replaces legal advice. We help with the operational side of request management.
- DSAR workflows for intake, routing and tracking of access, deletion and opt-out requests, so nothing sits unnoticed in an inbox.
- Cookie consent management that honors Global Privacy Control signals and links opt-outs to the rest of your privacy program. Our consent platform is used on more than 8,000 websites and processes over 50 million consent choices a month.
- Dynamic privacy policies and vendor disclosures that stay accurate as your systems and vendors change, which also helps you find where the data lives.
- Continuous website monitoring and Patrol, our privacy risk monitoring tool, to surface trackers and data flows that your request process needs to cover.
- EU representation support through our partnership with EU Presence for Article 27 needs.
Frequently asked questions
Why do companies struggle with data subject requests?
Most struggles come from requests arriving in many channels, unclear ownership, incomplete knowledge of where data lives, manual searching across systems, deletion that does not reach vendors, and no record of what was done.
How long do I have to respond to a data subject request?
Under the GDPR, within one month, extendable by up to two more months for complex or numerous requests if you notify the person in the first month. Under the CCPA, 45 days, extendable once by another 45 days with notice. Other laws differ, so check each law that applies.
Can I charge for a data subject access request?
Under the GDPR, access is generally free, and a reasonable fee or refusal is allowed only for manifestly unfounded or excessive requests. Regulators treat that exception narrowly. Other laws have their own rules, so ask counsel before charging.
Do I need to verify identity for an opt-out request?
California’s regulator has said that opt-outs of sale or sharing should not require identity verification, and it has fined businesses for adding friction or demanding sensitive details. Verification rules differ for access and deletion requests, so confirm the rules that apply to you.
Should I automate data subject requests?
Once you handle more than a handful of requests a month, or your data sits in many systems, automation usually pays for itself in time saved and deadlines met. Start by fixing intake, ownership and your data inventory, because automation cannot repair an unclear process.
What is the difference between a DSAR and a data subject request?
A DSAR is specifically an access request. A data subject request is the broader category, covering access, deletion, correction, portability and opt-outs.
Put this into practice
Turn privacy guidance into working controls.
Captain Compliance helps teams discover tracking technologies, enforce consent, manage privacy requests and document the evidence behind every decision.
