NIS2 and CAF Compliance: What Actually Changes for CNI Teams

NIS2 and NCSC CAF v4.0 are distinct instruments, but they point in the same direction: away from point-in-time compliance and towards continuous, demonstrable resilience.

NIS2 covers 18 critical sectors across the EU, expanded from the original NIS Directive, and divides organisations into Essential Entities (proactive supervision, higher penalties) and Important Entities (reactive supervision, lower penalties). For UK organisations, the domestic equivalent is the UK Cyber Security and Resilience Bill, which extends the existing NIS Regulations 2018 to cover managed service providers, designated critical suppliers, and data centre operators for the first time.

NCSC CAF v4.0, published on 6 August 2025, is the most significant revision of the framework since its introduction in 2018. It introduces 108 new Indicators of Good Practice across four objectives.

The headline changes are:

1. A new Contributing Outcome (A2.b): Understanding Threat. Organisations must document threat analysis methodologies and demonstrate the ability to model attack scenarios using structured techniques such as attack trees.
2. A new Contributing Outcome (A4.b): Secure Software Development and Support, covering software bills of materials, code provenance, and supplier assurance on development practices.
3. Rewritten Objective C monitoring requirements: threat hunting replaces the previous 'search for system abnormalities' standard, and C1.f adds requirements for behavioural analysis and integrated threat intelligence.
4. AI and automated decision-making: where AI supports essential functions, organisations must demonstrate visibility into how those systems behave and how they could be influenced.

Key takeaway: CAF v4.0 marks a substantial revision. Teams that assessed themselves against v3.2 will find the bar has moved, particularly in threat intelligence, software assurance, and board-level governance.

The two frameworks are complementary: NIS2 defines the legal obligation and the penalty regime, while the CAF provides the operational assessment structure to demonstrate compliance with it. For UK CNI (critical national infrastructure) and government teams, meeting CAF v4.0 expectations is the practical path to NIS regulatory compliance.

The most significant structural change is one many teams underestimate: governance of cyber resilience moves from a technical function to board-level accountability. Both NIS2 (Article 20) and CAF v4.0 place explicit accountability at the management body level, and management can be held personally liable for non-compliance. CAF v4.0's Achieved criteria under Principle A1.a (Board Direction) make this concrete: the board needs “the information and understanding needed in order to effectively discuss how the security and resilience of network and information systems contributes to the delivery of essential functions and what the potential impact from compromise would be.”

For a full breakdown of how CAF's governance principle maps against NIS2 Article 20 line by line, see SureCloud's NIS2-to-CAF mapping guide.

What this means for compliance and risk teams

In practice, this creates three new demands:

1. Board reporting must be substantive: a quarterly slide deck with a RAG status doesn't cut it any more. The board needs to understand threat context, control effectiveness, and the operational impact of specific risks, and reporting cycles are compressing as a result.

2. Governance documentation must demonstrate active oversight: minutes, decisions, escalation trails, and sign-offs must be recorded in a way a regulator can audit. A governance framework that lives only on paper won't survive scrutiny; it needs to be visibly practised.

3. Risk appetite must be formally defined: boards must be able to articulate what level of disruption is acceptable and connect that articulation to actual controls protecting essential functions.

The teams that struggle here are the ones where cyber risk reporting has historically been produced by the security function and consumed by the CISO in isolation. NIS2 and CAF v4.0 require that chain to extend upward, with the board demonstrably engaged.

For a template on structuring that reporting, see SureCloud's guide to board-level ICT risk dashboards.

Incident response under NIS2 Article 23 is now a legally timed obligation with a structured evidence trail attached to it. The UK Cyber Security and Resilience Bill mirrors that structure with its own two-stage notification framework for all regulated entities:

All notifications go to both the relevant Competent Authority and the Computer Security Incident Response Team (CSIRT) simultaneously. Data centre operators, managed service providers, and digital service providers face additional customer notification obligations. SureCloud's guide to enterprise incident management covers how regulatory clocks like these should trigger automatically rather than depend on someone remembering to start them.

The operational reality

Most CNI and government teams have incident response plans. Few are calibrated to a 24-hour notification clock, and that gap, between having a plan and being able to notify accurately within 24 hours, is where organisations are most exposed.

Three capabilities must be in place before an incident occurs:

1. Logging and detection infrastructure that surfaces incidents quickly enough for accurate early notification. If your detection average is 48 hours, your notification obligation is already in breach.
2. Pre-agreed notification templates and escalation paths, so the 24-hour window isn't spent deciding who writes the notification or who authorises it.
3. Evidence capture from the first moment of awareness. Regulators will examine the timeline, and the gap between occurrence, detection, and notification must be explainable and defensible.

The real exposure sits in the audit trail. Regulators examining a breach will scrutinise whether adequate controls were in place before the incident, and a weak evidence trail for the 24 hours following detection signals that the broader control environment may fall short of the standard.

Supply chain security is where NIS2 and CAF v4.0 create the most work for teams that have managed third-party risk through periodic questionnaires and annual reviews. Both frameworks require active, ongoing assurance of suppliers to essential functions.

CAF v4.0 raises the bar with two new supply chain outcomes under Objective A: suppliers to essential functions must demonstrate proportionate cyber security against common threats, and critical suppliers face a higher bar requiring documented risk assessment. NIS2 Article 21 adds a duty to assess the security practices of all direct suppliers regardless of criticality tier, and the UK Cyber Security and Resilience Bill goes further still: it introduces a direct regulatory designation regime, meaning some suppliers to Operators of Essential Services may themselves become regulated entities.

For the detailed principle-by-principle comparison, see SureCloud's guide to third-party risk management for regulated UK firms.

The practical shift

