Guide

Data Breach Notification Requirements: Who to Tell and When

Who a small business may need to notify after a data breach and how quickly: regulators, affected individuals, insurers, and customers. What the common timelines are, and how to decide before an incident forces it.

By SecureBusinessHub Editorial, International cybersecurity desk — · 7 min read

Data breach notification requirements are the rules that decide who you have to tell after a security incident exposes personal data, and how quickly. They are the part of a breach that catches small businesses out, because the clock usually starts before anyone has a clear picture of what happened, and more than one clock can be running at once. This guide sets out who the potential audiences are, what the common timelines look like, and the decisions worth making in advance rather than at nine in the morning during an outage.

The specific rules depend on where you operate, which sector you are in, and what your contracts say, so treat what follows as a map of the terrain rather than an answer for your business; a qualified adviser in your jurisdiction is the right source for that. For the wider picture of which regimes reach a smaller business at all, see our guide to NIS2 requirements and GDPR for small business.

There is more than one audience

People tend to hear "notification" and picture a regulator. In practice a single incident can create obligations to several different audiences, on different timescales, and some of those obligations come from a contract rather than a law. Listing them out in advance is most of the work.

  • The data protection regulator or supervisory authority, where personal data was involved and the incident meets the reporting threshold.
  • The individuals whose data was exposed, where the risk to them is high enough.
  • Your cyber insurer, usually within a window set by the policy itself, and often as a condition of cover.
  • Business customers and partners, where a contract or a data processing agreement obliges you to tell them, frequently on a tighter deadline than the law sets.
  • A sector regulator, if you operate somewhere with its own rules, and a national cybersecurity authority if you are covered by a law such as NIS2.
  • Law enforcement, for extortion, fraud or theft, which is separate from any regulatory duty.

The seventy-two hour rule, and what starts the clock

Across the European Economic Area and the UK, data protection law sets the reference timeline most people know: a personal data breach is reported to the supervisory authority without undue delay and, where feasible, no later than seventy-two hours after the organisation becomes aware of it. If the report takes longer, the delay has to be explained. The equivalent obligation to notify affected individuals applies where the breach is likely to result in a high risk to their rights and freedoms, and there it is "without undue delay" with no fixed hour count.

The phrase doing the most work is "becoming aware." It does not mean the moment you have a complete forensic picture, which for most incidents is days away. It means the point at which you have a reasonable degree of certainty that a security incident has occurred and personal data was involved. A short period of investigation to establish that is generally accepted; using the investigation as a reason to sit on a report for a week generally is not. Regulators also allow a phased report, where you notify what you know inside the window and supply the rest as you learn it.

The other thing worth knowing is that the obligation to write it down is broader than the obligation to report it. Data protection law expects an organisation to document every personal data breach, including the ones judged not to meet the reporting threshold, along with the reasoning for that judgement. An internal breach log is cheap to keep and is exactly what a regulator asks for if they ever come looking.

Not every incident is reportable

A reporting threshold exists for a reason. Under the European model, a personal data breach does not need to go to the supervisory authority where it is unlikely to result in a risk to people's rights and freedoms, and individuals do not need to be told unless the risk to them is high. A laptop lost with full-disk encryption and no evidence of access sits very differently from a database of customer records copied by an intruder. Effective encryption, and measures taken afterwards that remove the risk, are both explicitly relevant to that judgement.

Make the assessment deliberately and record it. The failure mode small businesses fall into is not usually over-reporting; it is deciding informally that something was probably fine, writing nothing down, and having no account of the reasoning if the same data surfaces somewhere unpleasant six months later.

The clocks that run in parallel

Where a business is covered by more than one regime, the deadlines do not line up, and this is where an unprepared response falls apart. An organisation inside the scope of the NIS2 directive sends an early warning to its national authority within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within a month, which is a separate obligation to a separate body from the data protection report. In the United States there is no single national breach notification law; obligations come from state laws, which vary in trigger and timing, and from sector rules in areas such as health and financial services. Contracts add their own: a business customer's data processing agreement may require notice within twenty-four hours regardless of what any regulator asks.

If you are a processor rather than a controller, meaning you handle personal data on someone else's behalf, your primary duty is usually to tell that customer without undue delay and let them make the regulatory report. Knowing which role you are in, for each data set you hold, is a five-minute exercise on a calm day and an unwelcome surprise during an incident.

What a notification actually contains

Notifications are shorter and more factual than people expect, and knowing the shape in advance removes most of the panic from writing one. The regulator wants a description of what happened, not a defence.

  • What happened, in plain terms, and when you became aware of it.
  • The categories of personal data involved, and an approximate number of people and records affected.
  • The likely consequences for those people.
  • What you have done to contain it and what you are doing to limit the harm.
  • A named contact point for follow-up questions.
  • For notices to individuals: the same in plain language, plus what they should do, such as changing a password or watching for fraudulent contact.

Notices to affected individuals are a communications exercise as much as a legal one. Say what happened, what data of theirs was involved, what you are doing, and what they should do. Avoid the passive-voice house style that tells someone their trust is valued but never quite says their address was published.

Decide it before you need it

Everything above is easier if it is written down in advance, and it belongs in the same document as the rest of your incident process rather than in a separate compliance file nobody opens. Our incident response plan template walks through that document; the notification section of it should name who decides whether a report is required, which authority receives it and how, what your insurer's window is and the number to call, and which customer contracts carry their own notice clauses. None of that is knowable quickly under pressure, and all of it is knowable on a quiet Tuesday.

