Rules, regulations and fines

This is the fourth of six posts drawn from Concordia on 1 October, where our Managing Director, Yogesh Agarwal, opened the day with six things we keep seeing in our work with clients. Last week we looked at the supply chain. This week: rules, regulations and fines, and what the Cyber Security and Resilience Bill will ask of you.

In October 2025 the ICO fined Capita £14 million, following a criminal cyber attack in 2023 in which the personal data of 6.6 million people was taken. The figure that gets quoted is not the fine. A high priority alert was raised within ten minutes. The affected device was not quarantined for 58 hours, against an internal target of one hour.

The fine itself was for failing to ensure the security of personal data, so it is not quite right to say the response time alone caused it. But the response timeline is what the case is remembered for, and it is what boards have started asking their own teams about.

It is not an isolated case. In May 2026 the ICO fined South Staffordshire £963,900 after a cyber attack exposed the personal data of around 634,000 people. Both fines came from the ICO under data protection law, and that is the part worth holding on to. This is already happening, under rules that are already in force, and it applies to any organisation handling personal data rather than only to the sectors the new Bill names.

What we are seeing

Regulators look at how you prevented, detected and responded, not only at the breach. Being attacked is not in itself a failure, and regulators know that. What gets examined alongside it is what happened once someone knew. How quickly it was understood, contained, escalated and reported.

EU rules can reach UK organisations. NIS2, DORA and the EU AI Act can apply to UK businesses depending on what they do, where they operate and who they serve, rather than on where they are registered. Their scope differs, so each needs checking rather than assuming, and DORA for example is aimed at financial services and their ICT suppliers. When it does land, it tends to arrive through a customer contract rather than a regulator's letter.

Government has gone directly to boards. In October 2025, ministers together with the heads of the NCSC and the National Crime Agency wrote to the CEOs and chairs of leading UK companies, asking them to treat cyber risk as a board-level priority and to use the Cyber Governance Code of Practice. Writing to chairs rather than to IT directors is itself the message.

What the Cyber Security and Resilience Bill will ask of you

The Cyber Security and Resilience Bill completed its third reading in the Lords on 2 November 2026 and returns to the Commons for consideration of amendments. It is not law yet, the detail can still change, and implementation will be phased. Organisations likely to be in scope should be assessing their readiness now, and some already carry duties under the existing NIS Regulations.

Start with whether it applies to you at all. The Bill does not cover the whole economy, and the government says so plainly. It covers operators of essential services in energy, transport, health, water and digital infrastructure, some digital services such as cloud providers and online marketplaces, and the groups the Bill adds: qualifying data centres, relevant managed service providers, large load controllers, and suppliers a regulator designates as critical. If your organisation falls outside the regime, these direct duties would not apply to it. Being in one of those sectors does not by itself make an organisation regulated, so the definitions are worth reading rather than assuming. Where the Bill does apply, the proposed security requirements are expected to align with the Cyber Assessment Framework, and we carry out CAF reviews, including GovAssure, under the NCSC’s Cyber Resilience Audit scheme.

They are still worth understanding, because the organisations that are in scope are somebody's customer and somebody's supplier. Requirements of this kind can arrive through a contract long before they arrive through a regulator, which is the same pattern we described last week.

An initial notification within 24 hours, then a fuller report. The clock starts when you become aware that a reportable incident is taking place, and the first step is a notification rather than a full account. It goes to your regulator, with the NCSC informed at the same time. The fuller report follows within 72 hours. Relevant digital service providers, relevant managed service providers and data centre operators would also have to tell customers who are likely to have been adversely affected.

Higher penalties for regulated entities, in two bands. The upper band is up to £17 million or 4% of worldwide turnover, whichever is higher, for the more serious breaches. The lower band is up to £10 million or 2%, again whichever is higher, for less serious ones. How turnover will be defined is left to secondary legislation. The government’s stated intention is to limit it to a level proportionate to the regulated services, though in some cases, such as where a parent company influenced the decisions behind a breach, group turnover may be considered.

Managed service providers come into scope. This is the change most likely to affect organisations who have never thought of themselves as regulated, which is why it is worth checking the definitions rather than assuming.

Separately from the Bill, the Home Office has set out its response on ransomware payments: a proposed ban on payments by public sector bodies and operators of critical national infrastructure, and a proposed requirement for businesses outside the ban to notify government of their intention to pay. These are still being developed rather than duties in force, and they sit outside the Bill, which is worth knowing because the two get run together.

The 24 hour clock is an operational question, not a legal one

This is the part most organisations find hardest, and it is also the part that is quickest to put right.

Filing a credible report within 24 hours is not really about understanding the regulations. It is about whether, at two in the morning on a Saturday, someone in your organisation knows they are allowed to make that call, has the facts in front of them, and does not need to wait for a committee.

That is a people and process question. The organisations that will find the new timescales manageable are the ones that have already decided who signs off, what the report says when half the detail is still unknown, and who writes it while everyone else is busy fixing the problem.

The good news is that this is a short piece of preparation. It does not need a compliance function or new budget, and a single afternoon with the right people in the room gets most of the way there.

Where we would start

These are the practical steps we recommend to clients:

• Work out which regulators actually apply to you. Most organisations have more than one, and the reporting clocks are not the same length. Writing them on one page is usually a surprise in itself.
• Name who can authorise a report out of hours. One person, with two named deputies, who does not need anyone else's permission. This is the single change that makes a 24 hour clock workable, and where there is nobody obvious to hold it, a virtual CISO can carry that role.
• Draft the 24 hour report now, while nothing is happening. It is short. Write the template, decide what you would say when you do not yet know the scope, and agree that saying so is acceptable.
• Rehearse it with the people who would really be involved. A cyber incident response exercise that includes the reporting decision, not just the technical containment, finds the gaps while they are cheap to fix.
• Check what your own suppliers owe you, and when. If a supplier takes a week to tell you, your 24 hours started without you. Notification timescales belong in contracts at renewal, and mapping who would need to tell you is part of supply chain security.
• Decide your ransomware position in advance. Whether you are in the proposed ban or in the notification group, the time to think about it is not the morning it happens.
• Keep the evidence in one place. Much of what a regulator asks for after an incident is what an ISO 27001 management system already holds, and the same is true of the Cyber Essentials controls the ministerial letter points boards towards.

What this means for you

Regulators are not looking for perfection, and nobody expects organisations to prevent every incident. What is changing is the expectation that you can show what you did, in order, quickly, and that someone at board level understood it.

If that sounds like governance rather than technology, it is. That is the actual shift.