Duty
to Act

Most people picture a hacker. The law pictures something far broader, and that gap is where organisations get caught out.

The starting definition sits in Article 4 of the UK GDPR. It is deliberately wide, and it does not mention attackers at all.

Read it again slowly. Accidental is in there. Destruction and loss are in there — you do not need anyone to have read the data. And it is a breach of security, not a breach of a firewall.

The three kinds

The ICO groups breaches into three types, and it is useful to name them because people routinely miss the second and third:

An availability breach is the one that surprises people. If ransomware locks your systems and the attacker never exfiltrates a single record, you have still suffered a personal data breach, because the people whose data it is have lost the benefit of it and you have lost control of it.

Incident, breach, near miss

These three words are not interchangeable, and using them loosely in an incident log will cost you later:

• Security incident — anything that threatens the confidentiality, integrity or availability of your systems or information. A phishing email that nobody clicked is an incident.
• Personal data breach — an incident that meets the Article 4(12) definition. This is the one that starts a statutory clock.
• Near miss — an incident that could have become a breach but did not. Not notifiable, but it belongs in your log, because a pattern of near misses is exactly the evidence a regulator uses to show you knew about a weakness.

One incident can trigger three or four separate reporting duties to three or four separate regulators, on different clocks. Knowing which apply to you is a job to do before anything happens, not during.

The core: everyone holding personal data

Two instruments do the heavy lifting for every UK organisation. The UK GDPR — Regulation (EU) 2016/679 as retained and amended in UK law — sets the principles, the security duty and the reporting duties. The Data Protection Act 2018 supplies the UK-specific machinery: exemptions, the ICO's enforcement powers, criminal offences, and a separate regime in Part 3 for law enforcement processing.

The security principle sits at the top of the UK GDPR and everything in Module 03 flows from it:

Article 5(2) then adds the accountability principle: the controller is responsible for compliance and must be able to demonstrate it. That second half is the one that decides enforcement outcomes.

The sector and service layers

The PECR change catches people out. Section 111 of the Data (Use and Access) Act 2025 replaced the old 24-hour telecoms clock with 72 hours, in force from 20 August 2025. Any internal policy or supplier contract still citing 24 hours under PECR is out of date. Note that regulation 5A still has no risk threshold — unlike the UK GDPR, every personal data breach connected with the service is notifiable, and regulation 5C sets a fixed monetary penalty of £1,000 for failing to notify.

The criminal layer

Two statutes matter here, and they point in opposite directions — one at the attacker, one potentially at you.

Sections 2 and 3 escalate this to unauthorised access with intent to commit further offences, and unauthorised acts intended to impair the operation of a computer. Section 3ZA covers unauthorised acts causing, or creating a risk of, serious damage. This is the law under which UK attackers are prosecuted — and in July 2026 two men were sentenced to five years six months for the September 2024 attack on Transport for London, which disrupted Live Tube arrivals and Oyster photocard applications and exposed personal data for around 5,000 customers including bank details.

Pointing the other way, the Data Protection Act 2018 creates offences that can catch your own staff, and your organisation's conduct during an investigation:

This is the provision behind prosecutions of employees who look up records they have no business reason to see — a recurring issue in local authority social care and in policing. Separately, section 148 makes it an offence to destroy, dispose of, conceal, block or falsify information or documents that the Commissioner has required, with intent to prevent the ICO from seeing them. Nobody should be tidying up logs after an incident.

What is coming, and is not law yet

The Cyber Security and Resilience Bill is the most significant reform of UK cyber regulation since the NIS Regulations 2018. It amends rather than replaces them, pulls managed service providers and data centres into scope, and introduces a tighter two-stage reporting regime with a 24-hour initial notification alongside turnover-linked penalties.

Where it stands: introduced to the Commons on 12 November 2025, second reading 6 January 2026, all Commons stages completed 16 June 2026, introduced to the Lords on 17 June 2026, Lords second reading 14 July 2026, Committee stage from 1 September 2026. Royal Assent is expected in late 2026, with obligations phased in through secondary legislation potentially running to 2028.

Every flagship UK data protection fine from 2024 to 2026 has been an Article 32 security case, not a privacy-policy case. This is the provision that decides whether a breach becomes a penalty.

Reading it properly

Four things in that text do real work, and each is regularly misread:

