Data breach within 72 hours: when the clock starts and what to report

Quick summary

• The 72‑hour period runs from when the controller becomes aware of the breach, not from when an attacker first acted.
• You must be able to prove the moment of awareness with coherent timestamps across tickets, logs and communications.
• Send a preliminary notification with what is known, then integrate updates—document every change with author, date and reason.

When does the 72‑hour clock start — and how to prove it

A SIEM alert may appear at 03:12 on Monday, but if no one acts until Wednesday, auditors will ask: from which timestamp did you calculate the 72 hours, and what evidence supports that timestamp?

Three distinct times to track

• Event time: when the malicious activity happened (reconstructed later from logs).
• Detection time: when a system or person first noticed an anomaly.
• Controller awareness: when the organisation reasonably becomes aware that a personal data breach has occurred.

Only the third time starts the GDPR countdown. Large gaps between detection and awareness must be explained with supporting evidence (tickets, escalation messages, read receipts).

The legal basis is Article 33 of the GDPR, which requires controllers to notify the supervisory authority without undue delay and, where possible, within 72 hours of becoming aware of a breach. The 72 hours are an upper bound: if you exceed them, document why.

Minimum evidential workflow (six steps)

1. Open incident: ticket ID, timestamp (with timezone), source (SIEM/EDR/user report), affected assets/accounts.
2. Confirmation: short signed statement by the investigator plus relevant logs attached.
3. Risk assessment: versioned document with author, date, data categories, and containment measures.
4. Notification decision: signed by the person authorised to decide, distinct from investigators.
5. Transmission: proof of submission to the supervisory authority stored with the incident record.
6. Integrations and closure: each update recorded with version, timestamp and the reason for the change.

A headline note: a timestamp without an owner and verifiable source is a note, not evidence.

AuditReady keeps every file, control, gap and export linked to who owns it, what it proves, its retention and whether it is available for sharing. Record legal holds and retention metadata so evidence is not lost.

Common errors that weaken auditability

• Reconstructed times written after the fact without original logs.
• Overwriting assessments without keeping prior versions.
• Decisions recorded only in ephemeral chats or screenshots without time metadata.
• Evidence stored only in a supplier email inbox.

Contracts and incident playbooks must require immediate escalation from processors to controllers with a formal, timestamped channel so the controller’s awareness time is traceable.

When to notify the supervisory authority and when to justify not doing so

Notifying the supervisory authority is the default when a breach is likely to result in a risk to people’s rights and freedoms. Exemptions (no notification) are exceptional and must be documented, signed and dated.

Examples to decide by documented assessment:

• Ransomware that copies personal data in cleartext: notify (high risk).
• Lost device that is fully encrypted and keys not compromised: likely no notification if documented as improbable risk.
• Email with a few customer records sent in error: assess per case; document number of recipients and mitigation measures.
• Unauthorized internal access to customer data: notify if access enabled identification or harm is likely.

Article 33 allows skipping notification only when the breach is unlikely to result in a risk to individuals; the decision must be supported by timestamps, escalation records and a documented evaluation of confidentiality, integrity and availability impact, categories of data and potential consequences.

Factors that shift the decision

• Nature of the data: special categories, financial credentials and identifiers increase risk.
• Number of affected individuals and ease of identification.
• Encryptions and key management state: encrypted data with uncompromised separated keys may reduce risk, whereas keys found with the data do not.

Remember: the assessment concerns the risk to individuals, not the technical severity of the attack.

Decision steps to document

1. Confirm a personal data breach occurred.
2. List categories of data and estimated numbers of individuals and records.
3. Estimate risk using pre‑defined criteria (those criteria must exist before the incident).
4. Record the decision and signature of the authorised approver; obtain independent verification from the DPO or equivalent.
5. Calculate and record the 72‑hour deadline from the moment of awareness.

If you decide not to notify, retain the full assessment (versioned, signed) because auditors will request it later.

What to include in the initial notification and subsequent updates

You do not need a full root‑cause analysis to send the initial notification. Send the fields you can reliably populate and state explicitly what remains under investigation.

Minimal fields for the initial notification

• Nature of the breach: what happened, systems affected, known time window.
• Categories and approximate number of individuals affected (motivated estimate).
• Categories and approximate number of records affected.
• Contact point: DPO or other reachable contact.
• Likely consequences for individuals.
• Measures taken or proposed: containment, access revocation, credential resets, system isolation.

If root cause and exact counts are pending, indicate that they are under verification and commit to dated updates.

How to structure integrations

• Send a preliminary notification with known facts and clearly label open items.
• Assign owners and internal deadlines for each open item—an integration without an owner is just a promise.
• Each update must include date, author, version and the delta versus the previous submission.

Link incident records to the notification receipt and all subsequent integrations. AuditReady maps GDPR processes (RoPA, DPIA, DSAR, breaches) into registries that show responsibilities, deadlines and linked evidence—without providing legal determinations.