For teams managing large supplier estates, this represents a structural change in how third-party risk gets assessed, evidenced, and reported. Organisations relying on spreadsheet-based third-party risk management (TPRM) processes will find the new standard difficult to meet consistently, and harder still to demonstrate to a regulator.

CAF v4.0's monitoring changes represent the most technically demanding shift for many CNI teams. The previous standard asked organisations to routinely search for system abnormalities indicative of malicious activity. Version 4.0 replaces that with a structured threat hunting requirement. A genuine step up in expectation.

The new standard under C2.b and C1.f

C2.b (Threat Hunting) requires threat hunting activity that's purposeful, structured, and intelligence-led. To achieve the 'Achieved' rating, organisations must proactively search for hostile tactics, techniques and procedures, rather than responding only to known indicators of compromise such as hostile IP addresses.

C1.f (Understanding User and System Behaviour and Threat Intelligence) is an entirely new Contributing Outcome. It requires organisations to understand and use behaviour patterns to identify abnormal activity, integrate threat intelligence into monitoring practices, and share intelligence with the wider community where appropriate.

This goes well beyond traditional log analysis. It requires skilled in-house threat hunters or a managed detection capability with the depth to apply behavioural analysis against the specific threat profile of the organisation's essential functions. Teams already running continuous controls monitoring across their existing frameworks have a head start, since the evidence infrastructure is similar.

Why this matters for CNI specifically

Critical national infrastructure faces a different threat landscape from most organisations. Nation-state actors with advanced capabilities, persistence, and long-term strategic objectives are a realistic threat model here, and CAF v4.0 makes this explicit: organisations must be capable of defending against adversaries with extensive resources and deep technical capability.

A monitoring programme calibrated only to commodity malware and opportunistic attacks falls short of the CAF v4.0 standard for an essential service provider. The framework now expects the threat model to reflect the actual adversary landscape, including anticipating technological developments that could be exploited against essential functions.

For many teams, this means investing in new threat intelligence capabilities, or building a formal relationship with a provider that supplies them.

The most consequential change runs through both frameworks as a shared design principle: compliance becomes an ongoing posture that teams sustain continuously. This is a genuine shift for teams that have run compliance as a project cycle: assess against the framework, remediate gaps, produce evidence, pass the assessment, repeat next year. NIS2 and CAF v4.0 are built around a different model.

What continuous assurance looks like in practice

Under NIS2, Essential Entities face proactive supervision: regulators don't wait for an incident to examine whether controls are in place, and they can request evidence of ongoing compliance at any point. Important Entities face reactive supervision, but the obligation to maintain controls is continuous regardless.

CAF v4.0's outcome-driven structure reinforces this: it asks whether your controls remain effective over time, a more demanding bar than passing a single assessment. IGPs require organisations to validate that security measures stay effective for as long as they're needed.

The practical implication: controls need ongoing monitoring, current evidence, and risk registers that reflect the live threat environment rather than last year's assessment.

The tooling question

This is where the gap between intent and execution becomes most visible. A GRC (governance, risk, and compliance) programme built on spreadsheets, periodic manual reviews, and evidence collected in the weeks before an audit struggles to sustain continuous assurance at the standard NIS2 and CAF v4.0 require. The volume of controls, the frequency of evidence requirements, and the need for real-time visibility across essential functions make manual processes a structural bottleneck.

Organisations that have already moved to platform-based compliance management need less effort at assessment time, because evidence collection runs continuously rather than retrospectively. SureCloud's Gracie AI Agents with Personas and Skills support this model directly: Gracie AI Agents map controls across NIS2, CAF v4.0, and ISO 27001 simultaneously, so a single piece of evidence satisfies multiple frameworks at once, inside SureCloud's Compliance Management platform.

One SureCloud customer put it simply:

“SureCloud gave us the flexibility to design our own user journeys and reporting tools.”

Each Competent Authority sets its own transition period for adoption from v3.2, so timelines vary and some teams have more runway than others. Early movers avoid the risk of a compressed remediation window once their authority announces a deadline.

The following priorities apply regardless of where your organisation currently sits on the maturity curve.

Immediate actions (first 90 days)

1. Determine your classification: Confirm whether you're an Essential or Important Entity under NIS2, and identify your relevant Competent Authority under the UK Cyber Security and Resilience Bill.
2. Map your essential functions: Both frameworks anchor to essential functions specifically, so risk assessments, controls, and evidence need to trace back to those functions.
3. Run a gap assessment against CAF v4.0: If you have a current v3.2 assessment, identify which of the 108 new IGPs represent gaps, and prioritise A2.b (Understanding Threat), A4.b (Secure Software Development), and C1.f (Behavioural Analysis and Threat Intelligence).
4. Review your incident response plan against the notification timeline: Test whether your current detection and escalation capability supports a 24-hour initial notification, and identify the gaps before an incident does.

Medium-term actions (3-12 months)

1. Audit your critical supplier relationships: Identify which suppliers have access to systems supporting essential functions, assess whether they can demonstrate appropriate cyber security, and start gathering evidence rather than attestations.
2. Establish a board-level reporting cadence: Design reporting that gives the board genuine visibility of threat context, control effectiveness, and residual risk, and document the governance trail.
3. Assess your monitoring capability against the threat hunting standard: Determine whether your current SIEM and SOC arrangements meet C2.b and C1.f, or whether you need additional investment or external support.
4. Evaluate your compliance tooling: If your current approach relies on manual evidence collection and periodic assessments, model the effort required to sustain continuous assurance and whether the tooling can scale.

For a deeper look at building a single compliance programme across NIS2, CAF v4.0, and adjacent frameworks, see SureCloud's NIS2 compliance whitepaper. The organisations that find NIS2 and CAF v4.0 most manageable treat the transition as an ongoing programme rather than a one-off project, because the compliance obligation continues for as long as the essential function operates.