Article 33(1) GDPR breach notification within 72 hours

What GDPR breach notification within 72 hours requires of your systems

Your security team has to decide, often within hours of an alert, whether an incident is a notifiable personal data breach, and the clock may already be running. Article 33(1) requires the controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach. The duty does not apply when the breach is unlikely to result in a risk to individuals. If notice goes out after 72 hours, the controller must give reasons for the delay. The risk this addresses is simple: regulators learn about serious incidents late, or never, and then cannot help contain harm or judge the response. What makes the obligation hard is less the deadline than the uncertainty around it. Detection gaps mean an incident may sit unseen in logs, awareness is blurred because the EDPB treats the start of the clock as the point of reasonable certainty that personal data was compromised, and a single incident can touch residents of several Member States.

Those conditions become design requirements for your systems. You need logging that records who accessed which personal data stores and when, alert rules that flag likely exfiltration or unauthorized access to those stores, and a case record that timestamps the moment analysts first had reasonable certainty. Confirm with your counsel which supervisory authority is competent for your main establishment, and whether you must notify several authorities if you are outside the EU but subject to Article 3(2), since the EDPB guidance says a representative does not route notice through the one-stop-shop. Also check the current text of the Regulation with counsel, because the Digital Omnibus proposals would change the threshold and deadline, and those changes are not law as of October 2026.

A useful exercise is to walk one realistic scenario from alert to decision and record each timestamp, then ask whether your logs can prove each step. Illustratively, if a database export is detected on a Friday evening, can your tooling show when it was detected, who triaged it and when the team concluded personal data was involved? Gaps in that chain are what make a late notice hard to justify. DeployOpen can help plan and implement the logging, alerting and case tracking that produce this evidence on self-hosted platforms, but the decision to notify and the notification itself remain the controller's responsibility.

Which controllers, systems and third parties fall under the 72-hour duty

The 72-hour duty applies to a controller once it becomes aware of a notifiable breach, so the first work is deciding who the controller is, which systems feed its awareness and which third parties can start the clock. Each card below is one scoping decision and the work it creates.

EU-established controllers

A controller established in the EU that suffers a breach must notify the competent supervisory authority under Article 33(1), unless the breach is unlikely to result in a risk to individuals. Check which group entities act as controllers for each data set, because the entity that decides the purpose and means carries the duty, not necessarily the parent company. Map each controller to its lead authority before writing the response plan, since the notice goes to that authority and the internal clock starts at the controller, not at the group.

Non-EU controllers under Article 3(2)

A controller outside the EU that is subject to Article 3(2) must notify every supervisory authority in whose Member State affected data subjects reside. An EU representative does not route notices through a single authority, so the one-stop-shop does not simplify this case. Build a register of data subject countries from your records of processing, and confirm with counsel how each authority expects to receive the notice and in which languages.

Processors whose notices start the clock

A processor must inform the controller without undue delay after becoming aware of a breach, without first assessing whether it is risky. Once that notice reaches the controller, the controller is generally treated as aware, so a delayed processor notice can eat into the 72 hours. Contract terms should set notice timing, a named contact and the minimum facts to be sent, and your team should test that the notice reaches an on-call mailbox outside business hours.

Systems that hold personal data

Every system that stores personal data is a possible source of a breach that must be assessed, including SaaS tools, backups, exports on file shares and test copies. Inventory these systems and record which data categories and data subjects each one holds, because the risk test depends on that content. Systems with no inventory entry are the ones most likely to be missed when the clock is running.

Log sources that establish awareness

Logs from identity providers, endpoints, network devices and applications determine when the controller becomes aware that personal data was compromised. The EDPB treats awareness as a reasonable degree of certainty that a security incident has led to compromise, so detection coverage affects when the clock starts. Confirm which log sources feed your monitoring, how long they are retained and whether alerts on those sources reach a person who can escalate them.

Hosted audit trails and admin logs