• "appropriate … to the risk" — this is not a checklist. There is no fixed list of controls that makes you compliant. The standard is proportionate to the risk your processing creates for people. A council holding social care records is held to a different standard than a shop holding a mailing list, on identical budgets.
• "the controller and the processor" — the duty falls on both. Your supplier is not off the hook because you are the controller, and you are not off the hook because your supplier holds the data.
• "the costs of implementation" — cost is a permitted consideration. It is not a permitted excuse. Regulators consistently find against organisations that priced a control and then never bought it.
• Paragraph (d) — the meta-measure. It is not enough to have controls; you must have a process for regularly testing, assessing and evaluating whether they work. An untested backup is not a restore capability.

Article 32(2) then tells you what to weigh when deciding what is appropriate:

Article 32(4) closes a gap people forget: the controller and processor must take steps to ensure that anyone acting under their authority who has access to personal data does not process it except on instructions. That is the insider-access limb — access control, need-to-know, and audit trails on staff activity, not just perimeter security.

What non-compliance costs

Article 83 sets two tiers. Infringements of Articles 25 to 39 — which includes Article 32 and Article 33 — sit in the lower tier: up to £8.7 million or 2% of total worldwide annual turnover, whichever is higher. Infringements of the basic principles in Article 5, which includes the security principle at 5(1)(f), sit in the higher tier: up to £17.5 million or 4%.

In practice the ICO's largest security penalty to date is £14 million against Capita plc and Capita Pension Solutions, issued 15 October 2025 and reduced from a proposed £45 million through a settlement in which Capita waived its right to appeal. The root cause the ICO identified was narrow and instructive: a 58-hour delay in quarantining an infected device after a high-priority security alert had been raised within ten minutes. Personal data belonging to 6.6 million people was exposed.

Seventy-two hours is the number everyone knows. Almost nobody can say when it starts, what it is a deadline for, or what happens if you miss it.

Four things that sentence actually says

• "without undue delay and" — 72 hours is a backstop, not an allowance. If you could reasonably have reported on day one, reporting on day three is still undue delay.
• "after having become aware of it" — the clock starts at awareness, not at the incident. The ICO treats awareness as the point at which you have a reasonable degree of certainty that a security incident has occurred and compromised personal data. Not the point at which you have every detail.
• "unless … unlikely to result in a risk" — this is the threshold. Note the double negative: the test is not "is there a risk?" but "is a risk unlikely?" If you cannot say it is unlikely, you report.
• "accompanied by reasons for the delay" — late reporting is provided for. It is not forgiven, but a late report with reasons is far better than no report.

The 72 hours run on calendar time, including weekends and bank holidays. A breach discovered at 4pm on the Friday before a bank holiday expires on the Monday.

What must be in the report

Article 33(3) sets the minimum content, and it is worth knowing because it shapes what your incident log needs to capture from hour zero:

You are not expected to have finished investigating. Article 33(4) permits phased reporting: where it is not possible to provide the information at the same time, it may be provided in phases without undue further delay. The ICO's own guidance is explicit that it expects controllers to prioritise the investigation, resource it adequately and expedite it urgently — and to explain the delay and say when more will follow.

The duty that applies even when you don't report

Any personal data breach. Not the notifiable ones — all of them. If you assess a breach as not notifiable, the reasoning behind that decision is exactly what the last sentence exists to let the Commissioner check. A breach register with no entries is not evidence of a clean record; to a regulator it reads as evidence that nothing is being detected or assessed.

If you are a processor

Article 33(2) is one sentence: the processor must notify the controller without undue delay after becoming aware of a personal data breach. There is no 72-hour figure attached to the processor — the reporting duty to the ICO stays with the controller. Which means your Article 28 contract has to set the processor's timescale, because the statute does not.

Parallel clocks

• NIS Regulations 2018, reg. 11 — operators of essential services notify their designated competent authority without undue delay and in any event no later than 72 hours after becoming aware of an incident with a significant impact on continuity of the essential service. Relevant digital service providers report to the ICO under reg. 12.
• PECR reg. 5A — 72 hours since 20 August 2025, no risk threshold, and the ICO states that PECR reporting takes the place of the UK GDPR reporting process for those providers.
• Communications Act 2003, s.105K — security compromise reports to Ofcom for public electronic communications networks and services.
• NCSC — reporting a significant cyber incident is not a statutory duty for most organisations, but it brings support and is expected of critical national infrastructure. In the year to May 2026 the NCSC managed more than 200 incidents affecting UK CNI and its supply ecosystem, around 75% linked to hostile state actors.

