Does the NCSC CAF Require Penetration Testing? B4.d Explained

Does the NCSC CAF Require Penetration Testing? B4.d Explained

By EJN Labs · 11 Jul 2026 · 9 min read

Short answer: not by name, but in practice you will struggle without it. The NCSC Cyber Assessment Framework (CAF) is an outcome-based framework rather than a checklist, so it does not list “penetration testing” as a hard requirement. What it does expect, under contributing outcome B4.d, is that you regularly test and verify that your security measures actually work. A penetration test is the most credible evidence you can put in front of a CAF assessor to show exactly that. The detail is where teams get caught out.

Where penetration testing sits in the CAF

The CAF is built around four high-level objectives, labelled A to D, covering how you manage security risk, protect against cyber attack, detect security events and minimise the impact of incidents. Each objective breaks down into principles, and each principle into a set of contributing outcomes. Every outcome is assessed against Indicators of Good Practice and scored at an achievement level, so the question an assessor asks is never “did you buy this product” but “can you show this outcome is being achieved”.

Penetration testing lives inside Objective B, “Protecting against cyber attack”. Within that objective sits Principle B4, “System Security”, and within B4 the contributing outcome that matters most here is B4.d, “Vulnerability Management”. This is the outcome that expects you to find, understand and fix weaknesses in your systems, and to keep checking that your defences hold.

The CAF is not a law in its own right. It is the framework the NCSC publishes to underpin several regimes that do carry legal or contractual weight, including the NIS Regulations 2018, the NHS Data Security and Protection Toolkit (DSPT) and GovAssure for central government. If you are being assessed under any of those, you are being assessed against CAF outcomes, and B4.d is one of them.

What outcome B4.d actually expects, in plain English

Strip away the framework language and B4.d asks you to run a working vulnerability management cycle. In practice that means being able to demonstrate the following:

  • You know where your weaknesses are. You maintain awareness of vulnerabilities across your networks, systems, applications and cloud services, rather than assuming they are secure.
  • You assess and prioritise by risk. Findings are triaged so that the issues most likely to lead to compromise of your essential functions are dealt with first.
  • You remediate within sensible timeframes. Patches and mitigations are applied on a schedule that reflects the severity of the issue, not whenever it is convenient.
  • You regularly test and verify. You do not just trust that controls are configured correctly, you check, and you can show the results of that checking over time.

That last point is where penetration testing earns its place. A CAF assessor wants evidence that you have looked at your systems the way an attacker would and confirmed that your controls stand up. It is worth being precise here: the CAF does not mandate a penetration test, and we will not pretend it does. What outcome B4.d expects is that you “regularly test” your security to understand your vulnerabilities, and the NCSC’s own guidance under Principle B4 explicitly points to penetration tests and vulnerability scans as examples of how to do that. An independent penetration test is the clearest, best-recognised way to evidence that expectation.

How often should you test for CAF?

The CAF deliberately avoids setting a fixed calendar. Because it is risk-based, the expectation is that testing is “regular” and proportionate to how much your systems change and how important they are. That flexibility is helpful, but it is also where teams under-test and get marked down.

A defensible rhythm for most organisations is to test at least once a year, and to add a test whenever something material changes. Sensible triggers include:

  • A significant change to your architecture, a new internet-facing service or a major application release.
  • A move to a new cloud platform or a substantial reconfiguration of an existing one.
  • The run-up to a DSPT submission, a GovAssure return or a NIS audit, so your evidence is current.
  • After a security incident, to confirm the root cause is closed and has not opened others.

An assessor looking at B4.d wants to see testing that keeps pace with your systems, not a certificate from three years ago.

Who is allowed to carry out CAF testing?

Any competent tester is allowed to carry out CAF testing. Because the CAF is outcome-based, it names no single accreditation scheme and does not restrict testing to one type of provider, so in principle any capable firm can help you demonstrate B4.d.

The practical bar is competence and independence. The assessor needs confidence that whoever tested your systems had the skills to find real issues, and enough distance from the team that built them to report honestly.

This is where scheme membership matters as evidence rather than as a named requirement. CREST is widely recognised across UK assessment regimes as evidence that a testing provider meets a proven standard of competence and process, which is exactly the assurance a CAF assessor is looking for. EJN Labs provides CREST-accredited penetration testing delivered by UK-based testers, and because we are an independent third party our findings carry the independence that strengthens the highest achievement levels under CAF. Independent third-party testing is not the only way to satisfy B4.d, but it is the way that gives assessors the least to question.

What the test needs to cover