It is also worth checking what your cyber insurance policy says before you need to rely on it, because prompt notification to the insurer is a common condition, and a late call can complicate a claim that would otherwise have been straightforward. Our guide to why cyber insurance claims get denied covers the conditions that most often cause problems.

A worked example

A sixteen-person online retailer discovers on a Thursday afternoon that a support mailbox has been accessed by someone who should not have had it, after an employee fell for a credential phishing page two days earlier. The mailbox contains order correspondence: names, addresses, phone numbers and partial order histories for several hundred customers. The owner treats Thursday afternoon as the point of becoming aware, because that is when it was reasonably clear that personal data was involved, and starts the seventy-two hour clock from there rather than from the phishing email.

By Friday the account is locked, passwords are reset, multi-factor authentication is turned on across the mailbox platform, and the log review has established roughly which messages were opened. The report goes to the supervisory authority on Friday afternoon with what is known and a note that the review is continuing. Affected customers are emailed on Monday with a plain description of what was exposed and a warning to be wary of anyone contacting them about a recent order, because the exposed data makes a convincing follow-up scam realistic. The insurer was called on Thursday, inside the policy's twenty-four hour window. None of those steps required a decision to be invented on the day; they were in the plan.

Where this fits

Notification is the obligation that follows a breach; the transparency you owe people before anything goes wrong is a different document, covered in our guide to what a small business privacy policy should include. The wider regime picture is in NIS2 requirements and GDPR for small business, and the mechanics of responding at all are in our incident response plan template. If you would rather adapt a structured document than build the notification section from a blank page, our editable policy template pack includes an incident response playbook with a notification section written for small businesses.

NIS2 requirements: the second regime to know about

Data protection law is not the only European regime a business gets asked about. The NIS2 directive sets baseline cybersecurity and incident-reporting obligations for organisations in a defined list of sectors, and it is the source of most of the security questions that now arrive attached to contracts. The two regimes cover different ground: data protection law governs personal data and what people can ask you to do with it, while the NIS2 requirements govern the security and resilience of network and information systems, whether or not personal data is involved. A single incident can engage both, on separate clocks, to separate authorities.

The directive applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet above ten million euros. That size rule puts most small businesses outside its direct scope, and the honest answer for a ten-person company is usually that the directive does not regulate it. What the size rule does not do is keep the requirements away, because one of them is supply chain security: organisations inside scope are expected to consider the security practices of their direct suppliers, and the way that expectation shows up in the world is as a questionnaire in your inbox.

The measures the directive names are a reasonable checklist for any business, which is why they are worth knowing even when they do not apply to you directly. They cover risk analysis and written security policies, incident handling, business continuity and backups, supply chain security, secure development and vulnerability handling, basic cyber hygiene and training including for management, encryption and access control policies, and multi-factor authentication. Reporting is staged and fast for the organisations it covers: an early warning within twenty-four hours of becoming aware of a significant incident, a fuller notification within seventy-two hours, and a final report within one month.

Because the directive is national law in each member state rather than a single rulebook, the details of scope, thresholds and reporting differ by country. For a fuller explanation of the instrument itself, see our guide to what the NIS2 directive is, and for the supplier side of the supply chain obligation, our walkthrough of vendor risk assessment. The reporting clocks that run alongside data protection deadlines are covered in data breach notification requirements.

Frequently asked questions

Does NIS2 apply to a small business?

NIS2 generally applies to organisations in its listed sectors that are at least medium-sized, meaning broadly fifty or more employees or turnover and balance sheet total above ten million euros. Most smaller businesses fall outside its direct scope, unless a member state has specifically designated them or they sit in one of the size-independent categories such as DNS service providers or trust service providers. Being outside scope does not stop the directive reaching you through customers who are inside it.

What is the difference between GDPR and NIS2?

GDPR governs personal data: what you may collect, why you may hold it, and what rights people have over it. NIS2 governs the security and resilience of network and information systems in specific sectors, whether or not personal data is involved. One incident can engage both regimes at once, on separate reporting clocks and to separate authorities.

How long do you have to report a data breach?

Under the European model, a personal data breach is reported to the supervisory authority without undue delay and, where feasible, within seventy-two hours of becoming aware of it, and affected individuals are told without undue delay where the risk to them is high. Organisations in scope of NIS2 carry a separate obligation: an early warning within twenty-four hours, a fuller notification within seventy-two hours, and a final report within one month.

Does a small business need a data protection officer?

Under GDPR a data protection officer is required where the organisation is a public authority, where its core activities involve regular and systematic monitoring of people on a large scale, or where its core activities involve large-scale processing of special category or criminal offence data. Most small businesses meet none of those tests and are not required to appoint one, though naming someone internally as the contact for privacy questions is worth doing regardless.

What should a small business do when a client's security questionnaire asks about NIS2?

Answer what you actually do rather than what you think the client wants to hear. The questions usually cover written security policies, incident handling and how fast you would notify them, multi-factor authentication, access control when staff join and leave, backup and recovery arrangements, and which of your own subprocessors touch their data. Gaps are common, and disclosing one with a date for closing it lands far better than an answer that does not survive the follow-up question.

Do these rules reach a business based outside the EU?

They can. GDPR reaches organisations outside the EU that offer goods or services to people in the EU or monitor their behaviour, and other regions have their own regimes with their own triggers. NIS2 obligations follow the sectors and the member states that transpose it, but its supply chain expectations travel through contracts, which is how they reach suppliers anywhere in the world.

Related reading