Notifying the regulator and notifying individuals are two separate decisions, on two different thresholds. Organisations routinely confuse them in both directions.

Two thresholds, not one

So there is a middle band: breaches you must report to the ICO but need not communicate to individuals. That band is large, and treating every reportable breach as requiring mass notification causes real harm — it exhausts people's attention and dilutes the warnings that matter.

What the message must contain

Article 34(2) requires the communication to describe, in clear and plain language, the nature of the personal data breach, and to provide at least the information listed in points (b), (c) and (d) of Article 33(3) — the contact point, the likely consequences, and the measures taken or proposed, including measures to mitigate adverse effects.

"Clear and plain language" is a legal requirement, not a communications preference. A notification written to minimise reputational damage rather than to help people protect themselves does not satisfy Article 34.

When you don't have to tell individuals

Article 34(3) sets out three exceptions. Communication is not required if:

• You had implemented appropriate technical and organisational protection measures and applied them to the affected data — in particular measures that render the data unintelligible to anyone not authorised to access it, such as encryption;
• You have taken subsequent measures which ensure the high risk is no longer likely to materialise;
• It would involve disproportionate effort — in which case there must instead be a public communication or similar measure by which the data subjects are informed in an equally effective manner.

Note the shape of the first exception. Encryption does not stop a breach being a breach, and it does not remove the Article 33 duty to consider reporting to the ICO. What it can do is remove the Article 34 duty to tell individuals, because the data is unintelligible to whoever now holds it. That is one of the strongest practical arguments for encrypting data at rest.

Article 34(4) adds a backstop: if you have not communicated the breach to individuals, the Commissioner may require you to do so, or may decide that one of the exceptions applies. The decision is not finally yours.

Across UK incidents in 2026, the single most common entry point was not the breached organisation's own systems. It was somebody they had contracted with.

This does not divide the duty. It multiplies it. Article 32 binds controller and processor alike, and Article 24 puts the burden of proof on you:

"To be able to demonstrate" is the operative phrase. You cannot demonstrate a supplier's security by having once received a completed questionnaire.

What Article 28 requires in the contract

Article 28(1) sets the selection duty: a controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. Article 28(3) then requires a written contract that, among other things, binds the processor to:

• process only on documented instructions from the controller;
• ensure persons authorised to process the data are under an appropriate duty of confidentiality;
• take all measures required by Article 32;
• not engage a sub-processor without prior specific or general written authorisation;
• assist the controller in ensuring compliance with Articles 32 to 36 — which expressly includes breach notification;
• make available all information necessary to demonstrate compliance, and allow for and contribute to audits, including inspections.

The audit right is the one most often written in and never exercised. An unexercised audit right is not evidence of oversight.

The gap the statute leaves you to close

Article 33(2) requires the processor to notify the controller "without undue delay" — with no hours attached. Your 72-hour clock, meanwhile, generally runs from when you become aware. So the practical exposure is the space between your supplier knowing and you knowing. The statute does not close that gap. Your Article 28 contract has to, with a specific figure — 24 hours is common — and a named contact who is reachable outside office hours.

Five questions to ask before you sign

1. How quickly, in hours, will you notify us of a personal data breach affecting our data — and who makes that call at your end, out of hours?
2. Who are your sub-processors, and how will we be told when that list changes?
3. When were your restore procedures last tested end to end, and can we see the result?
4. What would you actually give us within 24 hours of an incident, so we can meet our own Article 33(3) duty?
5. Will you accept an audit or inspection, and when was the last one you underwent?

The regulator does not assess you on the day of the breach. It assesses the years before it. Nearly everything that determines the outcome is decided while nothing is happening.

What the ICO actually looks for

Read across the enforcement record and a consistent pattern emerges. In every major UK security case, the finding was not that the organisation lacked a security team or a budget. It was one of four things:

None of those is a sophisticated attack. All four are visible from inside the organisation, in advance, for free.

Five things to be able to produce on demand

