If you suffer a data breach you must contain it, assess the risk to people and, unless the risk is unlikely, notify it to the Garante per la protezione dei dati personali, the Italian Data Protection Authority, without undue delay and, where feasible, within 72 hours of becoming aware of it. If the risk is high, you must also tell the data subjects. In every case the breach must be written into the internal register, even when you do not notify it.
The 72 hours go quickly, especially if the incident arrives on a Friday evening and nobody knows who has to decide. This guide sets out in order the obligations under the GDPR, what the Garante's procedure requires and, for organisations within the scope of NIS2, the parallel notification to CSIRT Italia. At the end you will find an hour-by-hour timeline and the mistakes we see most often.
What a data breach is under the GDPR
Article 4(12) of the GDPR defines a personal data breach as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed. You will find the short definition in the glossary.
Two things matter. First: no attack is needed. An email with an attachment sent to the wrong recipient, or an unencrypted laptop left on a train, are data breaches in every sense. Second: not every security incident is a data breach. If an attack takes down a server that holds no personal data, you have a cyber incident but not a breach within the meaning of the GDPR.
The European guidelines classify breaches by the security principle affected. A breach can involve more than one at once:
| Type of breach | What happens | Example |
|---|---|---|
| Confidentiality | Data disclosed to or accessed by someone who should not have it | A compromised mailbox, a file shared with a public link |
| Integrity | Data altered without authorisation | Suppliers' bank details changed in the master data by someone who broke into an account |
| Availability | Data lost or inaccessible, even temporarily | Ransomware encrypts the management software and the backups cannot be used |
When the 72 hours start
The deadline runs from the moment the controller becomes aware of the breach. According to the guidelines of the European Data Protection Board (EDPB), this happens when the controller has a reasonable degree of certainty that a security incident has occurred that has compromised personal data. A short initial period of investigation to establish whether a breach has really occurred is allowed. Putting off the investigation so that the clock does not start is not.
If the breach happens at a supplier that processes data on your behalf, that is a processor, Article 33(2) requires it to inform you without undue delay after becoming aware of it. For the EDPB, the controller is considered aware once the processor has informed it. That is why your contract with suppliers must say how and how quickly they will notify you: it is one of the points to check in supplier qualification.
Notifying the Garante: what Article 33 requires
Article 33 requires the breach to be notified to the competent supervisory authority, which for Italy is the Garante per la protezione dei dati personali, without undue delay and, where feasible, within 72 hours. If the notification arrives after 72 hours, it must be accompanied by the reasons for the delay.
Since 1 July 2021, notifications to the Garante can only be sent through the dedicated online procedure available on the Authority's online services portal. On the Garante's data breach page (in Italian) you will find the link to the procedure and a self-assessment tool that helps you work out what action to take after a breach.
The minimum content of the notification is set by Article 33(3):
- The nature of the breach, with the categories and approximate number of data subjects and records concerned
- The name and contact details of the data protection officer (DPO) or another contact point
- The likely consequences of the breach
- The measures taken or proposed to address it and, where appropriate, to mitigate its effects
You do not need to have every answer within 72 hours. Article 33(4) allows the information to be provided in phases, without further undue delay, when it cannot all be provided at the same time. A first notification that is complete as far as you know, followed by updates, is better than a perfect notification that arrives late.
When you do not need to notify the Garante
Notification is not required when the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The assessment considers the type and volume of data, how easily people can be identified, the severity of the consequences, the number of data subjects and whether they are vulnerable.
Examples where the risk may turn out to be unlikely: data that had already been lawfully made public, or a lost device holding strongly encrypted data whose key has not been compromised and of which a backup copy exists. Note that last detail: encryption protects confidentiality, but if the data existed only there you have still lost availability.
The decision not to notify must be justified and written into the breach register. If the Garante asks, you must be able to show how you reached that conclusion.
| Risk level | Internal register | Notification to the Garante | Communication to data subjects |
|---|---|---|---|
| Risk unlikely | Yes | No | No |
| Risk | Yes | Yes, within 72 hours where feasible | No |
| High risk | Yes | Yes, within 72 hours where feasible | Yes, without undue delay, except in the cases set out in Article 34(3) |
Telling data subjects: Article 34
When the breach is likely to result in a high risk to people's rights and freedoms, Article 34 requires it to be communicated to the data subjects as well, without undue delay. The purpose is practical: to let people protect themselves, for example by changing a password, blocking a card or watching out for targeted phishing attempts.
The communication must be written in clear and plain language and contain the nature of the breach, the contact details of the DPO or another contact point, the likely consequences and the measures taken or proposed. It is not needed if one of the conditions in Article 34(3) applies:
- the data was protected by measures that make it unintelligible to anyone not authorised, such as encryption;
- after the breach you have taken measures that ensure the high risk is no longer likely to materialise;
- contacting each person would involve disproportionate effort: in this case you use a public communication or a similar measure that is equally effective.
Having assessed the risk, the Garante can still require you to communicate the breach to the data subjects (Article 34(4)).
The breach register (Article 33(5))
Article 33(5) requires the controller to document any personal data breach, including the facts, its effects and the remedial action taken. This applies to all breaches, including those not notified. The register allows the Garante to verify compliance with Article 33, and allows you to avoid repeating the same mistakes.
A useful register contains at least:
- Date and time of the event and of its discovery, and who detected it
- A description of what happened and the type of breach (confidentiality, integrity, availability)
- Categories of data and of data subjects, with approximate numbers
- The risk assessment and the reasons for the decision to notify or not
- The dates of notification to the Garante and of communication to data subjects, if they took place
- Containment, remedial and preventive measures, with the people responsible
NIS2 notification to CSIRT Italia
If your organisation is an essential or important entity under Legislative Decree 138/2024 (D.Lgs. 138/2024, the Italian law transposing NIS2), significant incidents must be notified to CSIRT Italia, part of ACN, Italy's National Cybersecurity Agency. If you are not sure whether you are in scope, start from the guide NIS2: who must comply.
The scheme has several stages, always counted from awareness of the significant incident:
- Within 24 hours: a pre-notification, the early warning
- Within 72 hours: the incident notification, which updates the pre-notification with an initial assessment of severity and impact
- At the request of CSIRT Italia: intermediate reports with updates
- Within one month of the notification: the final report
The two notifications are separate obligations, to different authorities, with different criteria. The GDPR looks at the risk to the people whose data is involved; NIS2 looks at how significant the incident is for the entity's services. Ransomware that encrypts the management software of a NIS2 entity can trigger both: notifying CSIRT Italia does not replace notifying the Garante, and vice versa. It is best to prepare a single set of facts and feed both communications from it, so the information stays consistent.
The timeline: what to do, hour by hour
The legal deadlines are the ones set out above. The sequence below is an operational outline for meeting them without a scramble: adapt it to your organisation and write it into your incident handling procedure before you need it.
| When | What to do | Who |
|---|---|---|
| Hour 0 | The event is reported. Note the date and time of discovery: the deadlines run from here. | Whoever detects it, then the incident contact |
| First few hours | Containment: isolate the systems involved, change compromised credentials, preserve logs and evidence without deleting them. | In-house IT or supplier, SOC if there is one |
| Within the first 24 hours | Call together the response team and the DPO. First assessment: is personal data involved? Whose, how much, of what type? For NIS2 entities: send the pre-notification to CSIRT Italia if the incident is significant. | Response team, DPO, management |
| Between 24 and 48 hours | Assessment of the risk to people, gathering of the information required by Article 33(3), a reasoned decision on notification and communication. | Controller with the DPO |
| Within 72 hours | Notification to the Garante through the online procedure, even if partial. For NIS2 entities: incident notification to CSIRT Italia. | Controller |
| As soon as possible | If the risk is high, communication to data subjects. There is no need to wait for the 72 hours: the sooner it arrives, the sooner people can protect themselves. | Controller |
| Following days | Eradication of the cause, restoration from verified backups, updates to the notification as new facts emerge. | IT, suppliers, response team |
| Within one month | For NIS2 entities: final report to CSIRT Italia. | NIS2 contact |
| Closure | Breach register completed, lessons learned, measures and procedures updated. | Controller, DPO |
Common mistakes
The mistakes that make organisations miss the deadlines all look alike. Almost none of them concern the law: they concern the organisation.
- Nobody knows who decides. If roles are not assigned in advance, the first hours are lost working out who has to do what.
- Waiting until you know everything. Notification in phases exists precisely so that you do not miss the 72 hours. A late notification without reasons is a breach in itself.
- Wiping the traces. Reinstalling a compromised server straight away destroys the logs you need to understand what got out. Preserve first, restore afterwards. This is where access logs kept in good time prove their worth.
- Not recording "minor" cases. The email sent to the wrong person goes in the register even if you do not notify it.
- Mixing up the notifications. Thinking that notifying CSIRT Italia also covers the Garante, or the other way round.
- Forgetting suppliers. If the contract with the processor does not set timescales and methods for reporting, the breach may reach you days late.
- Never testing the procedure. A simulation, such as a cyber drill, shows up the gaps while they cost nothing.
Finally, remember that infringements of the obligations in Articles 33 and 34 are among those for which Article 83(4) of the GDPR provides for administrative fines of up to 10 million euros or, for undertakings, up to 2% of total worldwide annual turnover, whichever is higher.
72 hours is not enough time to get organised. It is enough time to carry out a procedure that already exists.
For further reading, the EDPB Guidelines 9/2022 on personal data breach notification are the European reference for interpreting Articles 33 and 34.
How Dottor Box helps
The Incident Response module makes you decide in advance who does what: fifteen response roles already defined, to be assigned to people in your organisation, and a single contact for the team. When an event happens, the data breach register takes it in with the checklist of phases, from preparation to lessons learned, with an owner and a status for every action. The event report in PDF documents what was done.
With the MDR + SOC levels, Dottor Marc takes on the role of Incident Response Team Lead and our SOC works with your team on reported incidents: you will find the details in SOC and MDR. Further upstream, Dark Web Monitoring alerts you to company credentials that have ended up in other organisations' breaches, often the first step of an attack. If you are setting up your NIS2 programme, the NIS2 compliance page brings all the pieces together.