How Long Do You Have to Respond to a DSAR? Every Deadline

Under GDPR you have one month from receipt of a data subject request, extendable by two further months for complex or numerous requests, and Article 12(3) requires you to tell the requester about the extension inside the first month. Under California's regulations you have two clocks at once: section 7021 gives you 10 business days to confirm receipt and 45 calendar days to respond, extendable once by another 45 for a maximum of 90, and it says the 45 days "will begin on the day that the business receives the request, regardless of time required to verify the request." Virginia and Texas both run 45 days with one 45-day extension. The contrarian part is that none of these deadlines is what companies actually miss. They miss the start, because a request that arrives in a support queue or a sales inbox has already started the clock, and the EDPB's right of access guidelines say the limit starts when the request "reaches the controller through one of its official channels" and that "it is not necessary that the controller is in fact aware of the request."

This article puts every deadline and every trigger event in one place, then covers the intake and verification mechanics that decide whether you can actually hit them.

Key takeaways

• GDPR: one month from receipt, plus up to two further months, with notice of the extension inside the first month.
• California: 10 business days to confirm receipt, 45 calendar days to respond, one 45-day extension, 90-day ceiling. Opt-out of sale or sharing is a separate and much shorter clock at 15 business days.
• Virginia and Texas: 45 days with one 45-day extension, and Virginia gives you 60 days to decide an appeal.
• Verification time does not stop the California clock. It can suspend the GDPR clock, but only if you asked without undue delay.
• The failure mode is intake, not fulfilment. A request is validly made wherever it lands, not only in the portal you built for it.

Every clock, with the event that starts it

GDPR, Article 12(3). Information on action taken must be provided "without undue delay and in any event within one month of receipt of the request." The period "may be extended by two further months where necessary, taking into account the complexity and number of the requests," and the controller must inform the data subject of the extension, with reasons, within one month of receipt. A refusal is on the same clock: Article 12(4) requires you to explain the reasons and flag the right to complain to a supervisory authority, at the latest within one month.

The month is a calendar month, not thirty days. The EDPB's guidelines compute it under Regulation No 1182/71 and give the worked example: an organisation receives a request on 5 March, and has "until and including 5 April to comply with the request, at the latest."

California, section 7021. No later than 10 business days after receiving a request to delete, correct or know, the business must confirm receipt and describe in general terms its verification process and when the consumer should expect a response. The substantive response is due no later than 45 calendar days after receipt. If necessary, the business may take up to an additional 45 calendar days, "for a maximum total of 90 calendar days from the day the request is received," provided it gives the consumer notice and an explanation of the reason.

California opt-outs, section 7026. This is the clock that gets forgotten because it is not a DSAR in the access sense. A business must cease selling or sharing the consumer's personal information "as soon as feasibly possible, but no later than 15 business days from the date the business receives the request," and must notify the third parties it sold or shared to after the request came in and before the business complied, directing them to comply and to forward the request onward.

Virginia, 59.1-577. A controller must respond "without undue delay, but in all cases within 45 days of receipt of the request." The period "may be extended once by 45 additional days when reasonably necessary." Virginia also builds in an appeal: within 60 days of receiving an appeal, the controller must inform the consumer in writing of any action taken or not taken.

Texas, 541.052. A controller must respond "without undue delay, which may not be later than the 45th day after the date of receipt of the request," and "may extend the response period once by an additional 45 days when reasonably necessary," having informed the consumer inside the first 45 days.

The convergence is not an accident. The 45-day-plus-45 structure is the Virginia model, and the states that legislated after Virginia largely copied it, which is why a single 45-day operating standard satisfies most of the US map. Check your own states against the US privacy laws resource rather than assuming, because thresholds and appeal mechanics differ even where the headline number does not.

The clock starts where the request lands, not where you want it to

This is the whole operational argument, so it is worth being precise about what the sources say.

The EDPB is unambiguous for GDPR: the time limit starts when the request "reaches the controller through one of its official channels," and "it is not necessary that the controller is in fact aware of the request." An email to your support alias is an official channel. So is a reply to a marketing email, if that address is one you publish. The clock is running while the ticket sits unread.

California is blunter still, and it forecloses the workaround most teams reach for first. Section 7021 says the 45-day period begins on the day the business receives the request "regardless of time required to verify the request." Verification is a separate obligation, and section 7060 requires a business to "establish, document, and comply with a reasonable method for verifying" the requester, but doing that work does not buy you time.

GDPR is slightly kinder here and it is worth knowing the exact shape of the concession. The EDPB accepts that where the controller needs to communicate with the data subject because of uncertainty about identity, "there may be a suspension in time until the controller has obtained the information needed from the data subject, provided the controller has asked for additional information without undue delay." Same for asking the data subject to specify which processing operations a request relates to, where the conditions in Recital 63 are met. The condition attached to both is the part that matters: you have to have asked promptly. A verification request sent on day 25 does not retroactively pause days 1 through 24.

Build the intake, then the fulfilment

In our experience the companies that miss deadlines are not the ones with slow fulfilment. They are the ones where nobody owns the front door.

