Imagine you run IT for a water treatment facility in Dutchess County. Your plant has served communities along the Hudson River for decades, and your cybersecurity program is built around NIST CSF — the framework your American auditors know, your insurance carrier expects, and your team trained on. Then, on a Tuesday morning, an email arrives from Group Security at the London headquarters of your parent company. Subject line: "CAF Self-Assessment — Required by Q3." Attached is a spreadsheet with 14 principles, four objectives, and terminology that reads like it was written for a different planet.
This scenario is playing out more frequently across the Hudson Valley. As UK-based conglomerates acquire American utilities, manufacturing operations, and infrastructure providers in the region, they bring along their domestic compliance expectations. The National Cyber Security Centre's Cyber Assessment Framework — CAF for short — is the UK government's primary tool for evaluating the cybersecurity posture of organisations that operate essential services. And when your parent company falls under the UK's Network and Information Systems (NIS) Regulations, every subsidiary that touches those essential services gets pulled into scope, regardless of which side of the Atlantic it sits on.
This post walks through what the CAF actually requires, how it maps to the NIST CSF work you have likely already done, and how to build an evidence pack that satisfies London without reinventing your entire program.
What the CAF Is and Why It Exists
The Cyber Assessment Framework was developed by the UK's National Cyber Security Centre — the public-facing arm of GCHQ — to provide a systematic way to assess the cyber resilience of organisations that deliver essential services. Think energy, water, transport, and health. The CAF is not a certification scheme like ISO 27001 or a maturity model like CMMC. It is an outcomes-based assessment. The question it asks is not "do you have a policy?" but "can you demonstrate that the outcome described in each principle is actually being achieved?"
Version 3.2, the current release, organises its requirements into four top-level objectives, which break down into 14 principles. Each principle contains a set of contributing outcomes — specific, measurable results that an organisation should be able to evidence.
The Four Objectives at a Glance
Objective A: Managing Security Risk. This is the governance layer. It asks whether your organisation understands the risks to the networks and information systems that support essential services, and whether appropriate policies and processes are in place to manage those risks. There are four principles here, covering governance (A1), risk management (A2), asset management (A3), and supply chain security (A4). If you have a functioning risk register and an asset inventory tied to your operational technology environment, you are already partway there.
Objective B: Protecting Against Cyber Attack. This is the controls layer. Five principles cover service protection policies (B1), identity and access management (B2), data security (B3), system security (B4), and resilient networks and systems (B5). For a Hudson Valley water treatment plant or manufacturing operation with both IT and OT networks, B4 and B5 tend to demand the most attention — particularly around segmentation between corporate IT and operational technology.
Objective C: Detecting Cyber Security Events. Two principles here: security monitoring (C1) and anomaly detection (C2). The CAF expects continuous monitoring with the capability to detect events that could affect essential service delivery. If you are running a SIEM with use cases tuned to your OT environment, you are in reasonable shape. If your monitoring stops at the IT perimeter and your SCADA network is a blind spot, this objective will surface that gap quickly.
Objective D: Minimising the Impact of Cyber Security Incidents. Three principles cover incident response planning (D1), lessons learned (D2), and reporting (D1 also folds in communication requirements). The CAF wants to see that you have tested your incident response plan — not just written one — and that you have a defined process for improving your posture based on incidents and near-misses.
How CAF Assessments Actually Work
The CAF assessment process follows a three-stage cycle that may feel unfamiliar if you are used to the American audit model of point-in-time certification.
Stage 1: Self-Assessment. Your organisation completes a self-assessment against each of the 14 principles and their contributing outcomes. For each outcome, you indicate whether it is "achieved," "partially achieved," or "not achieved," and you provide supporting evidence. This is the spreadsheet your London headquarters sent you. The self-assessment is not a checkbox exercise. Assessors expect narrative evidence that demonstrates the outcome is real — not aspirational.
Stage 2: Sector Regulator Review. In the UK, the relevant sector regulator (Ofwat for water, Ofgem for energy, and so on) reviews the self-assessment, may request additional evidence, and may conduct interviews or site visits. For US subsidiaries, this review is typically handled by the parent company's group security function, which aggregates subsidiary assessments into the group-level submission. Your audience, in practical terms, is the CISO office in London — not a UK regulator directly.
Stage 3: Improvement Plan. Based on gaps identified in the self-assessment and review, the organisation produces a prioritised improvement plan with timelines, owners, and resource estimates. This is where the real work begins. The CAF does not expect perfection on day one. It expects honesty about gaps and a credible plan to close them.
For a Hudson Valley subsidiary, the practical reality is that Stage 1 consumes most of your effort. Get the self-assessment right — with solid evidence and honest gap identification — and Stages 2 and 3 become structured conversations rather than fire drills.
Mapping CAF to NIST CSF: The Rosetta Stone for US Teams
If your team has already invested in NIST CSF alignment, the good news is that the conceptual overlap between the two frameworks is substantial. The bad news is that the overlap is not one-to-one, and the CAF's emphasis on operational technology, essential service continuity, and board-level governance creates pockets where NIST CSF coverage alone will leave you short.
Here is a practical mapping of where CAF objectives align with NIST CSF functions, and where they diverge.
CAF Objective A (Managing Security Risk) maps most closely to the NIST CSF Govern and Identify functions. If you have a risk management program under NIST CSF's GV.RM and ID.RA categories, much of your documentation transfers. The notable gap is CAF Principle A4 — supply chain security — which the CAF treats with more granularity than most US implementations of NIST CSF address. Expect to produce evidence of supply chain risk assessments specific to your OT vendors and service providers.
CAF Objective B (Protecting Against Cyber Attack) aligns with the NIST CSF Protect function. Your access control policies (PR.AA), data security controls (PR.DS), and platform security measures (PR.PS) will cover significant ground. The area where Hudson Valley operations typically need additional work is B5 — resilient networks and systems — particularly around demonstrating that the loss of a single system or network path does not compromise essential service delivery. UK assessors think in terms of service resilience, not just data protection.
CAF Objective C (Detecting Events) maps to the NIST CSF Detect function. If you have a security monitoring capability under DE.CM and anomaly detection under DE.AE, you are well-positioned. The CAF, however, places specific emphasis on monitoring that extends into operational technology environments — not just corporate IT. For a water treatment facility running SCADA systems or a manufacturer with networked industrial controls, this means demonstrating visibility into OT network traffic, not just firewall logs at the IT perimeter.
CAF Objective D (Minimising Impact) aligns with the NIST CSF Respond and Recover functions. Your incident response plan (RS.MA), communication procedures (RS.CO), and recovery planning (RC.RP) will transfer. The CAF adds emphasis on lessons learned being fed back into the risk management process — a closed-loop improvement cycle that some US organisations treat as optional.
Building the Evidence Pack
The evidence pack is where the self-assessment moves from theory to substance. Your London headquarters will expect documentation that maps to each CAF objective and principle. The table below provides a starting framework for organising that evidence.
| CAF Objective & Principle | Evidence Required | Typical US Source Document | Common Gaps for US Subsidiaries |
|---|---|---|---|
| A1: Governance | Board-level accountability for cyber risk; named responsible person; documented governance structure | Information Security Policy; Board/executive committee meeting minutes; RACI matrix | US subsidiaries often lack a named individual accountable at board level specifically for OT cyber risk — the CAF expects this explicitly |
| A2: Risk Management | Risk register covering essential services; risk assessment methodology; evidence of regular review cycles | Enterprise risk register; NIST CSF risk assessment output; risk treatment plans | Risk registers may not distinguish between IT risks and risks to essential service delivery — the CAF requires this separation |
| A3: Asset Management | Complete inventory of systems supporting essential services, including OT assets; dependency mapping | CMDB exports; OT asset inventory; network diagrams | OT asset inventories are frequently incomplete or outdated; dependency mapping between IT and OT systems is often missing |
| A4: Supply Chain | Supply chain risk assessment; third-party security requirements; monitoring of critical suppliers | Vendor risk assessments; procurement security requirements; third-party audit reports (SOC 2, etc.) | Supply chain assessments rarely extend to OT-specific vendors (PLC manufacturers, SCADA integrators, telemetry providers) |
| B1: Service Protection Policies | Policies governing the security of systems supporting essential services | Information Security Policy suite; Acceptable Use Policy; OT-specific security policies | Policies may not explicitly reference essential service protection or OT environments |
| B2: Identity & Access Management | Access control for essential service systems; privileged access management; authentication mechanisms | IAM policy; PAM tool configurations; MFA deployment records; access review logs | Shared credentials in OT environments; lack of MFA on engineering workstations; infrequent access reviews for SCADA accounts |
| B3: Data Security | Protection of data critical to essential service delivery; data-at-rest and data-in-transit controls | Data classification policy; encryption standards; DLP configuration | Operational data (sensor readings, control commands) may not be classified or protected to the same standard as corporate data |
| B4: System Security | Secure configuration; vulnerability management; patch management for essential service systems | Hardening standards; vulnerability scan reports; patch management records | OT systems often run legacy operating systems that cannot be patched on standard cycles; compensating controls need documentation |
| B5: Resilient Networks & Systems | Network segmentation; redundancy; resilience testing for essential service delivery | Network architecture diagrams; segmentation validation test results; business continuity plans | Flat networks between IT and OT; resilience testing that covers IT failover but not OT process continuity |
| C1: Security Monitoring | Continuous monitoring of networks and systems supporting essential services; log collection and analysis | SIEM deployment documentation; log source inventory; monitoring use cases; SOC procedures | Monitoring coverage stops at the IT/OT boundary; OT network traffic is not ingested into the SIEM |
| C2: Anomaly Detection | Capability to detect anomalous activity that could affect essential service delivery | Anomaly detection tool configuration; baseline documentation; alert tuning records | No baseline established for normal OT network behaviour; anomaly detection limited to IT-side indicators |
| D1: Response & Recovery Planning | Incident response plan covering essential services; tested recovery procedures; communication plans | Incident response plan; tabletop exercise reports; disaster recovery runbooks | IR plans may not include OT-specific scenarios; tabletop exercises rarely simulate loss of industrial control systems |
| D2: Lessons Learned | Post-incident review process; evidence of improvements implemented from past incidents or exercises | Post-incident reports; corrective action tracking; policy revision history | Lessons learned from exercises are documented but not tracked through to implementation; no closed-loop evidence |
What US Subsidiaries Typically Struggle With
Having worked with organisations in the Hudson Valley that face this exact scenario, several patterns emerge consistently. Understanding these before you begin the self-assessment will save weeks of rework.
The "Essential Service" Framing
American cybersecurity programs tend to frame risk in terms of data confidentiality and business continuity. The CAF frames everything through the lens of essential service delivery. For a water treatment plant in Ulster County, the essential service is safe drinking water delivered to homes. Every CAF principle asks you to evaluate your security posture in terms of its impact on that service. This is a subtle but important shift. Your risk register needs to articulate risks not as "data breach" or "ransomware" but as "disruption to water treatment processes" or "loss of SCADA visibility leading to inability to monitor chemical dosing." The language matters because it is what UK assessors are trained to look for.
OT Visibility Gaps
Most US operations that have invested in cybersecurity have done so on the IT side. Firewalls, endpoint detection, SIEM, identity management — these tend to be mature. The OT environment is another story. Many Hudson Valley facilities still operate with limited visibility into their industrial control networks. The CAF will surface this gap under Principles C1 and C2, and the honest answer for many subsidiaries is "partially achieved" with an improvement plan to extend monitoring into OT. That honesty is acceptable. Claiming full achievement when your Modbus traffic is unmonitored is not.
Board-Level Governance for a Subsidiary
Principle A1 expects named, board-level accountability for the security of essential services. For a US subsidiary, "the board" may be a local leadership team that reports into a UK group structure. The CAF does not require a multinational governance overhaul, but it does require clarity about who, by name and role, is accountable for cybersecurity at the subsidiary level, and how that accountability connects to the group-level governance structure. A simple governance diagram showing the reporting line from your local IT/OT security lead through the subsidiary executive team to the UK group CISO typically satisfies this requirement.
Supply Chain Depth for OT
Principle A4 asks about supply chain risk management, and US subsidiaries frequently discover that their third-party risk program covers SaaS vendors and cloud providers but ignores the integrator who maintains their PLCs, the vendor who supplies firmware updates for their RTUs, or the telemetry provider whose cellular modems connect field devices to the control centre. For a Hudson Valley utility, these OT supply chain relationships often represent more direct risk to essential service delivery than any cloud application. The CAF expects you to have assessed them.
Evidence Format and Terminology
This one is purely practical but causes more friction than it should. UK assessors expect evidence presented in CAF terminology — objectives, principles, contributing outcomes. If you submit a NIST CSF control matrix without a mapping layer, the group security team in London has to do the translation themselves, which introduces delay and often triggers follow-up questions. Build the mapping document up front. Use a simple two-column format: CAF contributing outcome on the left, your corresponding control and evidence reference on the right. This single artefact will smooth the entire review process.
An Implementation Approach That Works
Based on what works in practice for Hudson Valley organisations facing their first CAF cycle, here is a sequence that keeps the effort manageable.
Weeks 1 through 2: Scope and inventory. Define which systems, networks, and processes support the essential service your parent company has identified. Build or update your OT asset inventory. Create a dependency map showing how IT systems, OT systems, and third-party services connect to deliver that service. This scoping exercise is the foundation for everything that follows, and skipping it is the single most common mistake.
Weeks 3 through 4: Gap assessment and NIST-to-CAF mapping. Walk through each of the 14 CAF principles and their contributing outcomes. For each one, identify which existing NIST CSF controls address the outcome, document where you have evidence, and flag gaps honestly. Produce the mapping document described above.
Weeks 5 through 6: Evidence collection. Gather the documentation, configuration exports, test results, and policy references that support each "achieved" or "partially achieved" rating. Organise them by CAF objective and principle. Do not underestimate the time this takes — chasing down OT network diagrams and SCADA access review records is rarely quick.
Weeks 7 through 8: Self-assessment completion and improvement plan. Complete the self-assessment template with ratings and evidence references. For every "partially achieved" or "not achieved" outcome, draft an improvement action with an owner, target date, and resource estimate. The improvement plan is not a failure report — it is the part of the submission that demonstrates maturity and self-awareness.
Weeks 9 through 10: Internal review and submission. Review the completed self-assessment with your local leadership team to ensure they understand and support the ratings and improvement commitments. Then submit to your parent company's group security function. Build in a buffer for questions and clarifications — the first cycle always generates more back-and-forth than expected.
Making It Sustainable Beyond the First Cycle
The first CAF self-assessment is always the hardest. You are building the mapping, collecting evidence for the first time, and learning a new framework's vocabulary. But the CAF is not a one-time exercise. UK regulators expect ongoing assessment, and your parent company will ask for annual updates at minimum.
The organisations that handle subsequent cycles well are the ones that integrate CAF evidence collection into their existing operations. Quarterly access reviews already produce evidence for Principle B2. Monthly vulnerability scan reports feed Principle B4. Tabletop exercises generate evidence for Principle D1. If you design your evidence pack with reusability in mind — organising by CAF principle but sourcing from your normal operational outputs — the annual refresh becomes a collection exercise rather than a reconstruction project.
For Hudson Valley operations that sit at the intersection of American regulatory expectations and UK parent company mandates, the CAF does not have to be a burden. Approached correctly, it strengthens the parts of your security program that most US frameworks underemphasise: OT visibility, essential service resilience, and supply chain depth. Those are improvements worth making regardless of which flag flies over your headquarters.