Scope is the second place teams get caught out. Under CAF the guiding idea is your “essential function”, the service that must keep running. Your testing should focus on the systems that support that function, so a defensible CAF-aligned scope typically includes:

  • Internet-facing infrastructure and any perimeter exposed to attackers.
  • Internal networks, to model what an attacker could do once inside.
  • Web applications and APIs that handle sensitive data or underpin the essential function.
  • Cloud environments and their configuration, which is now where many real weaknesses live.

The point is not to test everything you own, it is to test the systems whose compromise would matter, and to be able to explain that reasoning to an assessor. A good testing partner will help you define a scope that maps cleanly to your CAF profile rather than leaving obvious gaps.

What happens when the test finds something

Each finding feeds back into your vulnerability management cycle: you prioritise it by risk, remediate it and then confirm the fix has worked. Under B4.d that response is what matters, because findings are not a failure of the test, they are the point of it.

That final confirmation carries real weight, because an assessor wants to see the loop closed, not just opened.

This is why retesting matters, and it is where EJN Labs keeps things straightforward. Our engagements include free retests of the issues we raise, so once your team has remediated we verify the fixes and update the evidence trail. You end up with a clear before-and-after record: what we found, what you fixed and proof that it is now closed. That record is exactly the kind of artefact a CAF, DSPT or GovAssure assessor wants to see against B4.d.

How EJN Labs delivers CAF-aligned penetration testing

We built our service around what an assessor accepts and what a busy security team can actually run. Every EJN Labs engagement is:

  • Fixed-price and scoped up front, so you know the cost and the boundaries before we start. No open-ended day counting.
  • Delivered on a clear timeline, usually with a report in your hands within days of testing finishing, in good time for your submission.
  • CREST-accredited and UK-based, giving you the independent, competent testing that strengthens your CAF position.
  • Reported the way assessors expect, with risk-rated findings, remediation guidance and evidence you can attach directly to your CAF, DSPT or GovAssure return.
  • Backed by free retests, so the vulnerability management loop under B4.d is demonstrably closed.

If you supply into the NHS, our page on CAF-aligned testing for NHS suppliers walks through how this maps to DSPT expectations. When you are ready, you can get a fixed-price quote in 24 hours and we will help you scope testing that stands up under CAF.

Frequently asked questions

Does the CAF legally require a penetration test?

No. The CAF is an outcome-based framework, not a law, and it does not list penetration testing as a mandatory control. Contributing outcome B4.d does, however, expect you to regularly test and verify your security, which is where penetration testing earns its place.

The NCSC’s own B4 guidance points to penetration tests and vulnerability scans as examples of how to meet that expectation. An independent penetration test is, in our experience, the evidence buyers most readily accept against B4.d, though the CAF names no required method.

Which CAF outcome does penetration testing support?

Penetration testing most directly supports outcome B4.d, “Vulnerability Management”. That outcome sits under Principle B4, “System Security”, within Objective B, “Protecting against cyber attack”, so it is the part of the framework concerned with finding and dealing with weaknesses before an attacker does.

By finding, prioritising and helping you close weaknesses, and by verifying that controls work, a pen test provides evidence across the whole of B4.d and strengthens your wider B4 system security position.

How often do we need to test for CAF?

Test at least annually and again after any significant change. The CAF sets no fixed cadence because it is risk-based, but it expects testing to be regular and proportionate, and an annual test plus change-driven retesting is what that means for most organisations.

Significant changes include a new internet-facing service, a major application release, a cloud migration or a security incident. Aligning a test with your DSPT, GovAssure or NIS cycle keeps your evidence current.

Does the tester need to be CREST-accredited for CAF?

No, the CAF does not name CREST or any single scheme, so accreditation is not a hard rule. What the framework expects is competence and independence, and CREST accreditation is widely recognised across UK assessment regimes as evidence of both, which is why it gives assessors confidence.

EJN Labs is CREST-accredited and independent, with UK-based testers, so our reports carry that assurance.

Does the CAF apply to our organisation?

The CAF applies if you fall under the NIS Regulations 2018 as an operator of essential services or relevant digital provider, use the NHS Data Security and Protection Toolkit, or are a central government body within scope of GovAssure. Those three routes cover most organisations assessed against it.

Many organisations outside those groups also meet CAF outcomes because they supply into these sectors and are asked to demonstrate equivalent assurance to their customers.

What do assessors want to see from a CAF penetration test?

Assessors want independent testing, scoped to the systems that support your essential function, with findings that are risk-rated and prioritised. Above all they want the vulnerability management loop closed, meaning evidence that issues were remediated and then retested to confirm each fix actually worked.

A clear report with a before-and-after remediation trail is exactly what supports outcome B4.d.


Leave a Reply

Your email address will not be published. Required fields are marked *