A workable intake has five parts. First, an inventory of every channel a request can arrive through, which is longer than the list you think: the privacy portal, support, sales, the general contact alias, the app store review reply, physical mail, and any address printed in a contract. Second, a rule that anyone in the company who recognises a request forwards it to one place the same day, and training that shows them what a request looks like when it is not phrased as one. Third, a single timestamped log with the date of arrival, the channel, the regime or regimes engaged, the verification status and the due date, because that log is what you hand a regulator who asks why a response took as long as it did. Fourth, a default operating deadline shorter than every statutory one, so that missing your internal date is a conversation rather than a violation. Fifth, a named owner with a named backup.

Fulfilment is the easier half and mostly a data-mapping problem: knowing which systems hold personal data, being able to pull one person's records out of each, and knowing which of them can be deleted without breaking a legal retention obligation. If you cannot answer that last question quickly, the retention schedule is the work item, not the DSAR tooling.

Where the deadlines interact with everything else

Two overlaps catch people out.

Deletion requests collide with retention duties. A request to delete does not override an obligation to keep records for tax, employment, or regulated recordkeeping, and every one of the state laws has exceptions for that. What it does require is that you say so, and that you know which exception you are relying on. "We kept it because we might need it" is not one of the exceptions.

Access requests collide with incidents. A DSAR arriving during a breach investigation does not pause, and the two clocks run independently, which is one more reason to treat notification timing as its own discipline. Our crosswalk of breach notification deadlines covers those clocks and their separate trigger events.

There is also a fine-tier asymmetry worth knowing. Under Article 83, the data subject rights articles, Articles 12 to 22, sit in the higher tier: up to 20,000,000 euros or 4 percent of total worldwide annual turnover. Botching DSARs is not a paperwork failure in the eyes of the Regulation.

When you should not hire anyone for this

If you are a single-product company with a short vendor list and a support team that already routes tickets well, DSAR handling is a process you write once and rehearse twice a year. Buy nothing. Write the intake rule, publish the address, build the log as a spreadsheet if that is what you will actually maintain, and run two fire drills where somebody emails support pretending to be a consumer. Most of the value in this whole discipline is in those drills, and no platform runs them for you.

Privacy request automation earns its keep at a different scale: many systems holding personal data, high request volume, or a business model where deletion has to propagate to downstream recipients. If you are buying tooling before you can name every system that holds a customer record, you are buying a workflow engine to run a process you have not designed. Build the map first, run requests by hand for a quarter, and let the volume tell you whether tooling is the answer.

Where Top Floor fits

We build the intake, the log and the decision tree, then hand them over. GDPR covers the Article 12 mechanics and the extension language; CCPA covers the 10-business-day confirmation, the 45-day response, the 15-business-day opt-out clock and the verification method you have to document under section 7060; and global privacy is where those are reconciled into one standard rather than three parallel ones. The reconciliation is the point. Running separate GDPR and state processes doubles the surface area for the same outcome.

How to decide this week

1. Send a test request to your own support alias, unannounced, and time how long it takes to reach whoever owns privacy. That number is your real risk.

2. List every inbound channel where a request could arrive, then decide which are official. Publishing fewer channels does not help; the test is where a reasonable person would send it.

3. Write your due-date arithmetic down once, per regime, including the trigger event and the extension notice requirement. Ambiguity mid-request is what produces late responses.

4. Document the verification method now, before you need it, because California requires a documented method and because deciding verification standards under time pressure produces either over-collection or an unverified disclosure.

5. Set the internal deadline at 30 days for everything. It satisfies the shortest common statutory clock with room, and it removes per-request arithmetic from the process.

Frequently asked questions

Does the GDPR one-month clock pause while we verify identity?

It can, but only on a condition many companies fail. The EDPB accepts a suspension where the controller has to contact the data subject because of uncertainty about identity, or to ask which processing operations the request relates to, provided the controller asked for that additional information without undue delay. Asking on day 25 does not claw back the first 24 days, and California is stricter still: section 7021 states the 45-day period runs from receipt regardless of the time required to verify.

When does the clock start if the request goes to the wrong inbox?

When it arrives, not when it reaches the right person. The EDPB states that the time limit starts when the request reaches the controller through one of its official channels and that the controller need not be aware of it, so a request sitting unread in a support queue is a request whose clock is running. This is why the intake rule matters more than the fulfilment workflow: the days you lose are almost always lost before anyone with privacy responsibility has seen the request.

Is the CCPA 45-day deadline calendar days or business days?

Calendar days for the response and business days for the acknowledgement, which is an easy mix-up because both appear in the same section. Section 7021 gives 10 business days to confirm receipt and describe the verification process, then 45 calendar days to respond, with one extension of up to another 45 calendar days for a 90-day ceiling, and notice to the consumer explaining the reason for taking longer. The separate opt-out of sale or sharing clock in section 7026 is 15 business days.

Do we have to honor a request from someone outside our state?

Legally you owe the rights the applicable law grants, which turns on residency and on whether that law reaches you, so a Virginia resident's request under Virginia law does not oblige you to anything under California's. Operationally, most companies find that handling every request to the strictest applicable standard is cheaper than running a residency-verification step on each one, particularly since verifying residency means collecting more personal data about a person who has just asked you to hold less of it.