Practical rule: if a field is uncertain, state who is verifying it and the expected deadline rather than leaving it blank.

When to inform the affected individuals

Notification to the supervisory authority is distinct from notification to individuals. The decision to inform people requires a separate risk assessment and separate evidence of delivery.

Three possible outcomes to record separately:

1. Mandatory notification to data subjects when risk to individuals is high. Provide a clear, plain‑language explanation: what happened, what data were involved, contact for questions and recommended protective steps (change passwords, monitor accounts, etc.).
2. Voluntary but advisable notification: you may choose to inform affected people even if not strictly required; document why (e.g., to protect customers or reduce fraud risk). This choice should be recorded and justified.
3. No notification with justification: explain which mitigation steps removed the risk and provide evidence (e.g., cryptographic proof, key separation).

For any outreach, keep the approved text, channel, number of intended recipients, actual sends, bounces and alternative channels used. In audit you will need two distinct evidences: receipt by the authority and proof of communication to individuals when required.

Parallel timelines: GDPR, NIS2, DORA and sectoral rules

Different regulatory regimes may require notifications on different clocks and to different recipients. Examples of timelines (illustrative):

• GDPR: notify supervisory authority within 72 hours from controller awareness (if risk exists).
• NIS2: initial alert/notification windows vary by national implementations and incident severity (some jurisdictions require initial alerts much sooner).
• DORA (financial sector incident rules): some incidents require very short reporting windows (hours) to sectoral authorities.

The same event can trigger multiple obligations. Build a single incident timeline with parallel obligations: recipient, deadline, owner, preconditions and receipt evidence. Do not assume one notification covers another: each regime requires its own content and proof.

AuditReady allows you to register incidents with profiles (e.g., DORA) and stages (initial, intermediate, final) so you can track separate notifications alongside a unified incident ID. The tool does not and cannot certify the legal classification; that decision and its approver must be recorded in your incident file.

FAQs on edge cases

1. If a supplier signals an incident Friday night, when does the clock start?

• The clock starts when the controller gains reasonable awareness. Record the time and channel of supplier communication, who read it and when the escalation occurred. If you argue awareness occurred later than the supplier’s technical notification, support that claim with evidence, not work‑hours assumptions.

2. Can you notify before you have a root‑cause?

• Yes. Send a preliminary notification with known facts and mark unresolved items for dated follow‑up.

3. Does a breach of encrypted data always require no notification?

• No. You must document the encryption algorithm, key separation and evidence that keys were not compromised. If keys are found with the data or credentials permitted decryption, the exemption will not stand.

4. What changes when the incident also affects NIS2 or DORA?

• You face multiple clocks and recipients. Use a single incident ID and record separate notifications and receipts. The GDPR receipt is not a substitute for sectoral or NIS2 notices.

5. How will auditors view a delay beyond 72 hours?

• Auditors look for a coherent explanation: containment actions, escalation, supplier response times and signed decisions. Weak explanations that reconstruct times afterwards or blame generic workload are problematic.

Test your process before the next incident

Run a tabletop or simulation with a realistic, small‑scale scenario (for example: a customer file mistakenly emailed to an external address on Friday at 18:40). Use the exercise to reveal weak links: unclear escalation points, inconsistent timezones, missing supplier escalation clauses.

Six questions to include in the simulation

1. Who is authorised to declare controller awareness and in what timeframe must they escalate to the DPO and security lead?
2. Where are detection, confirmation and decision timestamps recorded and in which timezone?
3. Which risk assessment template and scoring were used (with version and author)?
4. Who signed the notification decision and who verified it (separation of roles)?
5. Which ICT suppliers must escalate and under which contractual clause?
6. Which parallel obligations (NIS2, DORA or sectoral) activate on the same incident?

Use an audit checklist and convert weak responses into findings with an owner, deadline and evidence of closure. Close findings with proof, not just assertions.

Minimum incident registry fields: ID, event date, detection date, awareness date, owner, affected asset/process, data categories, estimated individuals, residual risk, compensating controls, decision, calculated deadline, transmission receipts, integrations, communication to data subjects and closure evidence.

A process that does not produce repeatable evidence will not stand up in audit, even if one notification happened to be timely. Update your playbook after exercises, assign remediation and plan a tabletop within the quarter. Start by strengthening the most common weak link: timely declaration of controller awareness.

If your challenge is tying together incident records, parallel deadlines, signed decisions and versioned evidence without digging through scattered emails and spreadsheets, request a demo of the evidence pack on AuditReady. See how breach registries, vendor records and remediation tasks can be linked into a single audit trail while keeping classification and approval responsibilities with your people: https://audit-ready.eu/?lang=en.

AuditReady evidence pack demo / not legal advice