The Cyber Assessment Framework for energy operators: what it asks, and how to evidence it

If you run IT, OT or risk for a UK energy or utilities operator, the Cyber Assessment Framework is the document your regulator will judge you against, and it is unlike most compliance frameworks you will have met. There is no certificate at the end, no clause-by-clause checklist to tick, and no vendor whose product makes you compliant. Instead there are outcomes you have to demonstrate you have reached, in your environment, with evidence. This piece sets out how the framework is actually built, what a credible evidence pack contains, where assessments most often come apart, and how to handle the uncomfortable truth that half your estate cannot be patched on an IT schedule.

The law you are assessed against is the NIS Regulations 2018

Start here, because it is where a surprising number of programmes go wrong.

The UK law for operators of essential services is the Network and Information Systems Regulations 2018, commonly the NIS Regulations. They designate competent authorities by sector, place duties on designated operators to take appropriate and proportionate measures to manage risk to their network and information systems, and require incidents with a significant impact on the continuity of the essential service to be reported.

NIS2 is a different thing. It is an EU directive that updated and widened the original EU NIS regime, and it is transposed separately into each member state's law. It did not replace the UK regulations, and it does not reach a purely domestic British electricity or gas undertaking. It becomes your problem in three specific situations: your group has operations inside the EU, you supply an essential service into a member state, or an in-scope EU counterparty pushes requirements down to you contractually under its own supply-chain security duties. Those are real and worth scoping properly, and we cover that scoping work on the NIS2 page. What they are not is a reason to restructure a Great Britain CAF programme around EU terminology.

The distinction matters practically, not just pedantically. The two regimes use different vocabulary for incident reporting, different thresholds and different authority relationships. A programme built on the wrong one produces evidence nobody asked for and misses the evidence your actual assessor wants.

Who assesses you, and who sets the bar

The NCSC owns the Cyber Assessment Framework, but the NCSC does not assess you. Your competent authority does.

For energy, responsibility is shared. Broadly, Ofgem acts as competent authority for downstream gas and electricity undertakings in Great Britain, with the Department for Energy Security and Net Zero taking other parts of the sector and separate arrangements applying in Northern Ireland. The precise designation follows the licensed activity, so a group that generates, distributes and supplies may find more than one relationship in play. Confirm which authority covers each of your undertakings before you plan anything, because the assessment cycle, the guidance you follow and the reporting route all hang off that answer.

Your competent authority also decides what "good enough" means. The CAF itself does not set a pass mark. The authority publishes or agrees a target profile: the set of contributing outcomes you are expected to have achieved, which can differ by the criticality of the operator and tighten over time. You then self-assess against that profile, produce an improvement plan for the gaps, and submit to whatever review or audit the authority runs. Treat the target profile as the specification for your programme, and get it in writing rather than inferring it from the framework.

How the CAF is built

The structure is simple enough to hold in your head, which is one of its virtues.

Four objectives. Objective A, managing security risk. Objective B, protecting against cyber attack. Objective C, detecting cyber security events. Objective D, minimising the impact of cyber security incidents. Read in order, they are a narrative: understand your risk, reduce it, see what is happening, and survive what gets through.

Fourteen principles sit under those objectives. Objective A covers governance, risk management, asset management and supply chain. Objective B is the largest, covering service protection policies and processes, identity and access control, data security, system security, resilient networks and systems, and staff awareness and training. Objective C covers security monitoring and the proactive discovery of security events. Objective D covers response and recovery planning, and lessons learned.

Contributing outcomes sit under the principles, around forty of them in total. These are the unit of assessment. Each is phrased as a statement about your organisation, and each is graded as achieved, partially achieved or not achieved. Some outcomes offer no partially achieved option, so they are binary.

Supporting each contributing outcome are Indicators of Good Practice: short descriptive statements, arranged by grade, that illustrate what achieving the outcome usually looks like and what falling short looks like. They are the most useful part of the framework in practice, because they tell you what an assessor has in mind without pretending to be a control standard.

The framework is revised periodically, so work from the version your competent authority currently references rather than a copy someone saved to a shared drive two cycles ago. Version differences change the wording of outcomes and occasionally the structure of a principle, and an evidence pack written against a superseded version reads as careless.

Outcome-based means you cannot buy your way through it

The single biggest adjustment for teams coming from Cyber Essentials or an ISO-style control set is that the CAF does not prescribe controls. It describes a state of affairs and asks you to show you are in it.

Take asset management under Objective A. A control checklist would tell you to maintain an asset register and review it quarterly. The CAF instead asks whether you have everything you need to know about the assets that support your essential service, and whether that understanding is accurate and current. You could satisfy that with a configuration management database, with passive network discovery across the control network, or with a rigorous manual process in a small, stable estate. All three can be credible. What is not credible is a register that you cannot show anybody uses, or one whose last meaningful update predates the last plant change.

Two consequences follow, and they are the ones worth taking to a board.

First, tooling is evidence, not achievement. Buying a monitoring platform does not achieve Objective C. Showing which of your systems it covers, which it does not, what the gaps mean for your essential service, who looks at the output, and what happened the last time it fired, achieves Objective C. Procurement is the easy half.

