Senior responsible owners (SROs) and non‑executive directors must stop accepting cyber statements and start accepting tests. The NCSC’s Cyber Assessment Framework v4.0 (CAF) is deliberately outcome‑focused: it says what resilience should look like, not how a programme proves it. That creates a delivery problem for boards and SROs: how do you convert CAF outcomes into the gates, evidence and supplier obligations that must be passed before you approve transition, go‑live or contract acceptance? This briefing shows exactly how to do that, the artefacts leaders should expect, and the conditional decisions that reduce operational and regulatory risk while preserving benefits.
The decision at stake
Boards frequently face three binary decisions presented as simple approvals: (a) approve the programme to move from design to build; (b) approve go‑live; (c) accept the supplier deliverable and hand over to operations. Each decision is about appetite for residual cyber risk and the accompanying evidence. The right question for leaders is not “are we secure?” but “have the programme and suppliers demonstrated, by testable evidence, that the residual cyber risks meet the board’s tolerance and the CAF outcomes mapped to critical operational functions?”
If leaders approve on narrative rather than evidence they accept hidden failure modes: unclear supplier responsibilities, incomplete dependency mapping, unverifiable controls, and fragile recovery plans. Those failure modes are the primary cause of post‑live outages, regulatory scrutiny and insurance disputes.
Why this conversion problem appears in programmes
NCSC CAF v4.0 sets outcomes (for example, reduce impact, detect and respond, maintain essential functions) rather than prescriptive controls. Delivery teams respond with controls‑lists, but those lists rarely align to the programme lifecycle, supplier boundaries, or the board’s need for pass/fail evidence.
Three common delivery failures repeat: (1) evidence fragmentation — security reviews, supplier attestations and test logs live in different artefacts so no single decision pack shows the end‑to‑end test result; (2) undefined failure modes — tests are run but do not exercise real dependencies such as third‑party integrations or data‑access pathways; (3) contractual ambiguity — exit, reversibility and supplier‑run recovery tasks are poorly defined and untested, leaving operational teams to negotiate during incidents.
A practical mapping: CAF outcomes to delivery gates
Start by mapping the CAF outcomes to three delivery gates aligned to standard lifecycle events leaders already recognise: Design‑to‑Build (D→B), Pre‑Go‑Live Operational Acceptance (OGA), and Post‑Acceptance Stabilisation (PAS). For each gate, define the pass/fail test, the evidence artefact, and the owner.
Example mapping (high level): - CAF outcome: Reduce likelihood of successful compromise → Gate: D→B → Test: Threat model signed off and SCA results remediated to agreed SLA; Evidence: threat‑model document, SCA report, remediation log; Owner: technical lead + security SME. - CAF outcome: Detect and contain attacks quickly → Gate: OGA → Test: Run a full playbook exercise (tabletop + live injected telemetry) demonstrating detection, escalation and containment within RTO/RPO targets; Evidence: exercise report, incident‑runbook, monitoring dashboards with historical test telemetry; Owner: ops lead + SOC. - CAF outcome: Maintain essential functions under supplier failure → Gate: PAS → Test: Simulated supplier outage (subcontractor or cloud region) with failover to standby service, data integrity verification and business continuity check; Evidence: failover runbook, data checksums, runbook timings, supplier post‑test attestation; Owner: service transition lead.
This mapping forces programmes to think in testable behaviours rather than lists of controls.
Concrete artefacts and the single evidence pack
Leaders should require a single evidence pack for each gate that contains the minimal, verifiable items needed to make a conditional decision. Antares recommends the following standardised artefacts per gate (examples): - Traceability matrix linking CAF outcomes → requirement → test case → test result. - Threat model and attack surface register with outstanding risk register items and mitigations. - Static and dynamic code/artifact scan results, with critical/high remediation evidence or compensating controls documented. - End‑to‑end integration test runs for all external interfaces with data flow diagrams and data‑integrity checks. - Supplier exit/reversibility test results (see later section) and contractual evidence for the exact responsibilities exercised during the test. - Operational runbooks, monitoring dashboards and a runbook rehearsal report demonstrating people and process readiness.
Present these artefacts as a one‑page gate scoreboard (pass/fail for each CAF outcome), then attach the supporting documents. Boards can digest the scoreboard; assurance teams can inspect the attachments.
Supplier and contractual levers: what to require and test
Translate supplier obligations into testable contract clauses and measurable performance tests. Key levers to include and test during OGA and PAS are: - Exit and reversibility: defined replication points, data export formats, transfer automation and a live back‑transfer test demonstrating data integrity and service continuity within a mutually agreed window. - Subcontractor transparency: lists of sub‑suppliers and explicit rights to audit or demand evidence for the CAF outcomes they affect. - Incident participation: mandatory supplier participation in runbook rehearsals (with costs and penalties for non‑participation) and explicit responsibilities for containment, forensics and remediation timescales. - Retention of forensic logs and access to telemetry for a minimum defined period to support investigations and regulator requests.
Crucially, the contract must permit the customer to require and witness the exact tests used as gate checks — not just receive a supplier attestation after a test.
Dependencies, failure modes and realistic testing
Programmes routinely test components in isolation. Leaders must insist on testing realistic failure modes that reflect operational reality: supplier region loss, denial of access to a data store because of a procurement or legal block, degraded network capacity, or concurrent supplier outages. Each major dependency needs a dependency test with a clear owner and rollback criteria.
Failure modes to include in the evidence pack: incomplete data exports, inability to re‑route traffic to an alternate supplier within contractual SLAs, absence of necessary credentials for failover, monitoring blind spots, and poorly defined escalation between suppliers and the customer. The evidence pack must show which failure modes were exercised, the test outcomes and corrective actions.
Decision gates and conditional approvals
Treat approvals as conditional, not binary. Example board decision language for OGA: “Approve go‑live conditional on (a) critical CAF outcomes marked as Green on the gate scoreboard, (b) no more than two Amber medium risks with a time‑bound mitigation plan and named owners, and (c) a successful supplier reversibility test within the last 30 days.”
If the evidence pack shows Amber or Red results for outcomes affecting essential services, the board should require a mitigated, time‑bound re‑test and delay full acceptance until the re‑test passes. For services that are not essential, the board may accept a limited residual risk with compensating business controls and a follow‑on remediation plan tightly governed by the SRO.
Who owns what: roles and accountability
Make responsibilities explicit. The SRO owns the decision package; the technical lead owns threat modelling and remediation; the service transition lead owns operations readiness and runbooks; the commercial lead owns contractual tests and supplier obligations; the security SME owns CAF mapping and acceptance criteria. Integrate these owners into the gate sign‑off: each artefact must have a named owner and a date of sign‑off.
Assurance teams (internal or third‑party) must be able to independently verify a sample of test artefacts before the gate meeting; for very high‑risk services, require an NCSC‑assured or accredited assessor to provide comfort.
Practical failure modes and what to do next
If a gate fails: do not default to “accept and monitor”. Instead, require a remediation sprint with a clear owner, a fixed scope limited to the failed outcome, and a re‑test window. If suppliers cannot perform the re‑test, the programme should have an executable fallback: temporary operational controls, manual workarounds with defined monitoring, or a staged go‑live that isolates the unvalidated capability from essential services.
Treat each remedial action as a mini‑project with visible funding, scope and deliverables. This prevents slow, ungoverned remediation that becomes years of tech debt.
Measuring success and moving to business as usual
The final gate should not merely pass control to BAU; it should hand over a sustained assurance plan: automated monitoring rules that map to CAF outcomes, supplier KPIs tied to telemetry, and quarterly evidence reviews until the service stabilises. Boards should receive a 6‑month post‑acceptance assurance summary showing incidents, near‑misses exercised in subsequent tests, and any supplier compliance issues.
This moves cyber from a one‑off procurement control to an ongoing operational discipline embedded in service management.
Boards should approve evidence, not narratives: demand a single gate scoreboard that maps CAF outcomes to pass/fail tests, and refuse to sign unless the evidence demonstrates the service will meet essential function resilience under realistic failure modes.
Antares recommended actions
These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.
- Build a CAF→gate traceability matrix before procurement closes: map each CAF outcome to specific requirements, tests and contractual clauses and include this matrix in the pre‑procurement evaluation.
- Require a single evidence pack per gate; present it as a one‑page scoreboard plus attachments. Boards should see only the scoreboard, while assurance teams retain access to the attachments.
- Contract for testability: include explicit exit/reversibility tests, supplier participation in runbook rehearsals, and rights to audit subcontractors; make the tests part of contractual acceptance criteria.
- Design and run at least two realistic dependency tests (including at least one supplier‑failure scenario) before OGA; remediate and re‑test any Amber/Red outcomes before board approval.
- Make approvals conditional: allow go‑live only when all CAF outcomes affecting essential services are Green or covered by time‑bound mitigations with named owners and a re‑test date.
- Define ownership clearly: SRO owns decision; technical lead owns threats & remediation; service transition lead owns operational acceptance; commercial lead owns contractual tests; assurance team verifies the pack.
- Embed post‑acceptance assurance into BAU: automated monitoring mapped to CAF outcomes, supplier telemetry KPIs and quarterly evidence reviews for six months post‑acceptance.
Our insights are provided for general information only and reflect the position at the date of publication. They do not constitute legal, financial, regulatory, cybersecurity or other advice tailored to your circumstances and should not be relied upon as a substitute for appropriate professional advice.
While we take reasonable care over our content, we do not guarantee that it is complete, accurate or current. Reading our insights does not create a client relationship with Antares Consultancy. To the fullest extent permitted by law, we accept no liability for decisions made or losses arising from reliance on this content. External links are provided for convenience and do not imply endorsement.
