Data breach notification: the disclosure playbook for UK suppliers

It is 02:00, an engineer has confirmed unauthorised access to a production database, and your biggest customer's data processing agreement says you must tell them within 24 hours. Data breach notification feels like one deadline at that moment. For a UK B2B supplier, it is several running at once.

This guide is for founders, CTOs and COOs of UK SaaS and managed service firms selling into financial services and insurance. It maps every notification clock you face, shows which one actually binds you, and sets out what to decide before an incident and what to say to customers during one.

What is data breach notification?

Data breach notification is the legal duty to report a personal data breach to the regulator, the people affected or your customer. Under UK GDPR, a controller reports a qualifying breach to the regulator within 72 hours of becoming aware, where feasible. A processor tells the controller without undue delay. For B2B suppliers, contracts usually set a faster clock.

The regulator is now the Information Commission, the body that replaced the Information Commissioner's Office (ICO). The current text of UK GDPR Article 33 names "the Commission" where it once named the Commissioner. For the wider law, see our guide to UK GDPR and EU GDPR.

Article 33 also sets the exception. A controller does not have to notify when the breach "is unlikely to result in a risk to the rights and freedoms of natural persons". It must still record every breach, its effects and the remedial action taken.

Are you a controller or a processor when a breach happens?

A UK SaaS firm is usually a processor for the customer data in its platform and a controller for its staff, sales and marketing data. The role decides the duty. A controller notifies the Information Commission within 72 hours. A processor's statutory duty is to notify the controller, its customer, without undue delay after becoming aware of the breach.

UK GDPR defines a processor as a body that "processes personal data on behalf of the controller". If your customers load their clients' or employees' data into your service and decide what happens to it, you are processing on their behalf.

That makes Article 33(2) your first statutory clock: "The processor shall notify the controller without undue delay after becoming aware of a personal data breach." Article 28 adds that your contract must commit you to help the controller meet its own breach duties.

The processor duty has no hour count, which is why your customers write one into the contract.

A breach of your own HR or CRM data is different. There you are the controller, so the 72-hour duty to the regulator and, for high-risk breaches, the duty to tell affected individuals under Article 34 are yours. Many incidents touch both kinds of data, so expect to hold both roles at once.

Which data breach notification clocks apply to a UK B2B supplier?

A UK B2B supplier faces two kinds of clock. Its own statutory duties come from UK GDPR, the NIS Regulations 2018 if it is an in-scope digital service provider, and soon the Cyber Security and Resilience Bill. Its regulated customers' clocks, under FCA rules, DORA and NIS2, reach it through contracts, and they are often the fastest.

Three of these deserve a closer look.

The NIS Regulations 2018 apply to a relevant digital service provider only when an incident has a "substantial impact" on its service. Micro and small enterprises are excluded. The test is the EU's 2003 SME definition, under which a small enterprise has fewer than 50 staff and annual turnover or balance sheet total of no more than €10 million, so check both before assuming the duty applies.

The Cyber Security and Resilience (Network and Information Systems) Bill is still a Bill. In late October 2026, Parliament's record listed it at report stage in the House of Lords. The government's incident reporting factsheet describes a 24-hour initial notice and a 72-hour full report. It then adds a new duty: once a relevant digital or managed service provider has made its full notification, it must identify the customers likely to have been adversely affected and notify them. The factsheet sets no deadline for that customer notice.

The NIS2 Directive reaches some UK firms directly. Article 26 says cloud computing and managed service providers that are not established in the EU but offer services there must designate a representative in a member state. Article 23 also expects in-scope entities to tell the recipients of their services, where appropriate, about significant incidents likely to affect those services.

Why does your contract set the real notification clock?

Your contract sets the real clock because your regulated customers carry deadlines they cannot meet without you. The FCA expects a regulated customer to report within 24 hours of deciding an incident meets a threshold. A DORA customer can have four hours. Their contracts with you are written to fit those windows, not UK GDPR's "without undue delay".

The regulators expect this cascade. DORA Article 30 requires contracts with ICT third-party providers to include the provider's duty to assist "when an ICT incident that is related to the ICT service provided to the financial entity occurs". For services supporting critical or important functions, the contract must also set the provider's notice periods and reporting obligations.

The FCA's policy statement PS26/2 brings its new reporting rules into force on 18 March 2027. Its finalised guidance FG26/3 asks firms to name the third party where an incident originated there.

Your customer's regulator never writes to you. Your customer's contract does.

We recommend building a notification register from your signed agreements: each customer, the clause, the trigger ("aware", "suspected" or "confirmed"), the deadline, the contact route and the content the clause requires. The shortest deadline on that register is the one your process must be built to meet.

How do you decide notification thresholds before an incident?

Decide thresholds in peacetime, because at 02:00 nobody can calmly debate whether an event counts. Agree four things in advance: the severity levels, the data categories that trigger notification, the service impact that matters to customers, and the named person who approves each notice. Then the incident team applies a rule instead of inventing one.

