Article 33 asks four things. The EDPB's new breach template asks 100.

It is Monday morning, and your weekend was worse than you knew. An engineer flags odd traffic. By noon you have pieced it together: on Saturday night, someone used a leaked API key to download your users table. Names, emails, password hashes. Forty thousand people.

Under the GDPR, a clock started the moment you understood what happened. Article 33 requires you to notify your country's data protection authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach. There is an exemption for breaches unlikely to put anyone at risk, and a stolen credentials table does not clear it. So you are filing a notification by Thursday. The question is what goes in it.

Article 33(3) keeps the required content short: describe what happened, give a contact point, describe the likely consequences, describe what you are doing about it. Four requirements, and until now the format was up to each country's authority.

In June, the EDPB (the European Data Protection Board, where the EU's data protection authorities coordinate) published a draft of one common form for all of them, open for public comment until 5 August 2026. I spent a morning reading it field by field. It is a Word document containing one very large table: 126 numbered rows, of which 26 are section headings, leaving 100 actual fields.

Most commentary treats four-versus-100 as the story: the form is too long. I think the length is a distraction. The real finding is that a large share of the fields are not about the breach. They are about your company as it was on Saturday night when the key was used: which vendors touch your data, where your systems run, what security measures were in place. You cannot find those things out on Monday with the clock running. You either recorded them beforehand, or you guess on a legal form.

Do you have to use this template yet?

No. It is version 1.0, adopted on 8 June 2026 and open for public consultation until 5 August 2026 at 23:59 CEST. Three things about its status, because coverage tends to blur them:

• It is not binding, and it is not final. The EDPB says it will decide on the timeline for rollout across supervisory authorities after the consultation. Both the content and the date can still change.
• It is built for software, not paper. The table has a "Business Logic" column with rules like visible only if "Type of notification" = "follow-up notification". The EDPB says it is primarily designed to be implemented by supervisory authorities in an IT tool.
• It could become mandatory by another route. The proposed Digital Omnibus Regulation also covers common templates for breach notification. That is still a proposal before Parliament and Council; nothing in it is in force.

And to be fair: as simplification, it mostly works. If you have ever notified two supervisory authorities about the same breach and found they wanted different information in different shapes, one common form is plainly good news.

How do four requirements become 100 fields?

First, the four requirements in the Regulation's own words. Article 33(3) says the notification "shall at least"

(a) describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned; (b) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained; (c) describe the likely consequences of the personal data breach; (d) describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.

Three of the four just say "describe". The template replaces describing with selecting: the nature of the breach becomes a choice between confidentiality, integrity and availability, then whether data was actually taken, likely taken, or not, then a list of incident types (ransomware, hacking, phishing, an employee abusing access privileges, and more), then whether the cause was internal or external, malicious or not.

I think that trade is honest. A free-text box invites you to write the paragraph that makes your incident sound as small as possible. A dropdown does not.

To be precise about the count: no breach triggers all 100 fields. 42 are marked mandatory outright (8 of those only in certain situations), 38 become mandatory only if an earlier answer makes them appear, and the remaining 20 are optional, conditional, or special cases. Which subset you get depends on the breach.

Which fields can you not answer during an incident?

Go back to Monday morning and put the template in front of you. For each mandatory field, ask where the answer would come from.

Many come out of investigating the incident: when it started, how you discovered it, what was taken, what you did about it. Your engineers are producing those answers right now. But a large share ask about your company rather than the incident, and they ask about it as it was when the breach happened. Four examples:

• Section 2.4 asks whether any data processor or joint controller was involved. Yes or no, mandatory. If yes, you name each one with contact details. Answering that honestly requires a list of your processors that already exists.
• Section 3.2 asks for a "Description of the systems, software, services, and infrastructures involved in the personal data breach and where they are located". Mandatory, free text. It is asking you to describe your architecture, in prose, for systems that were just compromised.
• Sections 3.3 and 3.4 ask which categories of people were affected (customers, employees, minors, patients, and more) and which categories of data (basic data, contact details, biometric data, criminal convictions, and more), each with a count. You may answer that a count cannot be determined, but the questions themselves are mandatory.
• Section 3.5 asks which security measures were in place when the breach occurred, as a twelve-item checklist: pseudonymisation, backup and recovery plan, data encryption, security policies, staff training, incident log, levels of access to data, logical access control such as MFA, periodic audits, physical access control, up-to-date IT systems, and other. Mandatory.

Section 3.5 is the one to sit with. It does not ask what your security posture is. It asks what it was, at a point in the past, for the specific systems involved. And not every breach is caught over one weekend. Suppose you shipped a change in March that widened access to the users table, the key leaked in April, and you only discovered the downloads in August. The honest answer to "levels of access to data" is a fact about March, and in most companies nobody wrote that fact down.

None of these questions is unreasonable, and all of them are answerable in principle. What they are not is answerable in 72 hours, while your engineers are busy containing the incident. Either you keep these records continuously, or you end up guessing on a legal form.

The obvious objection: under the GDPR you were supposed to have most of this already. Your record of processing activities should list your processors and security measures, and Article 33(5) makes documenting breaches an obligation in its own right:

The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken. That documentation shall enable the supervisory authority to verify compliance with this Article.

If you keep those records properly, much of sections 2.4 and 3.5 is transcription rather than research.

But the objection misses one thing. A record of processing is almost always kept as a living document: when something changes, someone edits it. A living document tells you what is true now. The template asks what was true when the breach began, and a document you edit in place cannot answer that, because every update deletes the previous answer. Keeping a record current and keeping its history are two different jobs, and most teams only do the first.

Why is my Privacy Policy a field in a breach form?

Section 4.1 asks for the likely consequences of a confidentiality breach. The first predefined option is:

Data were disclosed beyond the scope of the privacy policy or relevant legislation

I did not expect to find that in a breach form. To decide whether to tick that box, you compare what leaked against what your published Privacy Policy says you do with data. Not against the law. Against your own document.

Now consider what happens if that document is out of date. Say your Privacy Policy lists three categories of data, and the users table that leaked held a fourth you started collecting last year and never disclosed. Ticking the box documents that gap for the regulator. Leaving it unticked is worse. How serious a breach looks now depends partly on whether your published documents kept up with your product.

What are we doing about this at Lawcel?

A sentence of context, since not every reader knows us: Lawcel is a tool that keeps a company's legal documents, such as the Privacy Policy and Terms of Service, consistent with what the product actually does. It watches product changes and flags the ones that contradict something a published document says. We run it on our own company, and we hold other companies' compliance data, so this template is our problem too.

Going through the fields, two records we already keep turned out to be answers.

History. Every version of our legal documents is kept: what it said, when it was published, and by whom. The facts behind the documents get the same treatment, one dated entry per change rather than an edit that overwrites the old state. So "what did our Privacy Policy say in April" is a lookup, not an investigation. We did not build this for breach forms; you simply cannot keep documents consistent with a changing product without recording what changed and when. But that record is the one sections 3.5 and 4.1 assume you have.

Promises. Legal documents contain commitments with deadlines attached: how quickly you notify customers of a breach, how much notice you give before changing sub-processors, how fast you delete data. We keep those in a single list, because a deadline buried in a contract is the easiest thing to write and then forget. It matters here for one reason: if your data processing agreement promises customers breach notification within 24 hours, the GDPR's 72 hours is not your real deadline, and no regulator's template will remind you of that.

Neither of these is a breach-notification feature. They are ordinary record-keeping that turned out to answer questions the EDPB asked later. I expect that pattern to repeat: the difficult fields in this template are difficult precisely because they need history, and history only exists if someone was keeping it.

Where should you start?

With an exercise, not with the consultation. Open the template, go to sections 2.4, 3.2, 3.3, 3.4 and 3.5, and ask whether you could fill them in today about a breach that started three months ago and was discovered yesterday. Not whether you could eventually find out. Whether you could answer.

If you are reading this before 5 August 2026 and a field would be hard for you to answer honestly, say so through the EDPB's consultation form. The design can still change, and small companies are exactly the constituency the simplification agenda claims to serve.

If you are reading this later, the exercise still stands, because some version of this template is coming. The proposed Digital Omnibus would raise the risk threshold for notifying and extend the deadline, the EDPB and EDPS support it, and they have separately backed a single entry point for reporting personal data breaches. Fewer notifications, filed later, in one place, with much more specific content in each. The deadline is getting kinder. The questions are getting harder.

Whatever you cannot answer in the exercise is not an incident-response gap. It is a record-keeping gap, and a live breach is the worst possible moment to discover it.