Data Breach Response Plan UK: Notifying the ICO and Individuals

A data breach response plan is the document that decides, before a crisis hits, who discovers, who decides, who notifies the ICO, who speaks to the customer, and how quickly each step happens. Without one, a company might discover an incident on a Friday evening and spend the legal deadline arguing over who is responsible. This guide shows you how to set up your plan, with realistic deadlines, defined roles, and a checklist for the first 72 hours.

TL;DR

• Under UK GDPR, organisations have 72 hours from becoming aware of an incident to notify the ICO and affected individuals where there is a risk to their rights and freedoms.
• After the initial notification, you are expected to provide further information promptly. All incidents, whether reported or not, should be recorded for a minimum of 5 years.
• The average cost of a data breach in Brazil reached R$ 7.19 million in 2025, according to IBM's Cost of a Data Breach report. While these figures reflect the Brazilian market, the financial impact of a data breach in the UK is similarly substantial, often running into millions of pounds, with regulatory fines being just one part of that cost.
• A data breach response plan can fit on a few pages: named roles, a 'notify or not notify' decision tree, ready-made communication templates, and an hourly checklist.

What a data breach response plan is (and isn't)

It's an operational roadmap, not your privacy policy or Data Protection Impact Assessment (DPIA). It answers five questions in writing that no one answers well under pressure:

1. Who can declare that an incident exists?
2. Who decides if it needs to be communicated to the ICO and affected individuals?
3. Who performs technical containment (changing passwords, isolating servers, revoking tokens)?
4. Who writes and signs off on communications?
5. Where is the evidence of everything done, and in what order?

The UK General Data Protection Regulation (UK GDPR, Article 33) obliges the controller to notify the supervisory authority and the data subject when an incident is likely to result in a risk to the rights and freedoms of natural persons. The 72-hour timeframe is a key requirement.

At Agathas Web, we manage Moodle servers, websites, APIs, and integrations with the official WhatsApp API for clients of various sizes. The pattern we observe is consistent: those with a three-page data breach response plan resolve incidents in hours, while those without take days. The difference is almost never technical; it's about decision-making.

If you're still in the phase of understanding how breaches occur, start with our guide on what a data breach is and how to prevent it. This post begins where prevention has failed.

UK GDPR deadlines, simplified

UK GDPR regulates the communication of security incidents. The key numbers for anyone designing a data breach response plan are:

What	Deadline	Counted from
Notify the ICO (incident with risk to rights and freedoms)	72 hours	Becoming aware that personal data has been affected
Notify affected individuals (high risk to rights and freedoms)	Without undue delay	Same trigger, but typically within the 72-hour window or as soon as possible thereafter
Supplement initial communication to the ICO	Promptly	Date of initial communication (20 working days is a good internal target)
Record keeping of incidents (including those not notified)	Minimum of 5 years (recommended)	Date of record

Three details that often trip up companies

The clock doesn't wait for the investigation to finish. It starts ticking as soon as the controller becomes aware that personal data has been affected. Investigating for a week before 'declaring' the incident only creates a delay that needs justification.

An initial communication is accepted, but not a complete solution. The ICO expects you to provide as much information as possible in your initial report, and then follow up promptly with more details as they become available. A partial report alone does not fulfil the full obligations of UK GDPR.

The channel is the ICO's online portal. The Data Protection Officer (DPO) or legal representative submits the report electronically. If no one in your company has access to the ICO's reporting system, create it now, not on the day of the incident.

When an incident needs to be communicated

The ICO considers several conditions: the incident has been confirmed, it involves personal data subject to UK GDPR, and it is likely to result in a risk to the rights and freedoms of individuals. Factors weighing towards 'high risk' include:

• Sensitive data (health, biometrics, religion) or data concerning children;
• Large scale, by the number of individuals and data points;
• Absence of encryption that renders the data unintelligible;
• Low effectiveness of mitigation measures already applied.

A decision matrix that fits on one page

Notifying everything out of fear creates noise. Not notifying for convenience is a breach. The middle ground is a simple matrix, which every data breach response plan should include, completed by the DPO and appended to the record.

Situation	Tendency	Why
Lost laptop with encrypted disk and strong password	Record, do not notify	Data unintelligible to third parties
Client spreadsheet with name and email sent to wrong recipient, who confirmed deletion	Record, assess	Low scale and proven containment
Moodle database with personal identifiers, grades, and accessibility reports copied by an intruder	Notify	Sensitive data, scale, and confirmed copy
WhatsApp API token exposed in a public repository, with accessible conversation history	Notify	Content of messages and client phone numbers
Ransomware with confirmed data exfiltration	Notify	Data copy plus risk of disclosure

This table provides a tendency, not a definitive legal opinion. What the matrix ensures is that the decision was made with criteria and can be explained later, and it is this audit trail that regulators look for.

For those operating an EAD environment, there are particularities: data of minors, medical reports for exam adaptations, and grades. We detail this in UK GDPR in Moodle: what institutions need to do in their VLE.

Who notifies whom: the roles map

The most common mistake is a plan that says "the company will notify the ICO". A person notifies. Your data breach response plan needs to have names, personal phone numbers, and a substitute for each role.

Role	Typical incumbent	Primary responsibility
Incident Coordinator	Director, senior manager, or IT Manager	Declares the incident, convenes the team, decides priorities
Data Protection Officer (DPO)	Internal or outsourced	Assesses relevant risk, drafts and submits communication to the ICO
Technical Lead	Sysadmin, hosting provider, responsible developer	Containment, evidence preservation, root cause analysis
Legal Counsel	Internal lawyer or law firm	Reviews communications, contracts with processors, exposure to legal action
Communications	Marketing or customer service	Drafts text for individuals, responses to customers and press
Processors	Hosting, SaaS, agency, software provider	Notifies the controller and provides logs and information

Controller and processor do not have the same duty

The entity that decides on the data (the controller, usually your company) is responsible for notifying the ICO and affected individuals. The processor (your hosting provider, CRM vendor, or the agency running your website) has a duty to notify the controller and cooperate. In practice, this means that your 72-hour deadline depends on the speed of your supplier.

Review your contracts: a clause requiring notification within 24 hours, with log delivery, can save your deadline. In the managed hosting contracts we operate, client notification is immediate, and logs are provided concurrently, because we know they are the ones who answer to the ICO.

Checklist for the first 72 hours

The 72 hours below are the heart of any data breach response plan and fit within the UK GDPR deadline in most scenarios. If the incident starts on a Friday, you gain the weekend to investigate, but don't count on this to delay the decision.

Hour 0 to 4: Confirm and contain

• Record the exact date and time when awareness of the incident occurred. This is the starting point for the deadline.
• Coordinator declares the incident and opens a dedicated, closed channel (e.g., a specific team chat, not the general company group).
• Technical lead preserves evidence before cleaning up: server snapshot, copy of access logs, database, and firewall logs.
• Contain: change exposed passwords and keys, revoke API tokens, block IPs, isolate the compromised machine.
• Notify involved processors (hosting, SaaS) and formally request logs in writing.

Hour 4 to 24: Assess impact

• Which categories of data were affected? Is there sensitive, financial, or children's data?
• How many individuals? An estimated figure with a methodology is more valuable than "we don't know".
• Was the data encrypted? Was the encryption key also compromised?
• Was the access read-only, or was there copying, alteration, or deletion?
• The DPO completes the risk matrix (see next section) and recommends: notify or record.

Hour 24 to 72: Decide and communicate

• Coordinator and legal counsel validate the decision. If notifying, the DPO submits the report via the ICO's online portal (preliminary if data is incomplete).
• Communication to affected individuals is sent via the usual channel (email, SMS, WhatsApp, student portal), in simple language.
• Customer service receives a script of responses and the DPO's contact information.
• Everything is entered into the incident log, including the decision not to notify and the reasoning.

After 72 hours

• Supplement the communication to the ICO promptly (within 20 working days is a good internal target).
• Root cause analysis report and list of corrective actions with responsible person and date.
• Lessons learned meeting and plan update.

What to tell the ICO and affected individuals

Communication to the ICO follows their official reporting form. Communication to the individual is yours to craft, and it defines the customer's reaction. Have both templates ready within your data breach response plan, reviewed by legal counsel.

Minimum content for individuals

According to ICO guidance, the text to the individual should include, in simple language: the nature and categories of data involved, the security measures that protected them, the risks, reasons for any delay, mitigation measures taken, the date you became aware, and the DPO's contact. It should be direct and individual whenever possible; a generic notice on the website or in the press is an exception and requires justification.

When NOT to send the notification yet

Do not send emails to thousands of people before knowing if the intruder is still inside your systems. If the transactional email account was compromised, your warning could become the attacker's phishing attempt. Contain first, communicate via a channel you control, and if this pushes the deadline, use a preliminary communication and document the reason.

Two classic text errors: minimising ("a small incident with no impact") before knowing the full extent, and asking the customer to click a link to "check if they were affected," which is exactly the pattern of a scam.

The cost of not having a plan

The IBM Cost of a Data Breach 2025 report estimated the average cost of a breach in Brazil at R$ 7.19 million, a 6.5% increase over 2024. Healthcare leads, with an average of R$ 11.43 million. Third-party compromise and supply chain attacks emerged as the most expensive vectors, averaging R$ 8.98 million. While this sample is of larger organisations than the average SME, the cost composition applies to all: forensics, legal fees, customer service, and lost clients.

UK GDPR fines can reach up to £17.5 million or 4% of annual global turnover, whichever is higher (Data Protection Act 2018, Schedule 16). Beyond fines, there are warnings, reprimands, and orders to erase or restrict processing of data. For many companies, publicising the infringement hurts more than the monetary penalty.

And incidents are routine. According to a survey based on ANPD panels (Brazil's data protection authority), the average was around 350 incident communications per year between 2023 and 2025, with ransomware and credential theft among the most frequent types. While these are Brazilian figures, the UK also sees a significant number of reported incidents to the ICO annually.

Without a plan, money is wasted on hastily contracted forensics, overly broad communications due to lack of assessment, and missed deadlines, which can turn a well-handled incident into a regulatory enforcement action.

Setting up and testing a data breach response plan costs a fraction of that. A well-scoped technology consultancy can deliver the plan, templates, and the first simulated exercise in a few weeks.

Technical pitfalls we see in practice

This is the part that a generic data breach response plan downloaded from the internet doesn't cover, because it depends on how your infrastructure truly works.

Logs no one keeps

A server with a 7-day log rotation and an incident discovered 20 days later: there's no way to prove what was accessed. Define minimum retention (90 days is a reasonable starting point for web access and database logs) and store them off the server that could be compromised. Without logs, no data breach response plan works.

Shared credentials

"The panel password is in the WhatsApp group" is the phrase we hear most often when taking over an environment. With five people using the same login, no one knows who did what. Individual accounts with two-factor authentication are a prerequisite, not a future improvement.

Forgotten API tokens

Integrations with the official WhatsApp API, payment gateways, and CRMs use long-lived tokens. A token in a public repository or an exposed .env file grants access to conversations and client data. List where each token lives and how to revoke it in minutes.

Backup that also leaked

Backup in the same cloud account, with the same credentials, will also be compromised. And an .sql dump forgotten in the public folder of the website is a breach waiting to happen.

For the human side of the problem, uncontrolled AI use has also become a data outflow channel. We address this in AI usage policy in the workplace.

How to build your data breach response plan in 4 steps

You don't need a 60-page document. You need a document that someone can open at 11 PM and follow.

1. Minimum inventory. Which systems process personal data, where they are hosted, who the provider is, where logs and backups are kept. A spreadsheet can suffice.
2. Roles and contacts. The roles table above, with name, substitute, personal phone number, and who has access to the ICO's online portal.
3. Procedures and templates. The 72-hour checklist, the decision matrix, the communication template for individuals, and the incident log template.
4. Test. A 2-hour tabletop exercise: someone describes a scenario, the team responds how they would handle it. The first time, a gap always appears, and it's better that it appears in a simulation.

When it's not worth overcomplicating

If your company has an institutional website without a form and no system with customer data, the data breach response plan might be a single page. Complexity should be proportional to risk. What doesn't exist is "I don't have personal data" for anyone serving customers via WhatsApp, issuing invoices, or maintaining an email list.

How Agathas Web solves this

Our technology consultancy builds your data breach response plan based on your company's actual infrastructure, not a generic template. We are a technical team: we examine servers, logs, backups, tokens, and supplier contracts, and deliver the plan along with the corrections that make the plan executable.

What's included:

• Infrastructure diagnosis: where personal data is located, who accesses it, log retention, backups, shared credentials, and exposed API tokens.
• Written plan with roles, contacts, 72-hour checklist, decision matrix, and communication templates for the ICO and affected individuals.
• Priority technical adjustments: off-server log retention, individual accounts with two-factor authentication, backup review, and scanning for exposed files.
• Tabletop exercise with your team and a report on areas for improvement.
• Support during a real incident, should it occur: containment, evidence preservation, and technical data for the DPO and legal counsel.

How it works: an initial diagnostic conversation, a proposal with a defined scope and timeline, and execution in short cycles. We do not replace your lawyer or your DPO. We deliver the technical part they need to meet deadlines, and we review the data breach response plan whenever the infrastructure changes. To engage us, contact us via the technology and security consultancy page.

Conclusion: the plan is for the worst day, write it on the best

72 hours seems like a long time until you need to figure out, in the middle of an incident, who has the server password, where the logs are, and who can sign the communication. A data breach response plan doesn't prevent an attack. It prevents the attack from also becoming an infringement, a missed deadline, and a disastrous communication.

Start with the basics of your data breach response plan this week: name the incident coordinator and DPO, ensure access to the ICO's online portal, and find out how many days your logs are retained. If you want help turning this into a tested plan, Agathas Web's consultancy performs the diagnosis and delivers a ready-to-use plan.