---
title: "Data breach notification: the disclosure playbook for UK suppliers"
canonical: https://www.grcmana.io/blog/incident-disclosure-playbook
published: 2026-04-04
updated: 2026-10-22
authors: ["Harry West"]
---

# Data breach notification: the disclosure playbook for UK suppliers

## Key takeaways

Data breach notification for a UK B2B supplier is not one 72-hour clock. As a processor under UK GDPR you must tell your customer without undue delay, and your regulated customers' own deadlines, such as the FCA's expected 24-hour initial report from March 2027 and DORA's 4-hour notice, reach you through contracts. Map those clocks, decide thresholds before an incident, and send customers specific, timed updates they can use in their own reports.

- **Controller duty** — A controller notifies the Information Commission (formerly the ICO) within 72 hours of becoming aware of a breach, where feasible, unless it is unlikely to risk people's rights and freedoms.
- **Processor duty** — A processor must notify its customer, the controller, without undue delay after becoming aware of a personal data breach. UK GDPR sets no hour count, so contracts usually add one.
- **FCA initial report** — From 18 March 2027, FCA-regulated firms report operational incidents as soon as practicable, and the FCA expects the initial report within 24 hours of determining a threshold is met.
- **DORA initial notice** — EU financial entities send the initial notice within 4 hours of classifying an ICT incident as major, and no later than 24 hours after first becoming aware of it.

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](https://www.legislation.gov.uk/eur/2016/679/article/33) names "the Commission" where it once named the Commissioner. For the wider law, see our [guide to UK GDPR and EU GDPR](https://www.grcmana.io/vault/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](https://www.legislation.gov.uk/eur/2016/679/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](https://www.legislation.gov.uk/eur/2016/679/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.

| Regime | Who it applies to | Who you tell | Deadline | Source |
| --- | --- | --- | --- | --- |
| UK GDPR Art 33(1) | You, as controller | Information Commission (formerly the ICO) | Without undue delay and, where feasible, within 72 hours of becoming aware | UK legislation |
| UK GDPR Art 33(2) | You, as processor | Your customer (the controller) | Without undue delay | UK legislation |
| UK GDPR Art 34 | You, as controller, where the breach is likely to cause high risk | Affected individuals | Without undue delay | UK legislation |
| NIS Regulations 2018 reg 12 | Relevant digital service providers: online marketplaces, search engines and cloud computing services, excluding micro and small enterprises | Information Commission | Without undue delay and no later than 72 hours after first becoming aware | UK legislation |
| Cyber Security and Resilience Bill (before Parliament) | Relevant digital and managed service providers, and data centres | Regulator, with the NCSC informed at the same time; then affected customers | Initial notice within 24 hours, full report within 72 hours; customers after the full report | UK government factsheet |
| FCA PS26/2 and FG26/3 (SUP 15.18, from 18 March 2027) | Your customers with a Part 4A permission, and payment service providers | FCA | Initial report as soon as practicable, which the FCA expects within 24 hours of determining a threshold is met; enhanced reporters finalise within 30 working days of resolution | FCA |
| DORA Art 19 and RTS (EU) 2025/301 | Your EU financial-entity customers | Their competent authority | Initial notice within 4 hours of classifying an incident as major and no later than 24 hours from awareness; intermediate within 72 hours of that; final within one month of the last intermediate report | EUR-Lex |
| NIS2 Directive Art 23 | Essential and important entities in the EU, which can include your customers and, if you offer in-scope services there, you | CSIRT or competent authority | Early warning within 24 hours, notification within 72 hours, final report one month after the notification | EUR-Lex |

Three of these deserve a closer look.

The [NIS Regulations 2018](https://www.legislation.gov.uk/uksi/2018/506/regulation/12) 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](https://www.gov.uk/government/publications/cyber-security-and-resilience-network-and-information-systems-bill-factsheets/incident-reporting) 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](https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng) 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](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng) 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](https://www.fca.org.uk/publications/policy-statements/ps26-2-operational-incident-third-party-reporting) 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](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation), 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](https://eur-lex.europa.eu/eli/reg_del/2025/301/oj/eng) 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](https://www.grcmana.io/vault/iso-27001/annex-a-5-26-response-to-information-security-incidents) and [Annex A 5.27](https://www.grcmana.io/vault/iso-27001/annex-a-5-27-learning-from-information-security-incidents), 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](https://www.grcmana.io/vault/templates/incident-response-plan) includes a notification map you can adapt.

## Frequently asked questions

### How do you report a data breach to the ICO?

Use the [breach reporting service on the ICO website](https://ico.org.uk/for-organisations/report-a-breach/personal-data-breach/personal-data-breach-reporting/), which still carries the ICO name although the law now calls the regulator the Information Commission. Only a controller reports there. A processor reports to its customer, and a breach that is unlikely to put people's rights and freedoms at risk is recorded rather than reported.

### What happens if you miss the 72-hour deadline?

Article 33 still requires you to notify. A late notification must be accompanied by the reasons for the delay. Record when you became aware, when you decided and why it took longer, because those reasons become part of the record the regulator sees.

### Does a SaaS processor have to report a breach to the Information Commission itself?

Not under UK GDPR. As a processor, your duty is to notify your customer, the controller, without undue delay, and the controller decides whether to report. Two cases put you in front of the regulator yourself: data you control, such as your own staff records, and, if you are a relevant digital service provider under the NIS Regulations, an incident with a substantial impact on your service.

### Do weekends count towards the 72 hours?

UK GDPR Article 33 counts 72 hours from the moment you become aware and makes no exception for weekends or bank holidays. Plan your on-call cover and approvals on that basis. Some customers' regimes differ: DORA's technical standards let some financial entities submit by noon on the next working day.

### When will the Cyber Security and Resilience Bill's reporting duties start?

No start date is set yet. In late October 2026, the Bill was at report stage in the House of Lords. The government's factsheet says the incident reporting measures will be brought into force through secondary legislation after Royal Assent, so the start date depends on those regulations.