Where does your CAF evidence actually stand?

Ten contributing outcomes. You are assessed against each one.

A CAF assessment does not ask whether you have security monitoring. It asks, outcome by outcome, what you can show. These are the ten that sit under B4 and C1, in the framework’s own words.

• B4.aSecure by Design
• B4.bSecure Configuration■Exposure work produces evidence for this outcome
• B4.cSecure Management
• B4.dVulnerability Management■Exposure work produces evidence for this outcome
• C1.aSources and Tools for Logging and Monitoring■Exposure work produces evidence for this outcome
• C1.bSecuring Logs
• C1.cGenerating Alerts
• C1.dTriage of Security Alerts■Exposure work produces evidence for this outcome
• C1.ePersonnel Skills for Monitoring Tools and Detection
• C1.fUnderstanding User's and System's Behaviour, and Threat Intelligence■Exposure work produces evidence for this outcome

Marked outcomes are the ones a continuous vulnerability management and exposure programme produces evidence for. That marking is our assessment, not an NCSC mapping.

NCSC Cyber Assessment Framework, Principle B4 System security and Principle C1 Security monitoring. Read at source 22 September 2026.

1. 01

   Can you name the contributing outcomes you are assessed against, or only the principles?

   B4 holds four and C1 holds six. An assessor works outcome by outcome. A programme organised around principles tends to produce evidence that is broadly relevant and specifically unmatched to anything.

2. 02

   For B4.d, can you produce a current list of publicly-known vulnerabilities affecting your essential functions?

   The outcome is written about tracking them continuously, not about having scanned. A list dated last quarter answers a different question from the one being asked.

3. 03

   Can you show how you decided which of those to fix, and why the rest were left?

   Nobody closes everything a scan returns, and the framework does not expect you to. What it expects is that the prioritisation was deliberate and that you can account for it. The decision is the evidence; the scan is only the input.

4. 04

   When did you last test that your understanding of your own vulnerabilities is correct?

   B4.d asks you to test regularly to validate that understanding, which is a separate act from scanning. If the answer is that the tooling has never been checked against reality, that is the gap.

5. 05

   Is there obsolete or unsupported technology in the path of an essential function, and is there a dated plan to replace it?

   B4.d expects you to pursue supported replacements for obsolete platforms. An assessor is generally more interested in whether the plan exists and is moving than in whether the box has already gone.

6. 06

   For B4.b, could you produce the hardened baseline build and the configuration record for a system chosen at random?

   Chosen at random is the test. Consistent application across the estate is the outcome, and an estate where the answer depends on which system was picked is not evidencing it.

7. 07

   For B4.c, are privileged administrative actions performed from separated, highly-trusted devices?

   The outcome is specific about where administration happens, not only about who is authorised to do it. Administering an essential function from a general-purpose laptop is the common finding here.

8. 08

   For C1.a, do your log sources actually cover the systems your essential functions depend on?

   Coverage is usually assumed from the existence of a monitoring tool. The outcome is about whether the data you collect would let you identify events in time, which is a question about what is not being logged.

9. 09

   For C1.b, is log data held securely, with access limited to accounts that have a business need, and a retention period you can state?

   Three separate things, and the retention period is the one most often unstated. If nobody can say how long logs are kept, nobody can say whether an investigation could reach back far enough.

10. 10

    For C1.c and C1.d, does an alert reach a person who contextualises it, or a queue nobody reads?

    C1.c is about alerts being generated reliably. C1.d is about somebody contextualising them against the threat and your own systems. A high-volume alert feed with no triage satisfies neither, and it is visible in the evidence.

11. 11

    For C1.e, do the people doing the monitoring have the skills the framework expects, and can you evidence that?

    This outcome is about people rather than tooling, and it is the one most often left to an assertion. Roles, training and the reasoning behind how the team is shaped are all in scope.

12. 12

    For C1.f, can you say what threats you expect, and what normal looks like on your own network?

    The outcome asks that threats and corresponding user and system behaviour are sufficiently understood. Without a baseline, an anomaly is only an unfamiliar log line, and threat intelligence that is not tied to your own estate is reading rather than understanding.