GDPR Data Subject Rights and the 72-Hour Breach Clock

Two clocks run under GDPR. The slow one gives you one month to answer a data subject request. The fast one gives you 72 hours to report a breach to the supervisory authority — and if you miss it, you owe a justified reason in writing. Most SMBs are unprepared for the fast one, because it is the one you cannot plan the start of.

GDPR Chapter III grants data subjects a set of rights against the controller. Chapter II Article 5 makes the controller accountable for demonstrating compliance with those rights. When a breach occurs, Article 33 starts a 72-hour clock from the moment the controller becomes aware of it. The two are linked: answering a data subject request and reporting a breach both depend on the same artifact — the Article 30 record of processing activities — and both fail without it.

The rights list and breach-notification contents below reflect the public text of the GDPR (Regulation (EU) 2016/679, Articles 15–22 and 33–34) as summarized in the canon. Confirm the exact wording against the official EUR-Lex text before relying on it operationally.

The eight data subject rights

GDPR grants eight rights a controller must be ready to action:

1. Right of access (Article 15). The data subject can obtain a copy of their personal data plus supplementary information: the purpose, the categories of data, the recipients (including third-country recipients), the retention period or the criteria for setting it, the existence of the other rights, the right to lodge a complaint with a supervisory authority, the source of the data where it was not collected from them, and the existence of automated decision-making including meaningful information about the logic. Free of charge, at reasonable intervals (not weekly). 2. Right to rectification (Article 16). Correct inaccurate data or complete incomplete data. Without undue delay, within one month. 3. Right to erasure (Article 17, “right to be forgotten”). Erase data where it is no longer necessary for the purpose, consent is withdrawn, processing was unlawful, the subject objects and no overriding legitimate ground exists, or the data was collected from a child. Conditional — does not apply where processing is for freedom of expression, legal compliance, public interest, public health, legal claims, or archiving. 4. Right to restrict processing (Article 18). Suppress the data so the controller can store it but not process it further — used while accuracy is contested, while a legality dispute is verified, or where the subject objects to erasure and asks for restriction instead. 5. Right to data portability (Article 20). Receive the data in a structured, commonly used, machine-readable format and transmit it to another controller. Applies only where the lawful basis is consent or contract and processing is automated. 6. Right to object (Article 21). Object to processing — absolute for direct marketing, conditional on compelling legitimate grounds otherwise. 7. Rights regarding automated decision-making and profiling (Article 22). Not be subject to decisions based solely on automated processing that produce legal or similarly significant effects, with meaningful information about the logic. Special-category automated decisions require explicit consent or substantial-public-interest authorisation. 8. Right to lodge a complaint with a supervisory authority (Article 77). Not a request the controller actions, but a right the controller must inform the subject of (it appears in the access-reply list above).

The response clock: one month, extendable by two

The controller must respond without undue delay and in any event within one month of receipt of a request. That period can be extended by two further months where the request is complex — but the controller must inform the subject of the extension and the reasons within the first month. Replies are free of charge (a reasonable fee may be charged only for manifestly unfounded or excessive requests). Identity verification is allowed before acting; do not over-ask for ID or you stall the clock.

The one-month clock is the slow one. The trap is treating it as a deadline rather than a target — most requests should be answered in days, because the RoPA tells you where the data is.

How an SMB answers a request

1. Recognise it. A request does not have to use the word “access” or cite an article. A customer email asking “what data do you hold on me?” is an Article 15 request. Route a recognised request to one owner (the DPO or the person who keeps the RoPA). 2. Verify identity. Confirm the requester is who they claim, proportional to the data’s sensitivity. Do not demand a passport to release a marketing email address. 3. Pull the data from the RoPA. The RoPA’s activity rows tell you which systems hold the subject’s data — CRM, support desk, billing, analytics. Without the RoPA, this step is a forensic hunt that eats the one-month window. 4. Assemble the reply. For access: the data copy plus the supplementary information (purpose, recipients, retention, other rights, complaint right, source, automated decision logic). For rectification/erasure/restriction/portability/objection: the action taken, confirmed. 5. Respond within one month. In writing, in plain language, free of charge.