Application audit logs, such as those written by collaboration platforms, can show whether personal data was accessed or exported without authorization. Decide which audit events are enabled, where they are written, and who can read them during an incident. If a log is disabled or written to a local file that rotates quickly, the controller may be unable to establish the facts needed to decide notifiability within the window.

When the 72-hour clock starts and why awareness is the hard part

The 72-hour period starts when the controller becomes aware of a breach, and EDPB Guidelines 9/2022 read awareness as a reasonable degree of certainty that a security incident has occurred and has led to personal data being compromised. That point can arrive before anyone has confirmed the full picture and often before the first alert is closed. An EDR warning on a file server, a SIEM correlation that touches a customer database, or a mailbox rule that forwards email outside the organization may each be the moment the clock starts, depending on what the team already knows. Decide in advance who can declare that threshold met, what evidence they need to see, and how long triage may run before that declaration is due. Write those rules into the incident response plan so the decision is not improvised at 2 a.m.

Because the clock runs from awareness, the detection and triage pipeline is part of the notification obligation. Alerts from sources such as Wazuh or OpenSearch Security Analytics should reach a named responder with enough context to judge whether personal data is involved, and cases opened in a tool such as DFIR-IRIS should record timestamps for detection, triage and each escalation. Where the controller cannot justify its timing, Article 33(1) requires reasons for the delay, so those timestamps become the evidence. Confirm with your counsel and the current EUR-Lex text how the notification deadline is calculated for your jurisdictions before relying on any plan.

The Digital Omnibus proposal would change this picture. The EDPB-EDPS Joint Opinion 2/2026 supports proposals to notify only breaches likely to result in a high risk and to extend the deadline from 72 to 96 hours, but these are proposals and not law as of October 2026. Until the GDPR text is amended, plan for 72 hours. The EDPB also allows a bundled notification when several similar breaches involve the same type of personal data, in the same way, over a relatively short period, which helps where a single misconfiguration exposes many records in waves. Check the Legislative Observatory status before any change to your procedure, and treat a shorter internal target as the working standard.

How an assessor tests Article 33(1) and what they ask to see

This table sets out how a supervisory authority or an independent reviewer typically tests the 72-hour notification duty, the evidence they request for each test, and the gaps they most often find. Read it as a checklist for preparing records before anyone asks, since the GDPR itself provides no audit or certificate and the authority decides how it tests compliance.

Test area	Test approach	Evidence requested	Common findings
Awareness timing	Compare the recorded time of awareness with the first detection and triage timestamps	Alert timestamps, SIEM or EDR records, incident ticket history, timeline of first escalation	Awareness date set later than the first alert with no explanation, or clock start not recorded
Documented risk decision	Check that a risk assessment exists for each incident and that the reasoning supports the outcome	Signed risk assessment, criteria used, date of decision, reviewer identity	Decision not recorded, reasoning missing, or no-notification decision made without a documented basis
Authority list for cross-border cases	Confirm the authorities identified match where affected individuals reside and the controller's establishment	Data subject locations, lead authority analysis, list of notified authorities	Single authority notified for a multi-country breach, or non-EU controllers missing authorities
Late notifications	Check whether notices sent after 72 hours include reasons for the delay	Notification timestamp, delay explanation, record of phased updates	Reasons absent or generic, or delay caused by avoidable process gaps with no remediation
Out-of-hours operation	Walk through a simulated incident on a weekend or public holiday to see who decides and who sends the notice	On-call rota, escalation contacts, tested runbook, evidence of past after-hours drills	No named decision maker outside office hours, or contact details that are out of date
Detection capability	Confirm monitoring sources cover systems that hold personal data and that alerts reach responders	Log source inventory, detection rule list, alert routing configuration, sample alert records	Key systems or processors not feeding logs, or alerts routed to mailboxes no one monitors

Which evidence shows the 72-hour duty is met

An assessor or supervisory authority will work backward from the notification to find out when the controller became aware, what it did next, and why it decided as it did. The six artifacts below form that trail, and each one must be kept current between incidents, not assembled after the fact.

Detection and alert logs with timestamps

