You have had a data breach. What the first 72 hours require

A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. That definition is wider than an attack. It says 'accidental or unlawful'. The Data Protection Commission (DPC) says in its guidance that breaches include both accidents and deliberate acts. Its example of an accident is an email sent to the wrong recipient.

The DPC received 6,521 valid breach notifications in 2025, a 16% decrease on 2024. Of those, 5,692 were made under the GDPR and 731 under the telecoms rules in S.I. No. 336 of 2011. The annual report says half of all notifications arose from correspondence sent to the wrong recipient. The DPC's release the same day put it at almost half.

The example the DPC's annual report gives is not a hack. It is poor operational practice and human error: a wrong document put into an envelope addressed to an unrelated third party. The next section takes that case first.

Not every security incident is a data breach. The European Data Protection Board says all personal data breaches are security incidents, but not all security incidents are personal data breaches. An incident that reached no personal data is outside the breach rules (Articles 33 and 34).

Other reporting rules can still apply to it. NIS2, the EU cyber security directive, has incident reporting of its own. The National Cyber Security Centre's NIS2 page still showed 24 June 2025 as its last update when read on 15 October 2026. It says Ireland missed the 17 October 2024 deadline for making the Directive Irish law. It says the older NIS1 rules still apply to operators of essential services already designated. And it says the NIS2 incident reporting portal will be available once the legislation is in place. Where NIS2 stands in Ireland has the rest.

When the wrong recipient tells you they have received one of your customers' details, and shows you, the EDPB gives that as a case where there can be no doubt you are aware. If you spot the mistake yourself, the test is the same: a reasonable degree of certainty that personal data has gone where it should not. The clock has started.

The EDPB's guidelines on breach examples treat misdirected mail as human error with no malice behind it, where little can be done once it has happened. In the first hour, you can do this.

You must tell the DPC without undue delay and, where feasible, not later than 72 hours after becoming aware of the breach. The exception is a breach that is unlikely to result in a risk to people's rights and freedoms (Article 33(1)). If you notify later than 72 hours, you must give the reasons for the delay.

Awareness starts the clock, and it is a lower bar than certainty. You are aware once you have a reasonable degree of certainty that a security incident has compromised personal data. The EDPB's guidelines allow a short investigation to establish whether a breach has happened, and during it you may not count as aware. They expect that check to start as soon as possible. In most cases, they say, it should be finished soon after the first alert, and take longer only in exceptional cases.

Nothing in Article 33 waits for the investigation to finish. You can send the information in stages, without undue further delay, and a first notification can be followed by more (Article 33(4)).

The 72 hours does not stop for a weekend or a public holiday. Article 33(1) makes no exception for either. On the 72 hours, the EDPB's guidelines point to Regulation 1182/71, the EU rules on periods and time limits. Under that Regulation a period includes Saturdays, Sundays and public holidays. Only a period not expressed in hours is extended when it ends on one of those days. The Regulation is written for acts of the Council or the Commission, and the GDPR is an act of the Parliament and the Council. That makes this a pointer from the Board, not a rule in the GDPR itself.

The other statutory clocks, from the month you have to answer an access request onwards, are set out in one place.

A supplier that handles personal data for you (a processor) must tell you without undue delay after becoming aware of a personal data breach (Article 33(2)). There is no 72 hour figure in it, so any specific deadline has to come from your contract with them.

That does not give the supplier more time. The EDPB treats you as aware once the supplier has told you. Every day a supplier sits on the news is a day nobody is assessing the breach or deciding whether to notify. The EDPB recommends that the supplier tell you promptly, with details following in stages, and says the contract can require early notification. That is why your contract with the supplier (the processor agreement) should set a specific deadline for telling you.

If you are the supplier, the same rules apply to you from the other side. The EDPB says you do not need to assess the risk before telling your client: that assessment is the client's. You establish that a breach has occurred, then tell the client. Where one incident affects several clients, you have to report the details to each of them. If you host or run something for a client, work out now who you ring and how fast.

The DPC's guidance says that as soon as you become aware of a breach, you should try to contain it and assess the risk it could cause. Both start at once. In practice:

The DPC's Breach Notification Form asks you to declare how severe the risk to the people affected is, on four levels. The DPC's breach notification page defines the same four levels. It tells you to weigh the nature of the breach, its cause, the type of data exposed, the mitigating factors in place, and whether vulnerable people's data was exposed.

The four levels are the DPC's own scale. Its page expects the rating in your internal record even for a breach you decide carries no risk. No level is tied to the test for notifying the DPC (Article 33(1)): neither the page nor the form says which level means you need not notify. The DPC's 2019 practical guide does tie one level to telling the people affected (Article 34). If you rate the risk as High, it says, you must tell the people affected without undue delay.