The pattern is the same for each right: identify, verify, locate via RoPA, act, confirm. The differences are the action at step 4.

The 72-hour breach clock (Article 33)

The fast clock. A personal data breach is any unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data — from a lost laptop to a server compromise. The controller must notify the supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of data subjects.

The clock starts when the controller becomes aware — not when the breach occurred. A breach discovered months after the fact still starts the 72-hour window from discovery. If the controller cannot notify within 72 hours, the notification must be accompanied by a reasoned justification for the delay.

The processor’s obligation is narrower: notify the controller without undue delay after becoming aware (Article 33(2)). The controller then runs the 72-hour clock to the authority.

What the breach notification must contain

The Article 33(3) notification to the supervisory authority includes:

• **The nature of the breach**, including the categories and approximate number of data subjects and records concerned.
• **The name and contact details** of the data protection officer or other contact point.
• **The likely consequences** of the breach.
• **The measures taken or proposed** to address the breach and mitigate its adverse effects.

Where the notification is not made within 72 hours, it is accompanied by the reasons for the delay.

When data subjects must be told (Article 34)

A separate, higher bar. Where the breach is likely to result in a high risk to the rights and freedoms of data subjects, the controller must also communicate the breach to the affected data subjects without undue delay — in clear, plain language, with the same content elements (nature, DPO contact, consequences, measures). Where direct communication is disproportionate — too many subjects, or contact data unavailable — a public announcement substitutes. Article 34 exceptions: the data was rendered unintelligible (e.g. encrypted with keys not compromised), or subsequent measures ensure the high risk is no longer likely.

The decision tree: report to the authority at the 72-hour risk threshold (Article 33); communicate to subjects only at the higher “high risk” threshold (Article 34). Most reportable breaches clear Article 33; fewer require Article 34.

The breach response plan an SMB needs before the clock starts

The 72 hours go fast when spent figuring out what to do. Have the plan ready:

1. An internal reporting channel. Employees, processors, and the DPO must be able to report a suspected breach to the controller immediately — the canon specifies this is irrespective of the breach’s scope. A single inbox, a single on-call. 2. A breach register. Every suspected breach logged with detection time, scope, containment, and decision rationale (report / not report, notify subjects / not). The register is the evidence the authority asks for. 3. A pre-filled notification template. The four Article 33(3) elements as a fill-in form, with the DPO contact and the supervisory authority’s contact already set. In a breach, you fill the blanks; you do not draft from zero. 4. The RoPA as the data map. “Which data and whose” is answered by the RoPA in minutes. Without it, the 72 hours evaporate in discovery. 5. A containment runbook. The “measures taken or proposed” element requires you to have done something — rotate credentials, revoke access, isolate the system — by the time you notify.

The link to the rest of the GDPR program

The data-subject-rights response and the breach clock are the two operational moments where the GDPR program is tested in real time. Both depend on the RoPA. High-risk processing identified in the RoPA feeds the DPIA and the Article 34 high-risk communication decision. If you run ISO 27001, the breach response runbook is the GDPR-facing view of the ISMS incident-response procedure (Annex A.5.24–A.5.27) — see the ISO 27001 joint implementation.

How this fits the series

This is the operational companion to the GDPR pillar and the Article 30 RoPA article. It assumes you have built the RoPA — answering a request and reporting a breach both run on it. The DPIA template covers the high-risk processing that drives Article 34; the ISO 27001 joint implementation covers the incident-response merge.

What to do next

Write the breach notification template today — the four Article 33(3) elements as a fill-in form, DPO contact and authority contact pre-set, stored next to the RoPA. Then walk the eight rights once against your RoPA and confirm you could answer each within one month from the RoPA alone. The slow clock is manageable with the RoPA; the fast clock is manageable only with the template and the runbook already in place.

Want a data-subject-rights and breach-response readiness check? Book a 30-minute **GDPR applicability assessment** — we pressure-test your request-handling against the eight rights, review your breach template against the Article 33(3) elements, and walk your 72-hour runbook for the gaps. Bilingual EN/FR, no obligation.

→ /contact · download the GDPR for SMBs readiness guide