Regulation and assurance
A regime binds an organisation because of where it operates, what sector it serves, how large it is, and what it sells, not because of how much it spends on security. The first professional question in any regulatory conversation is therefore narrow and testable: does this rule apply to us, and from what date? This module gives you the map to answer it, separates the EU stack from the UK path, and shows why a certificate on the wall is not the same as being hard to attack.
This module opens the Practice and Strategy stage. Every later module in the stage cites an obligation established here: secure development answers to CAF outcome A4.b, exposure reduction to A4, resilience to CAF objective D, and the OT module to the NIS Regulations 2018. Read this first and the rest of the stage reads as consequence.
By the end of this module you will be able to:
- Map which regimes apply to a given organisation by jurisdiction, sector and size
- State the NIS2, DORA and Cyber Resilience Act obligations with their application dates
- Explain the UK path (NIS 2018, CAF v4.0, the CSR Bill) and how it diverges from NIS2
- Place ISO 27001:2022, Cyber Essentials and CAF self-assessment as assurance instruments
- Say what each instrument evidences, to whom, and what none of them evidences
- Brief a board on management-body accountability for cyber risk
The regulator started suing governments, not just companies
NIS2, the second European Network and Information Security Directive, set member states a firm deadline: transpose it into national law by 17 October 2024. A directive is not self-executing. It binds each government to pass its own statute, and until that statute exists, the companies inside that country have no NIS2 obligations to meet. The deadline passed and most governments missed it.
By mid-2026, 22 of the 27 member states had transposed. In response to the shortfall the European Commission opened infringement proceedings and referred Ireland, Spain, France and the Netherlands to the Court of Justice of the European Union for failing to transpose in time. The lesson for a practitioner is easy to miss and worth holding onto: regulators now litigate against national governments, not only against the firms those governments oversee. A rule can be politically agreed, published, and still not yet bind you, because the machinery that turns a directive into an enforceable duty runs on its own timetable.
That gap between agreement and application is exactly what a board wants you to track. The wrong answer to "are we regulated by NIS2" is a confident yes or no. The right answer names the jurisdiction, checks whether the transposing law is in force there, and gives a date.
If a European directive is not written into national law on time, who is at fault, and who does the Commission pursue?
1. Why the regulation arrived when it did
For twenty years, cyber security for most essential services was a matter of guidance and goodwill. Governments published advice, industry bodies wrote codes of practice, and the market was trusted to price the risk. It did not work well enough. Attacks on hospitals, pipelines, ports and utilities showed that when a breach harms the public rather than only the breached firm, voluntary adoption leaves too much unprotected. The wave of law that arrived between 2024 and 2026 exists to close that gap.
The mechanism the new statutes reach for is accountability at the top. Rather than mandate a fixed list of controls, which would be out of date within a year, they place a duty on the people who run the organisation. This is the idea of : the board or its equivalent must approve the cyber risk approach, oversee it, and can be held personally answerable when it is neglected. The practical effect is that cyber stops being discretionary spend that a finance director can defer and becomes a directors' duty, which changes who has to be in the room when a decision is made.
The scope of these duties usually turns on a status label. An , for example, is an organisation whose disruption would have a serious effect on an activity the public depends on, such as electricity, water, transport or health. Once an organisation carries that label, a named authority for its sector can require evidence, set expectations and impose penalties. So the first task in any regulatory assessment is not to read the rules; it is to work out which labels apply to you.
2. The EU stack: four regimes, four application dates
The European Union built its cyber duties as a set of separate instruments, each aimed at a different slice of the economy and each with its own start date. Teaching these well means teaching dates and applicability tests, not one-line summaries, so the four that matter are laid out below with the questions a reader should ask of each.
is the general baseline for important and essential entities across sectors from energy to digital infrastructure. Its transposition deadline was 17 October 2024. It requires management-body oversight, risk-management measures, and a staged incident report: an early warning within 24 hours, a fuller notification within 72 hours, and a final report within one month. Administrative fines reach up to 10 million euros or 2 percent of global annual turnover for essential entities, whichever is higher. The applicability question is whether the entity operates in a listed sector, meets the size threshold, and is established in a member state whose transposing law is in force.
, the Digital Operational Resilience Act, has applied since 17 January 2025 to almost every EU financial entity, from banks and insurers to trading venues. It demands an information and communications technology risk-management framework, major-incident reporting, threat-led penetration testing for the largest firms, and registers of third-party technology providers, with the first register submissions due by 30 April 2025. It also brings the most critical technology providers under direct EU oversight. The applicability question here is simpler: is the entity a regulated financial firm operating in the EU?
The regulates products, not operators. It entered into force on 10 December 2024. From 11 September 2026 manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents on a 24-hour, 72-hour and 14-day cadence, and the full set of obligations, including the CE marking that gates market access, applies from 11 December 2027. The applicability question is about what you sell: does the organisation place a product with digital elements on the EU market?
The EU AI Act runs on a staggered timetable of its own. Prohibited practices became unlawful in February 2025, obligations for general-purpose AI models followed in August 2025, most high-risk duties apply from 2 August 2026, and a 2026 simplification package deferred some standalone high-risk duties towards December 2027. Treat it as a separate obligation to check for any organisation deploying AI in a regulated context; the AI security module returns to its technical demands in detail.
Common misconception
“NIS2 applies to us in the UK, and a GDPR-style breach always means a fine of 4 percent of turnover.”
NIS2 is EU law. It binds entities established in EU member states whose transposing statute is in force; it creates no duty for a purely UK organisation. The UK path runs through the NIS Regulations 2018 and, once enacted, the Cyber Security and Resilience Bill. The fine figures attached to these regimes are ceilings, tiered by the severity of the failure and rarely reached, not a flat percentage applied to every incident. Quoting a maximum as if it were the expected outcome misleads a board about the real exposure.
3. The UK path diverges from NIS2
The United Kingdom did not adopt NIS2. Its statutory baseline remains the Network and Information Systems Regulations 2018, which predate the EU update and use the operator of essential services and relevant digital service provider labels rather than the essential and important entity split. Each sector has a designated competent authority: in energy, operators answer to Ofgem and the Department for Energy Security and Net Zero, assessed against an Ofgem-adapted profile of the national assessment framework. A UK water utility asking which incident-reporting regime binds it today is bound by the NIS Regulations 2018, applied by its sector authority, and not by NIS2, which has no UK effect.
The gap is being closed by new primary legislation. The was introduced on 12 November 2025, cleared the Commons, and was before the House of Lords in June 2026, with Royal Assent expected late in 2026. It widens scope to bring managed service providers and data centres into the regime, introduces 24-hour initial incident reporting, and raises the penalty ceiling to 17 million pounds or 4 percent of global turnover. Until it receives Royal Assent it is a Bill, not a law, so an organisation that reports today reports under the 2018 Regulations. Dates and status, once again, are the substance of the answer.
The assessment tool behind the UK regime is the NCSC . Its version 4.0 was released on 6 August 2025 and is outcome-based rather than a control checklist: it asks whether an organisation achieves security outcomes, grouped under four objectives. Version 4.0 added new contributing outcomes, most visibly A2.b on understanding attackers and A4.b on secure software development and support, threaded threat hunting and AI risk through the framework, and introduced 108 new indicators of good practice. For critical national infrastructure, the effect of A4.b is concrete: secure development stopped being hygiene advice in August 2025 and became part of the assured scope.
The UK also moved first on ransom payments. On 22 July 2025 the government confirmed, in its response to a consultation, a targeted ban on ransom payments by the public sector and operators of critical national infrastructure, alongside proposals to increase incident reporting. The ransomware module examines what that ban does and does not change; here it matters as one more UK-specific obligation that has no direct EU equivalent.
4. Assurance instruments and what none of them evidence
Regulation says what must be achieved. Assurance instruments are how an organisation demonstrates it. The three a UK reader meets most often each evidence something different, to a different audience.
certifies that an organisation runs a working information security management system: a set of policies, risk assessments and controls that is reviewed and improved on a cycle. The 2022 edition carries 93 Annex A controls grouped into four themes, and Amendment 1 of 2024 added a climate-change consideration. The old 2013 edition had 114 controls in 14 domains; its transition window closed in October 2025, so describing a certificate against the 2013 structure is now simply out of date. A certificate is issued by an accredited external auditor and is meaningful to customers and partners who want proof that a management system exists and was examined.
is the UK government-backed baseline: five technical control areas, verified by self-assessment or, in its Plus tier, by hands-on testing. It is designed to remove the commodity attacks that make up most of the volume, and it is often a condition of public-sector contracts. It evidences that a defined floor of basic hygiene is in place, to a buyer who needs a quick, comparable signal.
CAF self-assessment sits behind the UK regulatory regime and evidences, to a sector authority, that an operator has reasoned about the security outcomes the framework sets and can show where it stands against them. It is the deepest of the three because it is outcome-based and adversary-aware, but it is still a self-declared position that an authority may test.
What none of the three evidences is resistance to a determined attacker on the day of the attack. Each is a snapshot of a management system or a control set at a point in time, produced under known conditions and often by the organisation about itself. The professional habit that keeps you honest is to pair every framework with a second question: whatever this certificate says, what would an attacker do anyway, and would we see it? Certification and security overlap, but they are not the same thing, and a board that confuses them buys a false sense of safety.
Common misconception
“We hold ISO 27001 and passed Cyber Essentials, so we are secure and compliant covers the risk.”
Compliance and security are related but distinct. A certificate is evidence that a management system was examined against a standard on a given date, usually with the scope and timing known in advance. It does not measure whether a live intrusion would succeed. TalkTalk, Equifax and many certified organisations have been breached through gaps their certifications never tested. Treat every framework as a floor that removes commodity attacks and evidences diligence to a specific audience, then run the separate exercise of asking what a motivated attacker would still get through.
5. Working out your obligations: a one-page map
Put the pieces together and the assessment becomes a short sequence of questions. Where does the organisation operate, in the UK, the EU, or both? What sector does it serve, and does that sector carry an essential or important label? How large is it against the size thresholds each regime sets? What does it sell, and does that product have digital elements placed on the EU market? Who are its customers, and do their contracts import obligations of their own? Each answer switches a regime on, off, or to watch, and each regime that switches on carries a first date that matters.
Run the course capstone organisation, MedCore, a UK-based medical-device and clinical software company that also sells into the EU, through the map. It operates in the UK, so the NIS Regulations 2018 apply through its sector authority, and the Cyber Security and Resilience Bill is a watch item for its expected late-2026 assent. It places products with digital elements on the EU market, so the Cyber Resilience Act applies, with vulnerability reporting from 11 September 2026 and full obligations from 11 December 2027 as the dates to plan against. It is not a financial entity, so DORA does not bind it, though a banking customer may still pass DORA third-party expectations down by contract. Its AI-assisted triage feature puts the EU AI Act on the watch list. Two regimes on, two to watch, one off, each with a named first date: that is the brief a board can act on, and it is produced by applying the map, not by reciting the law.
The workspace mapper turns this same sequence into a tool. You enter an organisation profile, toggle each regime, and read back which apply, which to watch, and the first deadline for each, drawn on the two-lane timeline from the top of this module.
A UK-only ambulance trust asks which incident-reporting regime binds it today, in mid-2026. Which answer is correct?
A UK manufacturer sells an internet-connected sensor into the EU market. Which EU regime most directly governs that product, and what is the key date?
A board is told the company holds ISO/IEC 27001:2022 and asks whether that means it is secure against ransomware. What is the strongest professional response?
Try it in the workspace
A studio tool turns this module into something you can build and export.
Core distinctions
- A regime binds an organisation by jurisdiction, sector, size and product, not by security spend. The first question is always whether a rule applies and from what date.
- The EU stack is four instruments with four dates: NIS2 (transposition deadline 17 October 2024, 24h/72h/one-month reporting), DORA (financial entities since 17 January 2025), the Cyber Resilience Act (products, reporting from 11 September 2026, full obligations from 11 December 2027) and the EU AI Act on a staggered timetable.
- The UK did not adopt NIS2. Its baseline is the NIS Regulations 2018, applied by sector competent authorities such as Ofgem for energy, with the Cyber Security and Resilience Bill widening scope and expected to receive Royal Assent late 2026.
- CAF v4.0 (released 6 August 2025) is outcome-based across four objectives and now folds attacker understanding (A2.b) and secure software development (A4.b) into the assured scope for critical national infrastructure.
- ISO/IEC 27001:2022 (93 controls, four themes), Cyber Essentials and CAF self-assessment each evidence something to someone, but none evidences resistance to a live attacker. Pair every framework with the question of what an attacker would do anyway.
Standards and sources cited in this module
NIS2 Directive, European Commission policy page
Scope, management-body accountability, and staged incident reporting
Primary EU source for NIS2 scope, the 24-hour and 72-hour and one-month reporting cadence, and the essential and important entity split used in Section 2.
NIS transposition status, European Commission
Member-state transposition and infringement proceedings
Source for the mid-2026 transposition count and the referral of Ireland, Spain, France and the Netherlands to the Court of Justice, used in the opening story.
Digital Operational Resilience Act (DORA), EIOPA
ICT risk framework, incident reporting and third-party registers
Primary source for DORA scope and the 17 January 2025 application date cited in Section 2.
Cyber Resilience Act, European Commission
Products with digital elements, reporting cadence and CE marking dates
Source for the 10 December 2024 entry into force, the 11 September 2026 reporting duties and the 11 December 2027 full obligations used in Section 2 and the knowledge check.
Cyber Security and Resilience Bill, UK Parliament
Bill stages, scope changes and reporting duties
Source for the 12 November 2025 introduction, the June 2026 Lords stage and the scope and penalty changes in Section 3.
NCSC blog, CAF v4.0 released in response to growing threat
New outcomes A2.b and A4.b, threat hunting and 108 new indicators
Source for the 6 August 2025 CAF v4.0 release and the additions taught in Section 3 and drawn in the CAF figure.
ISO/IEC 27001, International Organization for Standardization
2022 edition: 93 Annex A controls in four themes, Amendment 1:2024
Source for the ISO 27001:2022 structure and the closed 2013 transition window used in Section 4.
CAF outcome A4.b just put secure software development inside the assured scope for critical national infrastructure. The next module takes that obligation and turns it into engineering practice: how a team builds security into the development lifecycle, measures its maturity, and produces the evidence an assessor asks for.
Module 22 of 41 · Practice & Strategy