Raw and correlated alert records show when the first signal reached the monitoring stack. Keep the source logs in an append-only store with synchronized clocks, so the timestamps can be defended. Check that alerting rules fire for the systems that hold personal data, and that log retention covers the window an investigator would need to reconstruct the first signal.

Incident tickets showing triage and awareness

The incident record should state who triaged the alert, when, what was found and when the team concluded that personal data was compromised. That last entry is the working candidate for the awareness point under EDPB Guidelines 9/2022. Make sure tasks, status changes and evidence entries carry timestamps and user identities so the sequence can be shown without reconstruction from memory.

Signed risk assessment with reasons

Article 33(1) excuses notification where a breach is unlikely to result in risk to individuals, so the decision not to notify needs its own record. Document the data categories, volume, ease of identification, consequences and mitigations, and have an accountable person sign and date it. Keep records for breaches that were judged not notifiable, since the regulator can ask for them later.

Authority notification record

The notification record should show the competent supervisory authority, the send time, the channel used, the reference number returned and the phase number where information was provided in stages. Confirm the authority before sending, particularly for controllers outside the EU, where EDPB Guidelines 9/2022 require notice to each authority in whose Member State affected individuals reside. Store the sent copy with the case.

Reasons record for late notice

When the notification goes out after the deadline, Article 33(1) requires reasons for the delay. Record the awareness time, each step that consumed time, the cause of any gap, such as a lack of on-call coverage or an unclear escalation path, and the corrective action taken. A short, dated memo filed with the incident is enough, provided it is written at the time rather than rebuilt later.

Standing evidence between incidents

Assessors also look for proof that the process works when no incident is open. Keep tabletop exercise records that test the 72-hour clock, on-call rota records for the period covered, escalation contact lists with review dates, and detector tuning logs. Ask your monitoring vendor or implementation partner to confirm how these records are exported, since the format and retention settings depend on your own deployment.

How to implement the 72-hour notification process step by step

This sequence turns Article 33(1) into a working procedure, from deciding when awareness starts to proving afterward that the process ran. Each step produces a document, a configuration or a tested outcome that an assessor or supervisory authority can review.

Define the awareness criteria in writing
Start by agreeing with legal, security and the data protection officer when the organization treats itself as aware of a breach. EDPB Guidelines 9/2022 describe awareness as a reasonable degree of certainty that a security incident has occurred and has led to personal data being compromised, so the written criteria should name who can declare that point, what evidence they need and who is told at once. The output is a signed awareness standard that every on-call responder can apply without waiting for a meeting. Confirm the criteria against your own incident taxonomy before you rely on them.
Centralize log sources and alert routing
Send logs from identity providers, endpoints, servers, network devices, cloud services and business applications to one searchable store, and route alerts from detection tools into a single case queue. Without this, the time to become aware depends on which team happens to see an alert. Tools such as Wazuh and OpenSearch Security Analytics can match ingested logs against rules and forward alerts, and a case manager such as DFIR-IRIS can receive them. The output is a source inventory showing each log type, its owner and the alert channel, confirmed by a test event that reaches the queue.
Set triage and escalation with timestamps
Define triage tiers, named escalation paths and a rule that every alert and handoff records its time in a common time zone. The timestamps matter because the 72-hour period runs from awareness, so the organization must be able to show when each person first saw signals and when escalation occurred. Assign a deputy for each role so that absence does not stop escalation. The output is an escalation matrix and a case template that captures first detection, triage, escalation and declaration times in fixed fields.
Write the risk-test procedure and templates
Write a procedure that applies the Article 33(1) test: a breach is notifiable unless it is unlikely to result in a risk to individuals. Set out the factors your assessors weigh, such as the nature and volume of data, the ease of identifying people, and likely consequences, and record who decides and how the decision is documented. Prepare a notification template and a no-notification justification template so that either outcome is recorded. The output is an approved procedure with both templates, reviewed by the data protection officer before it is needed.
Map competent authorities by establishment and residence
Create a register that links each establishment, each Member State where data subjects reside, and the supervisory authority that handles each. The notice goes to the competent authority, and EDPB Guidelines 9/2022 explain that a non-EU controller subject to Article 3(2) must notify every supervisory authority in whose Member State affected data subjects reside, because a representative does not trigger the one-stop-shop. Keep contact details current and confirm the channels each authority accepts. The output is a dated authority map that the incident lead can use without research during an incident.
Rehearse the process with a tabletop exercise
Run a tabletop exercise that starts with a plausible incident, such as a misdirected export or a compromised mailbox, and follows the clock from first signal to a draft notification. Include the people who would really decide, the risk test, the authority map and the escalation path, and record where the process stalls. The aim is to find gaps in ownership and tooling before a real event. The output is a written exercise report with assigned actions, each with an owner and a due date set by the organization. DeployOpen can plan and facilitate this exercise as part of a scoped engagement.
Review the process after each incident
After every security incident, including those judged not notifiable, hold a review that compares actual timestamps with the awareness standard and checks whether the risk test and templates worked. Update the procedure, the authority map and the log coverage where the review shows a gap, and record the changes with version numbers. Keep the review record with the breach register described in Article 33(5), so the organization can show a supervisory authority how its process improved over time. The output is a versioned revision history and closed actions linked to the incident record.