1. A breach register with entries in it — Article 33(5) requires documentation of any personal data breach, including the ones you decided not to report and why. The ICO publishes a log template; use it or something better.
2. An incident response plan that names people, not roles — with out-of-hours contacts for your DPO or equivalent, your processors, your insurers and your regulator, and with the first action being preserve evidence and start the clock.
3. Evidence that you test — Article 32(1)(d) requires a process for regularly testing, assessing and evaluating effectiveness. Restore tests with dates and outcomes. Tabletop exercises with a written debrief.
4. A current record of processing and suppliers — you cannot notify within 72 hours if it takes two days to establish whose data was in the affected system.
5. A decision trail on risk — where you accepted a risk, the note saying who accepted it, on what basis, and when it is due for review. An accepted risk with a name against it is a defensible position; an unaccepted risk that nobody looked at is not.

Frameworks worth mapping to

• Cyber Essentials — the government's baseline, five controls. Not a statutory requirement for most organisations, but it is the floor that suppliers are increasingly asked to certify against, and it is a reasonable answer to "what did you do?"
• NCSC Cyber Assessment Framework (CAF) — the outcome-based framework used across critical national infrastructure and now in local government assurance. The Cyber Security and Resilience Bill is expected to put the CAF on a statutory footing for in-scope organisations.
• ISO/IEC 27001 — a management system rather than a control list. Article 32(3) expressly notes that adherence to an approved code of conduct or certification mechanism may be used as an element to demonstrate compliance. Note the wording: an element. Certification is evidence, not a defence.

Where this is heading

Three changes are already fixed or close to it. The Data (Use and Access) Act 2025 is being commenced in stages: document-notice powers commenced two months after Royal Assent, while specified data-protection and PECR enforcement provisions commenced on 5 February 2026. The ICO applied a 40% settlement reduction in the South Staffordshire case; its draft enforcement procedural guidance proposes tiered discounts of 40%, 30% and 20% depending on when a case settles. And the Cyber Security and Resilience Bill, expected to receive Royal Assent in late 2026, brings a 24-hour initial notification duty for in-scope organisations, phased in through secondary legislation to around 2028.

The through-line across all three is the same: less tolerance for delay, more weight on evidence, and a shorter gap between knowing and acting.

1. A breach is wider than a hack. Article 4(12) covers accidental destruction, loss and alteration, not just unauthorised access. Ransomware with no exfiltration is still a breach.
2. The clock starts at awareness — reasonable certainty that a security incident has occurred and compromised personal data — and runs on calendar time. Seventy-two hours is a backstop, not an allowance.
3. Report on time and incomplete, rather than late and complete. Article 33(4) exists for exactly this.
4. Document everything, including what you decided not to report. Article 33(5) applies to any breach, and your reasoning is what the Commissioner will ask to see.
5. Article 32 is judged on the years before the breach. Known risks, paper controls, detection without response, and unowned legacy systems are what enforcement actually turns on.

Legislation cited in this course

• UK GDPR — Articles 4(12), 5(1)(f), 5(2), 24, 28, 32, 33, 34, 83
• Data Protection Act 2018 — Part 3 (law enforcement processing), s.148, s.170
• Privacy and Electronic Communications (EC Directive) Regulations 2003 — regs. 5A, 5C
• Network and Information Systems Regulations 2018 — regs. 11, 12
• Communications Act 2003 — s.105K
• Computer Misuse Act 1990 — ss. 1, 2, 3, 3ZA
• Freedom of Information Act 2000 — including ss. 31, 43
• Data (Use and Access) Act 2025 — s.111 (PECR breach notification timescale, in force 20 August 2025); further specified data-protection and PECR enforcement provisions commenced 5 February 2026
• Accounts and Audit Regulations 2015 — internal control and risk management (local authorities)
• Cyber Security and Resilience Bill — before Parliament, not yet law

Where to go next

• ICO — report a breach, and the personal data breach guidance and log template: ico.org.uk/for-organisations/report-a-breach
• ICO — enforcement action taken, including every published penalty notice: ico.org.uk/action-weve-taken/enforcement-action
• ICO — South Staffordshire cyber attack and £963,900 fine: ICO enforcement report
• Department for Education — Customer Help Portal and Turing Scheme incident: DfE incident notice
• UK Parliament — Cyber Security and Resilience (Network and Information Systems) Bill: Bill stages and documents
• GOV.UK — Cyber Security Breaches Survey 2025/2026: official survey
• NCSC — incident reporting, the Cyber Assessment Framework and Cyber Essentials: ncsc.gov.uk
• legislation.gov.uk — the full text of every provision quoted here: legislation.gov.uk