Second, judgement is part of the submission. Because the framework asks about outcomes, you are expected to explain your reasoning: why this risk assessment scope is the right one, why this asset is out of scope, why this compensating control is proportionate for an asset you cannot patch. Operators who write that reasoning down tend to score better than operators with more technology and no narrative, because the assessor can follow the logic.

What an evidence pack actually looks like

An evidence pack is not a folder of policies. It is a structured argument, organised by contributing outcome, that a reader who does not know your estate can follow.

For each contributing outcome in your target profile, you want:

• •A claim. Your own grading, with a sentence or two of reasoning.
• •The scope it applies to. Which systems, sites and essential services. This is where vagueness is most often exposed.
• •The artefacts that support it. Policies where the outcome is about governance, but mostly operational records: the asset inventory extract, the access review output, the monitoring coverage map, the change records, the exercise report, the ticket showing a vulnerability decision.
• •Evidence it is live rather than historic. Dates, owners, and the cadence the activity runs on. A policy approved three years ago with no review record is weaker than a plainer policy with a visible review trail.
• •Known gaps and what you are doing about them. Declared gaps with owners and dates read as control. Gaps the assessor finds for you read as something else.

A worked example helps. For security monitoring under Objective C, a thin pack contains a SIEM licence and a policy stating that logs are monitored. A credible pack contains a coverage map showing which asset classes and which network zones send telemetry and which do not, the retention period and why it was chosen, the use cases and detections that are actually enabled, the names and hours of the people who triage alerts, three worked examples of alerts raised and what was done, and an honest statement that the substation estate currently sends only boundary telemetry, with the plan and date for extending it. The second pack is longer, but it is also the one that survives a question.

The other practical point: the pack should be a by-product of how you operate, not a project. Evidence assembled in the eight weeks before a submission is thin by construction, because it can only show the last eight weeks. This is the argument for running the evidence discipline continuously, which is exactly what our continuous compliance service is for, and for your sector page if you want the shorter version of how we approach the sector.

The four gaps that come up every time

Across energy and utilities assessments, the same four weaknesses recur.

1. An asset inventory that stops at the IT boundary

Corporate IT inventories are usually decent, because something automated maintains them. The OT side is frequently a spreadsheet that was accurate at commissioning. Without a defensible inventory across both, you cannot define the scope of the essential service, which means Objective A is shaky and every dependency argument further down the framework rests on sand.

What helps: a single inventory with OT and IT in the same model, built using passive discovery where active scanning is unsafe, enriched from engineering records and vendor documentation, and tied into the change process that governs plant modifications. Record firmware and software versions, supported status, and the owner, because you will need all three for the patching conversation.

2. Supply-chain assurance that is paperwork

Objective A includes supply chain for good reason: in energy, a large share of the real risk arrives through original equipment manufacturers, systems integrators and maintenance contractors with remote access into control environments. A pile of completed questionnaires does not evidence that outcome.

What helps: a register of third parties mapped to the systems and essential services they touch, their access routes written down and verified rather than assumed, contractual security requirements that match the access actually granted, and evidence of the access being controlled in practice, which usually means brokered, time-bound, individually attributed and logged sessions rather than a shared VPN account and a standing firewall rule.

3. Detection coverage that does not reach OT

This is the most common Objective C gap, and often the most honestly held: teams know the control network is dark and have good safety reasons for not deploying agents on it. The mistake is leaving the gap undeclared, or implying coverage that does not exist.

What helps: passive network monitoring inside the OT environment, where a sensor on a span port can give you protocol-aware visibility without touching a controller; thorough monitoring at the IT and OT boundary, including the jump hosts and data historians that straddle it; and a written coverage map that states plainly what is and is not monitored. Where you want that watched around the clock by people who understand both sides, that is the job our managed security service does, and it is also where a lot of operators find the quickest improvement against Objective C without touching a single production controller.

4. An incident response plan that has never met reality

Objective D is about minimising impact, and the test is not whether a plan exists. It is whether the organisation can execute it. Plans written by IT, exercised by IT, and silent on operational decision making fail that test, because the hard calls in an energy incident are operational: whether to move to manual control, whether to isolate a site, who authorises a shutdown, what you tell the control room.

What helps: a plan that names decisions and decision makers rather than only technical steps, at least one exercise a year that puts engineering, operations, communications and leadership in the room together, and a record of what the exercise found and what changed as a result. Our ransomware readiness checklist sets out the four stages of that readiness in a form you can take to a leadership meeting.

Why OT cannot be patched like IT, and what to do instead

This is the conversation most operators dread with an assessor, and it is much less dangerous than it feels, provided you handle it openly.

The reasons OT cannot run an IT patch cadence are legitimate, and an experienced assessor knows them. Control systems are engineered for availability over years, not for a monthly reboot window. The software stack is often vendor-validated as a unit, so patching outside the vendor's release cycle can void support or invalidate a qualification. Some assets sit inside a safety case, where an unplanned change is itself a hazard. Maintenance windows may come round once or twice a year and compete with every other engineering demand. And a meaningful share of the estate runs software whose vendor stopped issuing fixes years ago.