The legal tests are the ones in Articles 33(1) and 34(1). The form asks the first of them in its opening questions: is the breach likely to result in a risk to the rights and freedoms of individuals? Answer no, and the form says you do not have to notify, but must still record the breach (Article 33(5)).

The form also states the default: all breaches are notified, except those the controller has assessed as unlikely to present any risk and can show why.

The same guide gives a case that did not need notifying. An organisation had notified the DPC, more than once, that supporting documents it had scanned were saved to the wrong person's electronic folder. The data stayed with the organisation, unaltered and not disclosed to anybody unauthorised, and was moved to the right folder when the error was found. The DPC concluded that those incidents did not warrant notification under Article 33(1), because there was no identifiable risk. Article 33(5) still required each one to be recorded.

The DPC checks your rating against the facts. Its 2019 practical guide describes an organisation that rated a breach as Low. A scam email (phishing) had led to a breach of an employee's email account, holding about 400 people's data, and one of those people had already been defrauded. The DPC found it likely to result in a high risk, which meant the people affected had to be told.

The DPC's 2025 report says 55% of the breaches reported to it that year were of low risk, or no risk to the people concerned could be identified.

If you did a data protection impact assessment for the processing involved, it may already give a first view of the risk. The EDPB says that view may be more general than the breach in front of you, so the breach still needs its own assessment.

Telling the people affected is the second question, and the bar is higher. You must tell them where the breach is likely to result in a high risk to their rights and freedoms (Article 34).

Article 34(2) sets what the message must contain. It describes the nature of the breach in clear and plain language. It also gives at least: the name and contact details of your data protection officer or another contact point for more information; the likely consequences of the breach; and the measures taken or proposed to deal with it, including, where appropriate, measures to reduce its possible harm. Those are the same points (b) to (d) of Article 33(3) that go to the DPC.

Article 34(3) gives three exceptions. First, where you had already applied appropriate technical and organisational protection measures to the data, in particular measures that make it unreadable, such as encryption. Second, where you have since taken measures that ensure the high risk is no longer likely to happen. Third, where telling each person would take disproportionate effort. In that case there has to be a public announcement or a similar measure instead.

The first is a practical reason to encrypt what you hold. A stolen laptop that is encrypted, where the thief does not have the key, is a very different matter from a stolen laptop with nothing encrypted.

If you have not told them, Article 34(4) lets the DPC require you to. Its 2019 guide describes a public body that rated a website security incident Low. The DPC found a likely high risk, with none of the exceptions applying, and directed it to tell the people affected.

Article 33(1) accepts a notification after 72 hours only with reasons for the delay. In three recent decisions the DPC fined the lateness as a separate infringement, with its own amount, on top of anything else it fined.

The maximum fine for breaking Article 33 or 34 is set by Article 83(4): up to €10,000,000 or, for a business (an undertaking), up to 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. In Ireland, section 141(4) of the Data Protection Act 2018 caps a fine on a public authority or public body that does not act as an undertaking at €1,000,000.

In the Permanent TSB case, fraudsters who already held some customer details phoned its Open24 contact centre posing as customers and changed account details. In the first of three breaches, the affected customer rang on 8 April 2022 and again on 16 April. The fraud team acted, but the data protection team heard of it only through a monthly list of complaints on 6 May. It decided on 20 May that there had been a breach and notified on 26 May. The DPC counted that as 48 days after the bank first heard of the fraud. It held that the 72 hours ran from 16 April at the latest.

Two things in that decision apply to any organisation. The DPC counted from when the bank ought to have known, which was before its data protection team had been told. And a parallel investigation did not stop the clock: PTSB was 'not entitled to suspend its consideration' of whether a breach had occurred while 'a separate and lengthy fraud investigation' ran. The DPC said the more correct course was to tell it of the possible breach without undue delay and add the rest as it came to light, which Article 33(4) allows.

Fixing the problem first did not excuse the delay either. The DPC said Article 33(1) makes no allowance for an organisation that delays notifying because it considers it has since fixed the issues.

The University of Limerick notified 12 breaches between November 2018 and January 2020, six of them phishing attacks on staff mailboxes. The Health Service Executive (HSE) decision followed intruders getting into two disused hospitals where paper medical records were stored, with videos of the records posted on social media.

A bank, a university and the Health Service Executive. Article 33 has no exemption for size.

Article 33(5) requires you to record any personal data breach: the facts, its effects and the action taken to put it right. The record has to let the DPC check that you complied with Article 33.

