Data Breach Response for UK Businesses: The First 72 Hours

01

The first report rarely contains the whole story

Imagine it is 9.10 on Monday morning. A member of the support team reports that one customer may have been able to download records belonging to another account. Nobody yet knows how long the problem existed, how many records were involved or whether anyone else found it.

The weak response is to start drafting a reassuring customer email before the facts are clear. Another weak response is to wait for complete certainty before treating the incident seriously.

A useful response begins with two jobs running together. The business contains the immediate problem while building a reliable record of what happened, who may be affected and what decisions have been made. That record supports the technical investigation, the risk assessment and any later communication with the Information Commissioner's Office, customers, insurers or other regulators.

This article explains that operational response for a UK business. It is general information rather than legal advice. Organisations in regulated sectors, and businesses dealing with particularly sensitive data, should take appropriate legal and regulatory advice for the incident in front of them.

02

A cyber incident and a personal data breach are not the same thing

The language matters because the reporting duty under UK GDPR concerns personal data breaches, not every technical fault or suspicious login.

The ICO defines a personal data breach as a security failure that leads to personal data being accidentally or unlawfully destroyed, lost, changed, disclosed or accessed without authorisation. It can affect confidentiality, integrity or availability.

That definition includes more than hacking. An email sent to the wrong recipient, a stolen laptop, an accidentally deleted customer file, a public cloud folder with the wrong permissions and a ransomware incident that makes records unavailable can all become personal data breaches.

A cyber attack might be blocked before personal data is affected. Conversely, a personal data breach can result from an ordinary human mistake with no attacker involved. The first assessment should therefore ask what happened to the information, not only whether malware was found.

03

The first hour is about control, evidence and ownership

Give the incident an owner. That person does not need to solve every technical problem personally, but they do need to coordinate decisions, keep the timeline current and make sure important actions are not lost between IT, management, suppliers and customer service.

Start an incident log on a trusted system. Record when the business first became aware, who reported the issue, what was observed, which systems or records may be involved, every containment action and the reason for each decision. The 72 hour reporting period is linked to awareness of the breach, so the first confirmed facts and timestamps matter.

Containment must be proportionate. Disable a compromised account, remove an exposed file, isolate an affected service or revoke a leaked token where that will stop further loss. Avoid wiping machines, deleting logs or making broad changes that destroy evidence before somebody competent has captured what the investigation needs.

04

Build enough of the picture to assess the risk to people

The ICO reporting test is about the likely risk to people's rights and freedoms. It is not simply a count of rows in a database.

Identify the categories of personal data involved, the approximate number of people and records, whether the data was encrypted, who could access it, how long it was exposed and whether there is evidence of copying or misuse. Consider what the information could reveal when combined with data already available elsewhere.

Names and business email addresses normally carry a different risk from medical information, identity documents, financial details, passwords or information about vulnerable people. Scale still matters, but sensitivity, context and the realistic consequences matter too.

• What personal data was affected, including any special category or financial information?
• How many people and records are likely to be involved?
• Was the information viewed, copied, changed, deleted or made unavailable?
• Who had access and can that access be verified from reliable logs?
• What harm could realistically follow, and how likely is it?
• What has already reduced the risk, such as encryption, rapid deletion or credential resets?

Return to the customer portal example. If the file contained only a small set of ordinary contact details and the unintended recipient confirms secure deletion, the risk assessment may be different from a download containing bank details and identity documents that was publicly accessible for several days. Document the reasoning either way.

05

The 72 hours are a deadline, not a waiting period

Where a personal data breach is likely to risk people's rights and freedoms, the organisation must notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. If the risk is unlikely, the breach does not normally need to be reported, but the decision and its reasoning still need to be recorded.

A business does not need every forensic answer before making an initial report. UK GDPR allows information to be provided in phases. The ICO expects the investigation to be prioritised and the remaining details to follow without undue further delay.

The notification should cover the nature of the breach, the categories and approximate numbers of people and records, a suitable contact, the likely consequences and the measures taken or proposed. Treat the 72 hours as the outer limit for a justified decision, not as time to leave the incident in somebody's inbox.

If the breach is likely to create a high risk to individuals, those people must also be informed without undue delay. That is a higher threshold than the test for notifying the ICO. The purpose is to give people clear information and useful steps they can take to protect themselves.

06

One incident can create several reporting routes

Reporting a significant cyber incident to the National Cyber Security Centre does not replace a separate duty to tell the ICO or another regulator. Depending on the incident, a UK business may also need to contact the police, its insurer, its payment provider, a professional regulator, the Financial Conduct Authority, customers acting as data controllers or other organisations named in contracts.

Check these routes early. Cyber insurance policies can contain notification and supplier approval conditions. Contracts may require a processor to tell the controller without undue delay. Payment card incidents can involve an acquiring bank and card security obligations. The right list depends on the business and the information involved.

The NCSC advises using a separate system to submit a report if the normal network may be compromised. That small operational detail is easy to miss when the team is moving quickly.

07

Communicate facts that help rather than speculation that spreads

Choose one owner for external updates and give customer-facing staff a clear route for questions. People should not receive three different explanations from support, sales and a director posting on social media.

A useful notification explains what is known, the types of information involved, the likely consequences, what the organisation has done and what the recipient can do now. It also gives a real contact point and explains where later updates will appear.

Do not minimise the issue with vague language, but do not present an early theory as a confirmed fact. Avoid publishing technical detail that could increase the risk or interfere with an investigation. Plain, honest communication gives affected people more value than polished reassurance with no useful action attached.

08

Recovery is not simply switching the old system back on

Containment stops the immediate loss. Recovery deals with the cause and proves the service can return safely.

That may mean rebuilding from a known clean state, patching the original vulnerability, rotating passwords and access tokens, checking supplier access, restoring tested backups and increasing monitoring around the affected area. The exact sequence depends on the incident, but speed should not replace evidence.

Define what must be true before normal operation resumes. Confirm that the vulnerable route is fixed, expected permissions have been restored, logs are arriving, key business journeys work and somebody is watching for recurrence. A rushed return that recreates the same exposure turns one incident into two.

09

The useful work continues after the incident closes

The final review should produce changes, not only a document. Look at why the incident was possible, why it was or was not detected quickly, whether the right people knew what to do and where the investigation lacked reliable evidence.

The improvement might be smaller than a security transformation programme. It could be removing unused accounts, shortening data retention, adding an alert for unusual exports, clarifying supplier responsibilities, testing backups or giving every employee one obvious way to report a suspected breach.

For the imagined portal incident, the strongest outcome is not a claim that the business will never experience another problem. It is a safer portal, a tested response process and a team that can make the next difficult decision from evidence rather than panic.

Prepare the response sheet before it is needed. Name the incident lead and deputy, list the trusted communication route, record supplier and insurer contacts, link the ICO assessment and reporting pages, and define where the incident log will live. When 9.10 on Monday arrives, that one page can save the first hour from being spent deciding who should start.