What meeting the 72-hour duty costs in money and effort

This table compares the cost components of being able to notify within 72 hours, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for quotes: most of the spend is staff time and integration work, and self-hosted open-source tools mainly remove license fees while those other costs remain.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
Logging and detection tooling	Organization: staff time to run tools. Licenses are removed with self-hosted open source (OpenSearch, Wazuh, DFIR-IRIS), but hosting and storage remain	Recurring (hosting, storage, upgrades)	Number of log sources, log volume and retention period
Engineering time to wire sources and alerts	Internal platform team or implementation partner, under a written fixed scope	One-time build, then recurring tuning	Number and variety of log sources (hosts, network, cloud, SaaS), custom detection rules, alert routing
Legal and privacy review of the risk test	Internal DPO or counsel, or outside privacy counsel	Recurring per incident, plus one-time playbook drafting	Number of EU countries affected, data categories involved, and how often decisions must be documented
Tabletop exercises	Internal staff time, facilitator fees if external	Recurring (at least annual review is good practice to confirm with your auditor or regulator)	Number of participating teams, time zones, and whether third parties such as processors join
External incident response retainer	Retained responder firm, paid per retainer and per engagement	Recurring retainer plus per-incident work	Hours of guaranteed availability, cross-time-zone coverage, and whether forensic log retention is included
Staffing across time zones	Internal on-call staff or contracted coverage	Recurring	Hours in which someone must be able to classify an alert and start the 72-hour clock decision
Assessor sampling	Independent auditor or assessor, if the organization commissions an assessment	Recurring per assessment cycle	Number of breaches in the register, sample size the assessor selects, and quality of records
Processor notice integration	Organization and its processors, through contract and tooling changes	One-time contract work, recurring checks	Number of processors and sub-processors that hold personal data

Which self-hosted open-source tools support 72-hour detection and case records

Meeting the 72-hour clock depends on three things: detecting suspicious activity early, recording what the detections show, and keeping a case record that shows when awareness arose. The tools below cover different parts of that chain. None of them decides whether a breach is notifiable, and each needs confirmation that it fits your logging sources and licence obligations.

OpenSearch Security Analytics

Runs detectors that match ingested logs from hosts, network devices and cloud services against Sigma rules, recording each match as a finding with rule, log type and severity. Alerts can go to Slack or email, and its correlation engine links findings across log types. For Article 33(1), the findings and their timestamps help show when the controller had reasonable certainty of a compromise. Confirm that your log sources are onboarded, that detectors are tuned, and that the Apache-2.0 licence terms fit your distribution model.

Wazuh rules and alerts

Decodes collected logs and compares each event against a built-in ruleset plus custom rules, writing matches to alerts.log and alerts.json and mapping them to MITRE ATT&CK. The alerts.json output gives you a machine-readable timestamped trail to feed case tooling. Confirm the ruleset covers the systems holding personal data, that custom rules reflect your environment, and that GPL-2.0-only obligations are understood before you modify or distribute the software.