Any breach. Not any notified breach. A minor incident correctly assessed as not notifiable still has to be written down, and the record is what shows the assessment happened.

The DPC's 2025 annual report gives two possible reasons for the fall in notifications: organisations improving their compliance, or organisations deciding that some breaches had not reached the threshold to report. It notes that Article 33(5) requires all breaches to be recorded, says it 'has commenced an initiative to examine organisations' compliance with this obligation', and says the initiative will give it insight into breaches both reported and not reported to it.

The DPC's breach notification page says that even where you decide there is no risk, you need an internal record of the details, the means for deciding there was no risk, who decided, and the risk rating recorded. The EDPB adds that a decision not to notify should be documented with the reasons the breach is unlikely to result in a risk. For a late notification, you must be able to give the reasons for the delay, and the EDPB says documenting them helps show the delay was justified.

A single log covers all of it: when and how you found out, what happened, what data, how many people, the effects, the remedial action, the risk assessment and its rating, and who decided and why. The EDPB says the log can sit inside your record of processing (the Article 30 record), provided the breach entries can be picked out and produced on request.

The Slane Credit Union decision below is told in full in what a website plugin cost an Irish credit union.

The DPC takes breach notifications through its Breach Notification Form on its website, and says all breach notifications must use it. It asks you not to put the personal information of the people affected in the notification.

What it asks for follows Article 33(3): the nature of the breach, including the categories and approximate number of people and records affected, the contact point for more information, the likely consequences, and the measures taken or proposed.

Article 33(3) asks for the approximate number of people and records. The form takes both as ranges, with an option for a number not yet known, so it expects an estimate.

If it is past 72 hours, say why: Article 33(1) requires the reasons, and the form has a field for them. If the notification is incomplete, the DPC asks for an updated notification with the rest as it becomes available, which is the phased notification Article 33(4) provides for.

Telecoms and internet providers notifying under S.I. No. 336 of 2011 use a separate form, and Regulation (EU) No 611/2013 gives them 24 hours from detection, where feasible, instead of 72. Those rules are for providers of public phone and internet services (publicly available electronic communications services). A business that buys phone lines and broadband is not one, and Article 33 is the rule that applies to it.

The European Commission's Digital Omnibus proposal of 19 November 2025, COM(2025) 837, would rewrite Article 33(1). Only a breach likely to result in a high risk would be notified, where feasible not later than 96 hours after awareness, through a single EU reporting point (a single entry point) that the same proposal would set up. It would leave Article 33(5) as it is, so every breach would still be recorded.

Even if it is adopted as proposed, notifications would keep going directly to the DPC until that reporting point exists. The proposal adds a paragraph saying so. It would also have the European Data Protection Board prepare a common notification template and a list of the circumstances in which a breach is likely to result in a high risk, which the Commission could then adopt.

It is a proposal. The European Parliament's procedure file showed it awaiting a committee decision when this article was checked on 15 October 2026. Until a text is adopted and in force, the 72 hours and the Article 33(1) test above are the law.

Everything above is faster if three things exist already.

First, a named person who decides on notification, with a deputy. Nothing in Article 33 pauses the 72 hours for a weekend or a public holiday, and the decision cannot wait for one person to be back. Second, your record of processing (the Article 30 record). It lists the categories of personal data you hold, why, who receives them and, where possible, how long you keep them. Add a note of where each set is stored. Article 30 does not ask for that, but it is what lets you see quickly what a breach has reached. Third, a contract with each supplier that handles data for you (a processor agreement), giving the time they have to tell you of a breach as a number of hours.

An organisation employing fewer than 250 people does not have to keep that record (Article 30(5)), unless its processing is likely to result in a risk, is not occasional, or includes special category or criminal offence data. The breach log has no such exemption (Article 33(5)): you need it whatever your size. What GDPR asks of a small Irish business covers the record in full.

For the commonest case, the EDPB lists measures that lower the chance of mail going to the wrong place: several recipients put in Bcc by default, an extra confirmation before sending to several people outside Bcc, a delay that lets a sent message be stopped, autocomplete switched off for email addresses, and a second person checking. The DPC's guidance adds keeping contact details accurate and reviewing correspondence before it issues.

There is one more: write the procedure down, and read it once before you need it, so the first reading does not happen inside the 72 hours. The EDPB says that, to help meet Articles 33 and 34, organisations and their suppliers are better off with a written notification procedure. It should set out how to contain, manage and recover the incident, assess the risk, and notify. The DPC's 2019 guide says organisations should develop their own internal policies and procedures for dealing with breaches. One worked example is the breach response plan FourWinds publishes.