What GDPR Article 33(3) and 33(4) require in a breach notification
A controller that becomes aware of a personal data breach must notify the supervisory authority within 72 hours, and often has to do so while the facts are still unclear. Article 33(3) sets the minimum content of that notification, and Article 33(4) allows the controller to provide the information in phases when it cannot all be given at once, without undue further delay. The regulator needs these facts to judge the likely harm to individuals, so a notification that says only that an incident occurred does not meet the Article. The four required elements are a description of the nature of the breach (including, where possible, the categories and approximate numbers of data subjects and of personal data records), the name and contact details of the DPO or another contact point, the likely consequences, and the measures taken or proposed to address the breach and mitigate its effects.
The difficulty is that the counts and consequences are usually the last facts to settle. Early in an incident, the team may know that a database was accessed but not which tables were read, how many people sit behind those rows, or whether any data left the environment. Writing the notification should therefore start with a checklist of what is known, what is estimated and what is still open, mapped to each Article 33(3) element. Ask who owns each item, which log sources can answer it, and how an approximate figure will be labeled so that it is not later read as a confirmed count. The EDPB's common breach notification template, adopted for public consultation on 10 June 2026, offers predefined options and guidance intended to make sure each required element is covered. Confirm the template's status and final form with the EDPB and your supervisory authority before you build it into a playbook.
The EDPB-EDPS Joint Opinion 2/2026 notes that some controllers use a layered approach: a first notification by the legal deadline with the information available, followed by a complementary notification as facts firm up. Decide in advance who may approve each stage, what the first stage must state at minimum, and which open items will trigger a follow-up. Keep a dated record of each submission and of the reasons information was incomplete, because the register required by Article 33(5) and any later review will test whether the phasing was justified. Confirm with your supervisory authority how it expects follow-up notifications to be submitted and referenced.
Which elements the notification must contain at minimum
Article 33(3) sets four minimum elements for a notification to the supervisory authority. Each one is answered at a different point in the investigation, so the first notification usually holds partial answers that a later phase completes. Read the cards as a checklist: decide what you can state today, what you can estimate, and what forensic work must close before you can state it.
Nature of the breach
Describe what happened: for example, unauthorized access to a customer database, exfiltration from a file share, or encryption of production systems by ransomware. Within the first hours you can usually state the type of incident and the systems involved, but not the full attack path. Ask your incident lead to separate confirmed facts from working assumptions in the notice, so later phases can correct them without contradiction.
Categories and approximate numbers
The notice should name the categories of data subjects (customers, employees, patients) and the categories of records (contact details, payment data, health data), with approximate counts where possible. Early counts are often ranges drawn from database tables, access logs or backup manifests. Document how each figure was derived, because the authority may ask how you arrived at it and a later phase can refine the estimate.
DPO or contact point details
Give the name and contact details of the Data Protection Officer or another point of contact who can answer follow-up questions. Confirm that the listed contact is staffed during the notification window and can receive mail from the authority. A generic mailbox with no one monitoring it is a common gap, and the contact should be the same person or team named in your breach response plan.
Likely consequences
Describe the likely consequences for individuals, such as identity theft risk, financial loss, discrimination, reputational harm or loss of confidentiality of sensitive data. This is an assessment, not a forensic finding, so it can be stated early with reasoning based on data types. Record the assumptions behind each consequence, because your assessment of risk also determines whether notifying affected individuals under Article 34 is required.
Measures taken or proposed
State the containment steps already completed, such as isolating hosts, revoking credentials or disabling a compromised integration, and the remediation planned. Proposed measures need owners and dates in the internal record. Forensic work often confirms or changes these measures, so the phased notice should say which steps are done and which are scheduled, without presenting planned actions as complete.
How phased notification works when facts are still emerging
Article 33(4) lets a controller provide the Article 33(3) information in phases when it cannot give everything at once. The key limit is that phasing does not postpone the first notice. The controller still notifies the supervisory authority within 72 hours of becoming aware of the breach, and the later phases must follow without undue further delay. Phasing is a way to deal with unknowns, not a way to wait until the investigation is finished. In practice this means the first notice should state what is known: the nature of the breach, the likely categories and approximate numbers of data subjects and records if they can be estimated, the contact point, the likely consequences, and the measures taken or proposed.
The EDPB-EDPS Joint Opinion 2/2026 describes a layered approach that matches this reading. A first set of information goes in by the legal deadline, and a complementary notification follows as the facts are confirmed. The EDPB's common breach notification template, adopted for public consultation on 10 June 2026, is designed to help controllers see which Article 33 items are still open so they can plan the second phase. Before relying on either the layered approach or the template in a live incident, confirm with your supervisory authority how it expects follow-up notices to be submitted and whether it accepts an incomplete first notice in its national form.
The controller should record, at the time of each notification, which information was missing, why it was missing, and when each missing item was supplied. This record is the evidence that the phasing was justified and that the later notices came without undue delay. It also feeds the internal breach register required by Article 33(5). Assign one person to own the open-items list, and make the decision to send a follow-up notice a documented step rather than an informal one. If the investigation changes the estimate of affected individuals or consequences, the complementary notice should say so and explain what changed.
How to build a notification that can be phased
This sequence turns Article 33(3) and 33(4) into a repeatable notification process, so the first notice goes out with the information the team already has and the complementary notice follows once the facts are confirmed.
Agree the minimum notification fields in advance
Start by writing a notification template that carries every field Article 33(3) requires: the nature of the breach with categories and approximate numbers of data subjects and records, the DPO or contact point details, the likely consequences, and the measures taken or proposed. The privacy lead and the DPO sign off the template, and the incident commander agrees which fields may be left open at first notice. Done means a single approved template exists, with each field marked as mandatory for the first notice or deferrable to a later one.
Map each field to a source of truth
For every template field, name the system that will supply the answer: the case record for the timeline and actions taken, the asset inventory for affected systems and hosting location, the log archive for the access window and the number of accounts involved, and the records of processing for the categories of data. Write the owner and the query or report that fills each field. Done means no field is left without a named source, and the team has confirmed that each source can be reached within the incident response period without waiting on a single person.
Set the content standard for a first notice
Define what a first notice must contain to be useful even when facts are incomplete. It should state what is known, what is not yet known, the date and time the organization became aware, the reason any figures are estimates, and the date by which the complementary information will follow. Ask legal counsel to review the wording of the standard so that statements about uncertainty do not later read as admissions or as a lack of diligence. Done means a written standard with a worked example, labeled as illustrative, that the on-call team can apply without drafting from scratch.
Define the complementary notification trigger and owner
Decide which events open a complementary notification, such as confirmation of the number of data subjects, discovery of exfiltration, identification of a new affected system, or a change in the likely consequences. Name one owner who holds the notification file, decides when a trigger has been met, and submits the update through the supervisory authority's channel. Done means a written trigger list, a named owner and a backup owner, and a reference to the first notice so every later update is linked to the original case.
Connect the forensic record to the notification file
Ensure the investigation tooling links each finding to the notification file. In a case management platform such as DFIR-IRIS, this means keeping assets, indicators, tasks and evidence in one case with an audit trail, and generating the timeline and report from that case data. Confirm that application logs, such as Nextcloud audit logs or OpenBao audit device output, are retained and can be exported for the period under review. Done means a dry run shows that a single timeline and evidence set can produce the figures for both the first notice and a later update without manual reconstruction.
Rehearse the phased notice in a tabletop exercise
Run a tabletop exercise with the incident team, DPO, legal counsel and communications lead using a hypothetical scenario labeled as illustrative. Require the team to produce a first notice from incomplete facts, then issue a complementary notice after new information arrives. Record where the template, the sources or the owners failed. Done means a written exercise report with corrected template fields, updated source owners and a list of gaps assigned to named people for closure before the next review.
Review the template against the EDPB common template
Compare the internal template with the EDPB's common breach notification template, adopted for public consultation on 10 June 2026, which offers predefined options and guidance to make sure notifications contain the information Article 33 requires. Confirm with the supervisory authority or counsel which version applies to your notifications at the time of use, since the template is still under consultation. Done means a mapping table between internal fields and the EDPB template fields, and a scheduled review date owned by the DPO.
How an assessor tests the notification content and phasing
This table sets out what an assessor compares when reviewing a controller's notifications to the supervisory authority, in the order the checks usually run. Read each row as a test step, the evidence it needs and the gaps that most often appear, so you can check your own notices before a review does.
| Test step | What the assessor compares | Common findings |
|---|---|---|
| Content against Article 33(3) | Each submitted notice is checked against the four minimum elements: nature of the breach with categories and approximate numbers of data subjects and records, DPO or contact details, likely consequences, and measures taken or proposed. | Notices omit approximate numbers, give no contact point, or describe measures without saying whether they are taken or planned. |
| Timestamps against the first notice | The time of awareness, the time of the first notice and the time of each later phase are compared to confirm the first notice was made within 72 hours of awareness or with reasons for delay. | The first notice is dated after the 72-hour mark with no reasons, or the awareness time in the notice differs from the incident log. |
| Missing fields explained | Where a field was blank at first notice, the assessor looks for a stated reason for the gap and a statement of when the information would follow. | Fields are left empty with no explanation, or the notice says information will follow but no later notice exists. |
| Later fields supplied | Each complementary notice is checked to see that it fills the gaps named in the first notice and refers back to it, without contradicting earlier statements. | Complementary notices arrive long after the gap is known, change the number of affected records without explanation, or repeat the first notice unchanged. |
| Consistency with the breach register | Facts in each notice are compared with the internal register of personal data breaches, including dates, data categories, counts, consequences and remedial actions. | The register records a different number of records or a different date, or a breach with effects is missing from the register because no notice was filed. |
| Forensic and log support | The assessor asks which logs, case records and evidence supported the scope and consequence estimates, and whether they can be produced with integrity. | Scope figures cannot be traced to logs, evidence is not preserved, or estimates change between phases with no recorded basis. |
| Use of the EDPB template | Where the controller used the common breach notification template, the assessor checks that predefined options were completed accurately and that free text matches the selections. | Template options are selected inconsistently with the narrative, or the template is not used and the notice does not map to the Article 33(3) elements. |
Forensic and log data that supports scope and consequence estimates
A first notification is an estimate, and the estimate is only as good as the records behind it. The cards below cover the sources that let an incident team move from "we think about this many people" to a defensible count of records and data subjects, and that keep working between incidents.
Case records and timelines
A single case record holds the assets, indicators, tasks and evidence for one incident, with an audit trail of who changed what. A consolidated timeline shows when the breach began, when the controller became aware and when containment happened, which is the basis for the Article 33(1) clock and for explaining any gap in the first notice. Check that your case tool keeps the audit trail on by default and that analysts record decisions as they make them, not afterwards. DFIR-IRIS is one open-source option that keeps cases in this form.
Asset and data inventories
An inventory maps each system to the personal data categories it holds, the data subject groups involved and the sub-processors that touch it. Without it, a team can confirm that a server was accessed but not whether it held health data, children's records or only business contacts. Keep the inventory tied to the record of processing so that it is current before an incident, not reconstructed during one. Ask who owns each entry and how often owners confirm it.
Authentication and API audit logs
Identity provider logs, application audit trails and API request logs show which accounts and tokens accessed which records, and over what period. These logs usually decide whether the affected count is a few accounts or a whole table. Confirm which applications write audit events, where those events are stored and whether a long-running export can be pulled without disturbing production. For example, Nextcloud's admin_audit app writes additional event information to audit.log in the data directory, or to a path set with logfile_audit, so the path must be captured and included in backups.
Endpoint and host telemetry
Process, network connection, kernel module and file hash data from endpoints shows how an intruder moved and which hosts can be ruled out. osquery exposes these items as SQL tables, and its osqueryd daemon can schedule the same queries across a fleet, so the answer to "which hosts had this connection" can be given in hours rather than by manual inspection. Before an incident, confirm retention for query results, because a host that was rebuilt will not give its history back.
Secrets access and API traces
Logs from secrets managers show which workloads read credentials, and whether those credentials could open further personal data stores. OpenBao audit devices record a detailed JSON log of every API request and response, including errors, with most sensitive values hashed using HMAC-SHA256. Check that the audit device is enabled before an incident, that its output is shipped off the host, and that your team can correlate hashed values with the workload that presented them.
Evidence chain of custody
Evidence that will support a notice, a regulator's questions or a later fine must be collected in a way that shows it was not altered. Record each item with a hash, the collector, the time and the storage location, and keep a log of every access. DFIR-IRIS logs evidence with SHA-256 verification and chain of custody, which is one way to meet this need. Confirm with your legal and forensic teams how long the controller's policy requires evidence to be kept, since that period is set by the controller rather than by the GDPR.
Which open-source tools produce the data behind a notice
DFIR-IRIS is the place where the incident team keeps one case for each breach investigation. It is not a log source in the usual sense, but it holds the working record that the notice draws on: which assets were affected, which indicators were found, what tasks were run and by whom, and what evidence was collected. The tool is licensed under LGPL-3.0-or-later. It does not decide whether a breach is notifiable under Article 33(1), and it does not write the notice to the supervisory authority. Those remain decisions and drafting work for the controller's privacy and incident team.
- Assets and indicators: Affected systems, accounts and indicators of compromise are attached to the case, so the team can state the systems involved and the likely consequences with a consistent scope.
- Consolidated timeline: The investigation timeline lets the team date the first detection, the point of awareness and the containment steps, which the 72-hour analysis depends on.
- Evidence with chain of custody: Evidence entries carry SHA-256 verification and custody records, which supports the facts the controller later relies on.
- Alert triage: Alerts from SIEM, EDR and REST sources can be grouped into cases, which helps show when relevant signals first arrived.
- Reports from case data: Reports generated from the case give the team a versioned internal account to compare against each phased notification.
Confirm with the vendor and your own deployment how the audit trail and report templates are configured before relying on them as notification evidence.
For a self-hosted collaboration or file platform, the application's own audit log shows who accessed, changed or shared personal data and when. In Nextcloud, the admin_audit app writes additional event information to an audit log in the data directory, or to a path set with the logfile_audit key. The app is licensed under AGPL-3.0-only. It shows what the application recorded, which helps scope the affected records and data subjects, but it does not establish whether the event was a breach, and it does not write the notice.
- Event coverage: Confirm which events the admin_audit app records in your version, since scope questions depend on what was logged and what was not.
- Log location: The file is written to the data directory by default, or to the path set with
logfile_auditinconfig.php. Check that the path is stored on protected, retained storage. - Access to the log: Restrict who can read or modify the audit file, because the log is itself evidence and must be preserved intact.
- Retention and rotation: Set rotation and retention so that logs covering the period before awareness are still available when the team estimates scope.
- Linkage to cases: Record the log extracts used for each finding in the case so the figures in the notice can be traced back to source.
Check the logging configuration with the vendor documentation for your release, and test that the events needed for a scope estimate are actually written.
OpenBao audit devices record a detailed JSON log of every API request and response, including errors. Most sensitive values are hashed with HMAC-SHA256 before they are written. For a breach investigation this log shows which identities requested which secrets or policies, when, and whether the requests succeeded. The project is licensed under MPL-2.0. It does not tell the team whether a stolen credential exposed personal data, and it does not decide notifiability or write the notice. Those tasks still depend on mapping the secrets to the systems and datasets they protect.
- Request-level detail: Each API request and response is logged, including errors, which helps reconstruct a sequence of access attempts.
- Hashed sensitive values: Most sensitive values are stored as HMAC-SHA256 hashes, so the log supports correlation without exposing the secret, but it cannot show the secret value itself.
- Device configuration: Confirm that at least one audit device is enabled and that the log destination is protected and retained, because a missing device leaves a gap.
- Mapping to data: Keep a current map of which secrets and paths protect which systems, so the team can state which personal data may have been reachable.
- Secret rotation records: Record when credentials were rotated after the incident, since the notice describes the measures taken.
Confirm the audit device options and log format for your OpenBao version with the project documentation before building procedures around them.
osquery exposes operating system state as SQL tables, including running processes, loaded kernel modules, open network connections, browser plugins, hardware events and file hashes. Its osqueryd daemon can schedule the same queries across an entire fleet of hosts, which lets the team check many endpoints for the same indicators in a short period. The project is dual-licensed under Apache-2.0 OR GPL-2.0-only. It shows the current and recent state of hosts, but it does not prove what data was accessed, and it does not decide notifiability or write the notice.
- Fleet-wide hunting: Scheduled queries can run the same check on every host, which helps establish whether an indicator was present and where.
- Connection and process state: Open network connections and running processes help identify command-and-control activity and the hosts that held it.
- File hashes: Hash queries let the team compare files against known indicators and record which hosts contained them.
- Limits of point-in-time data: Results reflect the state when the query ran, so the team should confirm retention of results in a central store to cover earlier periods.
- Recording results: Export query results into the case so each host finding is traceable in the record.
Before relying on osquery for scope, test the queries in a lab, confirm the deployment's logging and retention settings, and document what each query could and could not show.
Where organizations fall short on notification content
Most notifications to the supervisory authority fail on content rather than timing. The gaps below tend to appear together when no one has prepared the notice before an incident, and each one can be closed with a template, a shared timeline and a named contact.
Notices sent without the minimum fields
Article 33(3) sets a floor: the nature of the breach, the categories and approximate numbers of data subjects and records, the contact details, the likely consequences, and the measures taken or proposed. Drafts often describe the incident in general terms and skip the counts or the consequences. Check each notice against those five elements before it leaves the building, and record any element that is still unknown with the reason it is unknown.
No pre-agreed template
When the first draft is written during the incident, the wording, the sections and the level of detail change from one notice to the next. Staff then spend the early hours deciding what to include rather than gathering facts. The EDPB has adopted a common breach notification template for public consultation, and organizations should compare their own form against it. Agree one internal template before any incident, with named owners for each section and a version history.
No link between timeline and notice
The facts in the notice must match the forensic record. When the case timeline lives in a ticket, the notice is drafted from memory, and dates or affected systems drift between documents. This is a problem for the authority, which may compare the notice with later reports. Draw every statement in the notice from a case record with a timestamp and source, so the counts and consequences can be traced back to evidence.
No trigger for complementary notices
Article 33(4) allows information to follow in phases, but only if the controller knows when a follow-up is due. The EDPB-EDPS Joint Opinion 2/2026 describes layered notification, where a first set of information arrives by the deadline and the rest follows in a complementary notice. Without a defined trigger, the follow-up is forgotten or sent late. Set named events, such as completion of log review or a confirmed record count, that start the complementary notice.
DPO contact details missing or outdated
Article 33(3) requires the DPO's details or another contact point, and a notice that names a departed officer or a mailbox nobody monitors delays the authority's follow-up. Contact details often sit in a privacy notice and are not reviewed after staff changes. Confirm the DPO's current name, direct line and monitored mailbox before each exercise, and name a deputy who can sign the notice when the DPO is unavailable.
Questions buyers ask about phased breach notification
Is phased breach notification allowed under the GDPR?
Yes. Article 33(4) allows the information to be provided in phases when it is not possible to give all of it at the same time, as long as each phase arrives without undue further delay. The first notice still has to reach the supervisory authority within the 72-hour deadline in Article 33(1), so phasing does not extend that clock. The EDPB-EDPS Joint Opinion 2/2026 notes that some controllers already use a layered approach, sending a first set of information by the legal deadline and the rest in a complementary notification. Your job is to decide in advance what the first notice must contain, and to document why the remaining details were not yet known.
What happens if the first breach notice is incomplete?
An incomplete first notice is acceptable only if the missing items genuinely could not be established in time and you follow up without undue delay. Article 33(3) sets the minimum content: the nature of the breach, including where possible the categories and approximate numbers of data subjects and records, the contact point, the likely consequences, and the measures taken or proposed. Gaps in those items are the ones an authority will question. Record what you knew, when you knew it, and what you were doing to close each gap. The EDPB's common breach notification template, adopted for public consultation on 10 June 2026, offers predefined options intended to help notifications cover the required information.
How much effort does a phased notification take?
Effort depends mainly on how quickly you can establish scope, not on the notification itself. The work includes triaging the incident, identifying affected systems, estimating the data subject and record counts, and tracing what was accessed or exfiltrated. Log sources drive most of that time. Nextcloud's admin_audit app writes to audit.log, OpenBao audit devices record every API request and response with sensitive values HMAC-SHA256 hashed, and osquery can run fleet-wide queries for processes, network connections and file hashes. No public effort figure has been confirmed for this work, so ask any partner for a written estimate based on your own environment and log retention.
Can we run phased notification and the investigation in-house?
Yes, many organizations do, provided they have people who can run the forensic work and the legal and DPO review inside the deadline. The organization owns the decision to notify, the content of the notice and its submission. What you may need outside help with is preparing the logging, building the case record and timeline, and rehearsing the process before an incident happens. DFIR-IRIS keeps each case as one record of assets, IOCs, tasks and evidence with an audit trail, builds a consolidated timeline and logs evidence with SHA-256 verification and chain of custody, which helps internal teams assemble the layered notices consistently.
What does an implementation partner need from us?
A partner needs access to the environment, a named decision-maker, and clear answers on what your systems log and for how long. Before any incident, the useful inputs are your log sources, retention periods, storage locations, SIEM and EDR coverage, and your current incident contacts and DPO details. DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the work is scoped in writing before it starts. A partner can configure logging and case management and prepare evidence. It cannot issue regulatory notices on your behalf or decide whether a breach is notifiable.
How do the pending Omnibus proposals affect breach notification?
As of October 2026, the GDPR text has not been amended, so Articles 33 and 34 apply as written. The Omnibus IV proposal (procedure 2025/0130(COD)) has a text agreed in interinstitutional negotiations on 26 June 2026 and is awaiting Parliament's first-reading vote. The Digital Omnibus proposal (procedure 2025/0360(COD)) is awaiting committee decision. Plan against the current text, and check the European Parliament Legislative Observatory before finalizing your procedures, since the status of both files may have changed. Confirm with your legal counsel how any adopted changes would apply to your notification workflow.
Which logs must we keep to support a phased notice?
Keep logs that let you answer the Article 33(3) questions quickly: what happened, which systems, which data categories, how many people and records, and what you did about it. Authentication and admin audit trails, API request logs, endpoint process and network data, and a case record with timestamps are the core sources. Confirm retention periods against your own legal and contractual obligations, because logs that roll over before an investigation starts cannot support an estimate later. Test that you can export them during a tabletop exercise, not for the first time during a live incident.
How DeployOpen prepares systems and evidence for this requirement
DeployOpen prepares the logging, case management and documentation that let your team describe a personal data breach in the required detail and update the supervisory authority in phases. We do not decide whether a breach is notifiable or file the notification; your organization owns that decision and the filing.
How we scope
- Each engagement is fixed-scope, with the systems, data sources and deliverables for Article 33(3) agreed in writing before work starts.
- The written scope names which platforms supply forensic and log data, such as identity, file sharing, secrets and endpoint telemetry.
- We confirm with your legal and DPO function which fields the internal notification template must capture for the authority.
How we build
- We configure self-hosted case management in DFIR-IRIS so each incident keeps assets, indicators, tasks, evidence and a single investigation timeline.
- We set audit logging in Nextcloud and OpenBao so requests, errors and access events are retained in a form investigators can query.
- We deploy osquery queries across the fleet to capture processes, network connections and file hashes that help estimate affected records.
How we hand over
- You receive documented runbooks for phased notifications, showing which facts are needed at the first deadline and which follow later.
- Evidence handling procedures cover SHA-256 verification and chain of custody, so the figures in a notification can be traced to source records.
- Handover includes a tested report template generated from case data, with fields mapped to the Article 33(3) content items.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover, including updates when the EDPB template changes.
- We can run tabletop exercises that practice a layered first notice followed by a complementary notice, using your own systems and contacts.
- Confirm with us the response times and support hours in the written scope, since these depend on the agreed retainer terms.