DFIR-IRIS case records

Keeps each incident as one case with assets, indicators, tasks and evidence, and an audit trail of changes. It triages alerts from SIEM, EDR and REST sources into cases and builds a consolidated timeline. Evidence can be logged with SHA-256 verification and chain of custody, and reports are generated from case data. Confirm that the case timeline can record the moment of awareness, that your roles permit this, and that the LGPL-3.0-or-later terms suit how you deploy it.

Nextcloud admin_audit logs

The admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit. This covers events on the Nextcloud platform itself, which matters when that platform holds personal data. Confirm that the events you need are captured, that the log path is protected and retained, and that logs reach your central detection tooling. Review AGPL-3.0-only obligations with counsel if you modify the app or offer it to users over a network.

Who owns the 72-hour decision, who builds the process and who assesses it

As controller, your organization owns the 72-hour clock. Article 33(1) requires the controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals. Nobody else can make that judgment or send the notice in your name. Under EDPB Guidelines 9/2022, awareness begins when there is a reasonable degree of certainty that a security incident has compromised personal data, so your people must be able to make that call quickly.

Risk decision: Your privacy and security leads decide whether the breach is likely to result in a risk to individuals and document the reasoning, including any decision not to notify.
Notification: Your named officers choose the authority, submit the notice in phases if facts are still emerging, and give reasons for any late filing.
Accountability: Your management accepts the fine exposure under Article 83(4)(a) for failing to meet Article 33.
Breach register: Your team records every breach, notifiable or not, under Article 33(5).
Staffing: Your organization sets on-call coverage so awareness is recognized outside business hours.

Check that your incident plan names the decision makers, the deputies and the authority contacts, and that these people can be reached within your own working hours.

Questions buyers ask about the 72-hour notification duty

How much does it cost to get ready for the 72-hour notification duty?

Readiness has no fixed price because the cost follows the scope agreed for your environment. The main components are internal staff time for the decision process, the logging and detection work that lets you become aware in time, the runbook and notification templates, and rehearsals. Open-source tools such as Wazuh and OpenSearch carry no licence fee under their own licences, but hosting, storage, tuning and day-to-day operation are costs you carry and must confirm separately. One-time work covers designing the process, building detections and writing templates. Recurring costs include log storage, on-call coverage, runbook updates after system changes and periodic exercises. Ask any provider for an itemized quote that lists deliverables, exclusions, who operates the tools after handover and what hosting is assumed. Set that quote against the exposure in Article 83, which allows fines for Article 33 failures of up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher.

How long does it take to put a 72-hour notification process in place?

Timing depends on scope. The main drivers are how many systems and cloud services already send logs to a central place, whether you run a SIEM, how many establishments and EU Member States are involved, and whether any written breach process already exists. Gaps in log sources or retention usually take the longest, because they depend on system owners who must change configurations and test them. A runbook, decision criteria and notification templates can often be drafted in parallel with the technical work. Ask for a written schedule with dated milestones for scoping, detection gaps, logging changes, runbook approval and a tabletop exercise, along with the dependencies each milestone relies on from your staff. A schedule that names your owners and approval steps is more useful than a single overall duration, because it shows where delays would come from.

Can our own team run the 72-hour process without outside help?

Many organizations can, provided the responsibilities are clear and the technical foundations exist. The controller owns the duty, so you need a named decision owner who can assess risk and sign off the notification within the window. A data protection officer or privacy lead should own the risk test and the breach register, and legal counsel should review the wording. Your security team needs to triage alerts, reconstruct timelines and record when awareness began. The usual gaps are incomplete log coverage, short log retention, no written risk criteria and no rehearsed template. Ask yourself whether your team has run a breach exercise against the clock in the last year. If the answers are no, an outside partner can help close the technical and documentation gaps, but the decisions stay with your organization.

What does the notification process require from our staff?

The work spreads across several roles, and each needs to know its part before an incident happens. The list below shows the usual split:

