DSAR Response Deadline: GDPR One Month, CCPA 45 Days

The DSAR response deadline is one month under the GDPR and 45 days under the CCPA. Under the GDPR the one-month period can be extended by up to two further months for complex or numerous requests, and under the CCPA the 45-day period can be extended by a further 45 days with notice to the requester. In both cases the clock generally starts when the request is received, not when you begin working on it.

This is general information, not legal advice. Below we break down when each clock starts, how extensions work, and how to avoid missing the date.

The GDPR deadline: one month

Under the GDPR, you must respond to a data subject access request without undue delay and within one month of receipt. The month runs from the day after you receive the request. If that day has no numerical equivalent in the next month, the deadline is the last day of that month, and if it falls on a weekend or public holiday, it rolls to the next working day.

You can extend the one-month period by up to two further months where the request is complex or where you have received a number of requests from the same person. If you rely on an extension, you must tell the requester within the original month and explain why. An extension is a considered decision you document, not a default you reach for because discovery is slow.

The CCPA deadline: 45 days

Under the California Consumer Privacy Act, you must respond to a verifiable consumer request within 45 days of receiving it. That 45-day window includes the time needed to verify the request. You can extend it once by a further 45 days when reasonably necessary, provided you notify the consumer of the extension and the reason within the first 45 days.

The mechanics differ from the GDPR, but the discipline is the same: verify quickly, discover thoroughly, and leave time for review. For a fuller comparison of the two regimes, see GDPR vs CCPA data requests.

Deadlines at a glance

When the clock actually starts

The most common way to lose time is misjudging the start date. The deadline generally begins when the request is received by the organization, not when it reaches the privacy team. A DSAR that lands in a general support inbox and sits there for five days has still consumed five days of your window. Because a valid request does not have to use formal language or a specific channel, front-line staff need to recognize one and forward it immediately. Centralized privacy request management is the practical fix: one intake point, timestamped on arrival.

Verification and the clock

You are entitled to verify the requester's identity before disclosing data, and under some interpretations the clock effectively pauses until you have the information you reasonably need to identify them. Do not treat that as license to delay. Ask for confirming details promptly, keep them proportionate, and resume the moment you have them. Efficient identity verification protects both the deadline and the requester.

Why the deadline is hard to hit

The deadline is rarely blown at the response stage. It is blown during discovery, because finding a single person's data across a CRM, help desk, billing system, marketing tools, and backups takes far longer than teams expect. If you start discovery in week three of a four-week window, you have almost no room for redaction and review. The fix is to shorten discovery: automated personal data discovery searches your connected systems at once instead of one at a time, and following a consistent DSAR process keeps every request on the same timeline.

How to protect the deadline

1. Timestamp on arrival. Log the request the day it lands and set the due date immediately.
2. Work backward. Reserve the last few days for redaction, human review, and delivery, then plan discovery around what remains.
3. Make the date visible. A due date no one can see is a due date that gets missed. Automated deadline tracking keeps the countdown in front of the team.
4. Decide on extensions early. If a request is genuinely complex, notify the requester within the original window rather than at the last minute.

What counts as a complex request

Under the GDPR, the extension exists for requests that are complex or numerous, but "complex" has a specific meaning, and volume alone does not qualify. A large amount of data to search is not the same as a complex request; it is a resourcing problem you are expected to plan for. Complexity might arise where the data is genuinely difficult to untangle, where extensive redaction of third-party information is required, or where the request overlaps with other legal matters. If you rely on the extension, be ready to explain the specific reason to the requester, and record it. Reaching for an extension because discovery ran late is not a valid basis, which is another reason to start discovery on day one.

If you are going to miss it

If a deadline is at genuine risk and you qualify for an extension, use it properly: notify the requester in time and explain the reason. Missing a deadline without a valid extension can lead to a complaint and regulatory attention. The safer path is to never let discovery start late in the first place.

Want the clock handled for you? Obtainer timestamps each request on intake, tracks the GDPR one-month and CCPA 45-day deadlines automatically, and keeps the countdown visible while deadline tracking flags anything at risk. You stay in control of what is disclosed at the end.