Each decision maps to a question a regulator or customer will ask:

1. Severity. Define levels in terms the clocks use: "aware", "substantial impact", "major" and "significant". Align the wording with your incident procedure under ISO 27001 Annex A 5.24, so one classification drives both response and notification.
2. Data. List the data categories that make a breach notifiable by default, such as customer personal data, credentials and special category data. Article 33's risk test still applies, but a default speeds the call.
3. Service impact. Set the outage length or degradation that triggers a customer notice even where no personal data is involved. A DORA or FCA customer may need to report an outage you would class as an availability problem.
4. Approver. Name who signs off each type of notice, with a deputy. A notice waiting for an absent approver misses its clock as surely as one nobody drafted.

Record each decision as it is made, with the time. Article 33(5) requires you to document breaches in a way that lets the Information Commission check your compliance, and your decision log is part of that record.

What should a customer breach notification contain?

A customer breach notification should say what happened, which data and time window are affected, what you have done to contain it, what the customer should do now, and when the next update will arrive. Written in plain language and sent on time, those five elements let your customer meet its own regulatory duties without chasing you.

UK GDPR Article 33(3) sets the minimum for a controller's report to the regulator, and it is a useful model for a customer notice too. It covers the nature of the breach, the categories and approximate numbers of people and records, a contact point, the likely consequences and the measures taken. Article 34 asks for "clear and plain language" when writing to individuals.

A customer notice should include:

• What happened. The type of incident and when you became aware of it, without speculation about who did it.
• Data and window. Which of the customer's data, systems or services are affected, and the period of exposure as far as you know it.
• Containment. What you have done so far to stop or limit the incident.
• Customer actions. Specific steps such as rotating API keys, resetting credentials or watching for named activity.
• Next update time. A date and time, not "in due course".

An update without a next-update time is a promise to go quiet.

Write for the customer's security team, not its lawyers. That team will paste your words into its own regulatory report, so precise times, systems and counts are more useful than reassurance.

How often should you update customers during an incident?

Update customers at the interval you promised in your last message, even when nothing has changed. A fixed cadence lets your customers plan their own reports and stops their teams from chasing you. UK GDPR allows information to be given in phases, so you never need to wait for the full picture before sending the first notice.

Article 33(4) says that where you cannot provide all the information at once, it "may be provided in phases without undue further delay". The FCA takes the same line: its guidance says firms "should not wait 24 hours to report" just because they have 24 hours.

Your customers' regulators work in phases too. The DORA technical standards require an intermediate report within 72 hours of the initial notice "even where the status or the handling of the incident have not changed". Your updates should land before your customers' own reporting points, so each report they file reflects your latest facts.

We recommend agreeing a default cadence for each severity level and stating it in the first notice. Close the incident with a final message saying the incident is resolved and when the post-incident report will follow.

What goes in the post-incident report?

A post-incident report explains the root cause, the full impact, what was fixed and what changes to stop a repeat. Your regulated customers need it inside their own final-report deadlines: one month under DORA and NIS2, and 30 working days after resolution for FCA enhanced reporters. Send yours early enough for them to use it.

NIS2 Article 23 gives a clear template for the final report: a detailed description of the incident, its severity and impact, the likely root cause, the mitigation applied and ongoing, and any cross-border impact. A customer-facing version should cover the same ground, minus anything that would expose other customers or create a fresh security risk.

The report also closes your own loop. The lessons belong in your improvement process under ISO 27001 Annex A 5.26 and Annex A 5.27, and the updated controls become evidence for your next security questionnaire.

Why is breach disclosure a trust asset for a B2B supplier?

Breach disclosure is a trust asset because an enterprise buyer can check it. A notice that arrives inside the contract clock, names the data and the window, and keeps to its stated cadence shows a working process. Late, vague or lawyer-written notices show the opposite, and the customer's security team can record what it saw.

That is why we treat trust as market access infrastructure. For a supplier selling into financial services, an incident is the moment a customer tests whether the notification commitments in your contract and questionnaire answers are real.

You do not control whether an incident happens. You control whether your disclosure matches what you promised.

What are the common data breach notification mistakes?

The common data breach notification mistakes are planning for one 72-hour clock, waiting for certainty before the first notice, and letting nobody own the decision to notify. Each one turns a manageable incident into a contract dispute. All three are fixed by decisions made before the incident, not during it.

• Planning for one clock. UK GDPR's 72 hours is the deadline most teams know, and for a supplier it is often not the one that binds. Your notification register shows the real one.
• Waiting for certainty. The law expects phased reporting. A short, accurate first notice that says what is still unknown beats a complete one sent late.
• No named approver. Notification stalls when legal, engineering and leadership each assume another team will sign off.
• Drafting from scratch. Templates for the regulator notice, the customer notice and the update should exist before you need them. Our incident response plan template includes a notification map you can adapt.

Frequently asked questions