Security operations: monitor alerts, triage them, and log the time at which a security incident is confirmed.
Engineering and system owners: enable the log sources, keep retention long enough to reconstruct events, and restrict access to those logs.
Privacy or DPO function: apply the risk test, decide whether the breach is notifiable and keep the internal breach register.
Legal, management and communications: approve the notification, check the content and prepare later messages to individuals if needed.

Each role should hold a current contact list, know its deadline inside the 72 hours and have practiced the handoffs. Ask any provider to list these roles in the scope so that you can assign named people before work starts.

Can an outside partner send the notification to the authority for us?

The duty sits with the controller, so the notification should be made and approved by your organization, even when outside help is involved. A partner can prepare technical content, timelines, draft wording, evidence and forensic support, and can rehearse the process with your staff. Whether any outside party may submit on your behalf depends on your legal arrangements, your national supervisory authority's procedures and what your contracts allow, so confirm these with counsel before relying on it. DeployOpen plans, implements and documents self-hosted open-source platforms inside your infrastructure and prepares systems and evidence for assessments. It does not act as a supervisory authority, legal representative or certifying body. Put the division of tasks in writing, including who submits, who approves and who keeps the register.

Does the proposed 96-hour deadline change our duty today?

No. As of October 2026 the GDPR text has not been amended, so the 72-hour deadline in Article 33(1) still applies. The Digital Omnibus proposal (COM(2025) 837) would extend the deadline to 96 hours and limit notification to breaches likely to result in a high risk, and it is awaiting committee decision. The EDPB-EDPS Joint Opinion 2/2026 supports those changes, but a supportive opinion is not law. Plan around 72 hours and keep the process unchanged until the legislation is adopted and enters into application. Check the procedure status in the European Parliament's Legislative Observatory before any planning decision, because a change to the text would need to be reflected in your runbook and templates.

Which logs and tools help us become aware of a breach in time?

Awareness starts when the controller has a reasonable degree of certainty that a security incident has led to personal data being compromised, according to the EDPB's Guidelines 9/2022, so the clock depends on how quickly your detection turns signals into a confirmed incident. Central log collection from endpoints, servers, identity systems and cloud services is the foundation. Wazuh can decode events and compare them with a ruleset of over 3,000 built-in rules and decoders plus custom rules, and writes matches to alerts.json for review. OpenSearch Security Analytics runs detectors against Sigma rules and correlates findings across log types. DFIR-IRIS can then group alerts into one case with a timeline and evidence chain. For Nextcloud, the admin_audit app writes additional events to audit.log, which you should confirm is enabled and retained. Test each source by simulating an event and checking that the alert arrives.

How DeployOpen scopes and prepares the 72-hour notification process

DeployOpen helps organizations prepare the systems, logs and written procedures that let them decide quickly whether a breach is notifiable and reach the supervisory authority within 72 hours. We do not decide notifiability for the controller, and we do not file notifications on its behalf; the organization keeps that responsibility.

How we scope

We agree in writing which systems, logging sources and teams fall inside the Article 33(1) scope before work starts.
We record which supervisory authorities the organization would notify, based on where its establishment and affected data subjects sit.
We confirm with the organization who owns the notifiability decision and who signs off the notification.

How we build

We configure detection and log collection so that alerts on personal data systems reach a named responder without delay.
We build a case workflow in DFIR-IRIS that keeps assets, evidence, tasks and an audit trail from first alert onward.
We test the alert path with the organization's own staff so the time from detection to awareness is measured, not assumed.

How we hand over

We deliver a written 72-hour runbook covering the awareness point, the risk assessment step and the notification steps.
We provide a documented record of configured detectors, log retention settings and escalation contacts for the organization's files.
We hand over the runbook and records to the organization, which owns them and keeps them current after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing of the detection and case tooling are available as a retainer.
We can rerun the alert path and runbook exercise after significant changes to systems, staffing or supervisory authority contacts.
Confirm with DeployOpen during scoping exactly which support tasks sit inside the retainer and which are separate fixed-scope work.