None of that excuses leaving the risk unmanaged. What the framework expects is that you understand the exposure and have done something proportionate about it. In practice that is architecture plus visibility.

Segmentation, properly. The reference model here is IEC 62443, which organises an industrial environment into zones, groupings of assets with a shared security requirement, connected by conduits, the controlled and monitored pathways between them. Done properly it means a compromise in the corporate estate does not reach a controller, and a compromise in one zone does not reach the next. Done as a flat network with one firewall and a long rule list, it means very little. Most of the segmentation value in energy comes from a small number of deliberate decisions: separating corporate IT from the control environment, separating the control environment from safety systems, breaking site networks apart so one substation or plant is not a route into the rest, and making the data historian and jump host the only ways across. Our network security work is largely this, and it is the control with the best ratio of risk reduction to operational disruption.

Monitoring at the boundary. If you cannot see inside a zone, see everything crossing its conduits. Boundary telemetry from the IT and OT interface, the remote access path and the jump hosts catches most of what matters, because that is where an intruder has to pass to reach anything interesting.

Controlled remote access. Vendor and contractor access is the other half. Brokered sessions, individual identities, multi-factor authentication, time-boxed approvals, recording where practical, and no standing routes. This one tends to be unpopular and is worth doing anyway.

A vulnerability process that records decisions. For each unpatchable asset: the vulnerability, why it cannot be remediated now, the compensating controls that reduce the exposure, the residual risk accepted, who accepted it, and when it will be reviewed. This single artefact closes more Objective B conversations than any tool, because it shows the risk is managed rather than ignored. Where you want the exposure tested rather than assumed, scoped and safely conducted penetration testing against the boundary, the remote-access path and the IT estate gives you the evidence, and we scope OT-adjacent testing conservatively for obvious reasons.

Incident reporting, and the decisions you have to make quickly

The NIS Regulations require designated operators to notify their competent authority of incidents that have a significant impact on the continuity of the essential service, without undue delay and in any event within a short window measured in hours rather than days, which the Regulations put at no later than 72 hours after becoming aware. The thresholds that make an impact "significant" are sector-specific and come from your competent authority's guidance, typically framed around factors such as the number of users affected, the duration of the disruption and its geographic spread. Get those thresholds, in writing, before you need them, and keep the current version to hand.

Two things make this harder than it sounds. The first is that the clock starts when you become aware, not when you have finished investigating, so you will be reporting on incomplete information. The second is that the judgement about whether a threshold is met is operational, not technical, and the person who can make it may not be in the first conversation. Both are solved the same way: decide in advance who assesses reportability, what information the first notification contains, and who signs it off, then rehearse it. An operator that can produce a first notification inside the deadline with an honest "here is what we know and what we do not" is in a far better position than one that spends two days trying to be certain.

Note also that non-compliance under the NIS Regulations carries civil penalties, in tiers, with substantial maximums for the most serious failures. The practical exposure for most operators is less about the headline figure and more about the enforcement relationship: an authority that finds material gaps you had not declared will scrutinise everything else you submit.

The Cyber Security and Resilience Bill: on the horizon, not in force

The regime is changing, and it is worth planning for without over-reacting.

The Cyber Security and Resilience Bill is the UK's update to the NIS Regulations, prompted by the threat landscape and by the EU's move to NIS2. At the time of writing it is still before Parliament: it passed the House of Commons in June 2026 and is being considered by the House of Lords. It is not law, and nothing in it is enforceable against you yet. Parliamentary timetables shift, so check the current stage rather than relying on a date in an article, including this one. We track the position on our regulation tracker.

The direction of travel is clear enough to be useful. The Bill is expected to widen the set of organisations with duties, including managed service providers and data centres, update and strengthen incident-reporting requirements, and give regulators more powers and better information. For an energy operator already working to a CAF target profile, that is an extension of a regime you are in rather than a new one, and the sensible response is not to wait. The gaps listed earlier in this piece are the gaps a widened regime will also ask about. Closing them now is work you would have to do anyway, and it has the advantage of being done calmly.

The one thing worth doing specifically in anticipation is scope. If the Bill widens duties to parts of your group, or to suppliers you depend on, you want to know which ones before the commencement date rather than after. That is a mapping exercise you can run today against the Bill as drafted, with the caveat that the drafting can change in the Lords.

Where to start

If you are early in this, the useful first move is not a tool and not a policy refresh. It is an honest baseline against your target profile, outcome by outcome, with the gaps written down and ranked by what they mean for the essential service rather than by how hard they are to fix. That tells you where the real exposure is, and it gives you an improvement plan your competent authority can see progress against.

That is what a Cyber Assurance Assessment produces: a defensible current-state position, a prioritised route to the profile you need, and the evidence structure to keep it true next cycle. Where certification such as ISO 27001 is also in play for the management system behind it, that is delivered through certified assessment partners, with us remaining your single point of accountability for the work and the evidence.

To talk through where your organisation sits against the CAF, and what the first useful step would be, book a 30-minute call. If it is more specific than that, for example you have a target profile in hand and want a second opinion on two or three contributing outcomes, send us the detail and we will come back on it.