Penetration Testing for NHS Compliance: Complete Guide

NHS organisations and digital health suppliers work with highly sensitive patient data and systems that support day-to-day clinical care. Because of this, penetration testing is an important part of NHS compliance and technical security assurance.

The requirement is not the same across every NHS setting. In some cases, testing is part of formal assurance. In others, it becomes relevant when a supplier is being assessed, or a product is being introduced into an NHS environment.

The main challenge is knowing what needs testing, who should carry it out, what evidence NHS reviewers may expect, and when further testing is necessary. This guide explains how to approach those requirements with the right evidence for DSPT, DTAC, procurement, and NHS onboarding.

Why Penetration Testing Is Mandatory for NHS Compliance

Penetration testing is required in some NHS assurance, procurement, integration, and product assessment processes because security claims need to be backed by evidence. The exact requirement depends on your organisation and the NHS route you are following.

For NHS compliance, policies and security controls on paper are not always enough. Testing helps show whether a real weakness could be used to access systems, patient data, user accounts, or connected services.

This is also why a vulnerability scan alone is not treated as the same thing as a penetration test.

Core NHS Compliance Frameworks Requiring Penetration Testing

NHS cyber assurance uses several connected frameworks. DSPT, DTAC, CAF, Cyber Essentials, and penetration testing each serve a different purpose.

Data Security and Protection Toolkit (DSPT)

The Data Security and Protection Toolkit is used by organisations with access to NHS patient data or systems to show how they manage information security and data protection.

For DSPT compliance 2026 to 2027:

• The current toolkit is Version 9
• Version 9 evidence materials were published on 8 September 2026
• Evidence requirements vary by organisation category
• NHS Trusts, ICBs, CSUs, relevant OES providers, and genomics organisations follow the CAF-aligned model

Older NHS guidance that refers to Standard 9 can still help with penetration testing practice, but it should not be treated as the full Version 9 evidence model.

Important change in V9: Compliance is no longer considered a point-in-time exercise.The NHS is now looking for evidence of ongoing vulnerability management, active risk logging, and re-testing throughout the 2026-2027 cycle so that they can track remediation on an ongoing basis each year, rather than just once a year.

Digital Technology Assessment Criteria (DTAC)

DTAC sets the baseline requirements for digital health technologies entering the NHS and social care. It covers:

• Clinical safety
• Data protection
• Technical assurance
• Interoperability
• Usability and accessibility

For NHS DTAC compliance, penetration testing falls within technical assurance. The evidence should cover the product being offered to the NHS, not simply a general security certificate held by the supplier.

Testing should reflect the parts of the product that attackers could target, such as its web application, APIs, mobile application, authentication, administration functions, cloud components, and other external services.

DTAC Section C3 Refinement: According to DTAC Section C3.3, penetration testing reports are rigorously assessed in terms of freshness and methodology. The team should sign the Remediation Action Plan, and the evidence should also include a penetration test report that is less than 12 months old, explicitly mapped against the OWASP Top 10 framework and scored with standard CVSS ratings.

Cyber Assessment Framework (CAF)

The Cyber Assessment Framework is broader than penetration testing. It assesses whether organisations can:

• Manage cyber risk
• Protect against cyber attacks
• Detect security events
• Reduce the impact of incidents

Penetration testing can contribute evidence by revealing weak segmentation, exposed services, privileged access issues, attack paths, and risks linked to supplier-connected systems.

CAF also requires organisations to consider supply chain risk where third-party systems or services support essential functions.

Test findings should therefore feed into risk management and remediation. A report has limited value if weaknesses are recorded but not tracked, fixed, and checked again.

Cyber Essentials & Cyber Essentials Plus

Cyber Essentials focuses on five baseline technical controls designed to protect organisations from common cyber attacks. It covers the same controls but adds independent technical testing to check that they are working as intended.

It is not the same as penetration testing.

• Cyber Essentials checks baseline controls.
• Cyber Essentials Plus adds independent technical verification.
• Penetration testing examines whether weaknesses can be exploited within an agreed scope.

For NHS suppliers, one form of assurance may not satisfy every procurement requirement. PPN 014 requires NHS bodies to apply proportionate cyber security controls to relevant contracts. Depending on the risk, suppliers may need Cyber Essentials, Cyber Essentials Plus, or other security measures.

The Mandate for Certified Security Testing (CREST)

The Legal Mandate 

There is no UK law that says every NHS penetration test must use a CREST accredited provider. The requirement depends on the NHS programme, contract, integration route, or buyer involved.

IM1 is a clear example. Before go-live, suppliers must complete penetration testing through a third party CHECK or CREST-accredited organisation. NHS England also requires this testing annually afterwards.

Other NHS routes may set their own requirements through DSPT evidence, DTAC assessments, procurement terms, integration specifications, or individual Trust conditions. Some buyers may also make accredited testing a contractual requirement.

For suppliers, the safest approach is to check the exact security wording for the NHS route you are entering rather than assuming the same CREST requirement applies everywhere.

Procurement Standard Refinement: CHECK or CREST accreditation will be considered mandatory in technical evaluation in the following procurement frameworks (Procurement Policy Note 014) and primary care integration frameworks (GP IT Futures, IM1, or NHS England API integrations).

Qualysec Advantage

When an NHS route requires accredited testing, choosing a provider with the right credentials becomes part of meeting that requirement. Qualysec is a CREST-accredited penetration testing provider, giving NHS organisations and digital health suppliers independent assurance around testing quality and technical capability.

Its testing process includes:

• Scope definition
• Information gathering
• Manual exploitation
• Reporting
• Remediation testing

The Danger of Unaccredited Testing

If an NHS programme requires CHECK or CREST accreditation, using a provider without that accreditation can cause problems during procurement or onboarding. The issue is not that every unaccredited tester lacks skill. The problem is that the resulting evidence may not meet the stated requirement.

Weak testing evidence can also fail because:

• The scope does not match the NHS-facing product
• Automated scanning is presented as penetration testing
• Exploitation evidence is missing
• The methodology is unclear
• Findings cannot be reproduced
• Remediation is not retested
• Tester competence is unclear
• The report is too old

Where accreditation is specified, verify the provider before commissioning the test.

Quality Assurance

A strong NHS penetration test should leave a clear trail of how the work was carried out. Procurement and security teams should expect:

• A documented methodology
• Qualified testers
• Agreed rules of engagement
• Secure evidence handling
• Technical peer review
• A clear severity model
• Practical remediation advice
• Retesting after fixes

The report may be reviewed by technical, compliance, procurement, information governance, or risk teams. It should therefore make the scope, findings, evidence, and remediation status easy to understand.

Key Scope Areas for an NHS-Focused Penetration Test

The scope should match the systems that support the service being assessed. A generic NHS testing package may miss parts of the real attack surface.

Infrastructure & Network Testing

External testing may include:

• Public IP addresses
• Firewalls
• VPN gateways
• Remote access services
• Administrative interfaces
• DNS services
• Authentication gateways
• Internet-facing servers

Internal testing may cover:

• Active Directory
• Privilege escalation
• Credential exposure
• Segmentation weaknesses
• Service accounts
• Lateral movement
• Trust relationships
• Legacy services

The allowed level of exploitation should be agreed before testing begins, especially where clinical or operational systems share infrastructure.

Third-party managed systems should only be included when the organisation has permission and the contractual right to test them.

Web & Mobile Application Testing

Web application testing should cover the parts of the product where users, data, and permissions meet. Common areas include:

• Authentication and session handling
• Authorisation and broken access control
• Injection flaws and cross-site scripting
• Insecure file uploads
• Data leakage
• Privilege boundaries
• Business logic weaknesses

API testing is especially important for digital health products that connect with NHS services. NHS England requires appropriate penetration testing for many API integrations before deployment.

For mobile apps, testing should also cover local storage, certificate validation, API communication, deep links, reverse engineering exposure, and platform-specific access controls.

Cloud Security Assessments

For suppliers using AWS, Azure, or GCP, cloud testing may cover:

• IAM permissions
• Excessive privileges
• Exposed storage
• Security groups
• Public workloads
• Secrets
• Cloud APIs
• Containers
• Serverless services
• Network segmentation
• CI/CD exposure

A cloud security review checks configuration and access controls. Penetration testing checks whether weaknesses in cloud-hosted applications or infrastructure can be exploited.

Before testing, confirm the cloud provider’s rules and the customer’s responsibilities under the shared responsibility model.

Social Engineering

Social engineering is not a standard requirement for every NHS penetration test. It should only be included when the threat model, contract, assurance activity, or red team objective calls for it.

Testing may cover:

• Phishing simulations
• Credential harvesting simulations
• Pretexting
• Help desk manipulation
• Physical access attempts

Written authorisation is essential before testing begins. NHS England’s simulated phishing service also requires organisations to obtain the right level of approval before they run a campaign.

Any exercise that involves staff or physical access must be planned carefully so it does not disrupt patient care, emergency procedures, or live clinical services.

Step-by-Step Approach to NHS Security Control Testing

1. Scoping Without Disruption

Start by identifying the systems that support the NHS-facing service and deciding what can be tested safely.

Document:

• Systems included and excluded
• Test accounts
• Production or staging environments
• Third-party dependencies
• Sensitive data
• Business critical functions

The Rules of Engagement should define the testing window, source IPs, prohibited techniques, exploitation limits, emergency contacts, stop procedure, and incident escalation.

Clinical environments need tighter safeguards because testing must not affect essential services. Relevant owners from security, infrastructure, applications, service desk, clinical systems, and suppliers should be involved.

2. Threat Modeling

Before exploitation begins, map how an attacker could realistically reach the service.

Focus on:

• Internet-facing entry points
• User and privileged roles
• APIs
• Trust boundaries
• Third-party connections
• Clinical data flows
• Administrative systems

The highest priority scenarios are those that could expose patient data, alter clinical information, disrupt service availability, enable privileged access, or affect continuity of care.

A clear threat model helps direct testing toward the systems that matter most instead of spending time on low-impact assets while critical attack paths remain unchecked.

3. Rigorous Technical Testing

A penetration test should combine automated discovery with manual testing. Automated tools can help find possible weaknesses, but a tester still needs to confirm whether those weaknesses can actually be exploited.

Depending on the scope, testing may cover:

• Authentication and authorisation
• Privilege escalation
• Lateral movement
• Application logic
• APIs and session security
• Cloud permissions
• Data exposure

Confirmed findings should include evidence of what testers tested and how they reproduced the issue.

Business logic flaws also need manual attention because they can involve misuse of legitimate application functions rather than a known technical vulnerability. Any disruptive technique should stay within the agreed Rules of Engagement.

4. Rapid Remediation Guidance

Rank the findings by technical severity and by the effect they could have on NHS services.

Each issue should record:

• The affected asset
• What the vulnerability is
• What an attacker would need to exploit it
• Supporting evidence
• Likely impact
• Recommended fix
• Responsible owner

First, we should address critical and high severity issues.

5. Thorough Re-Testing

A closed ticket is not enough. The tester should repeat the original attack and check whether the weakness can still be exploited. For compliance NHS reviews, this gives clear proof that the fix worked. The retest result should be added to the evidence pack with the final status of the issue.

Want a Sample Security Testing Report?

See how our experts document vulnerabilities, risk severity, and clear remediation steps.

Download Sample Report →

What an NHS Approved Evidence Pack Looks Like

There is no single NHS-approved penetration testing report format that applies to every route. A strong security assurance pack should provide reviewers enough evidence to confirm what they tested and whether they properly handled the findings.

Scope details are especially important. Reviewers should be able to tell whether the NHS facing product and its relevant infrastructure were actually covered.

For a specific procurement or integration route, retain any additional evidence needed to prove that you met its scope, recency, and provider requirements.

Common Pitfalls: Why Healthcare Security Controls Fail Assessments

NHS compliance security can reject or question evidence for a few recurring reasons:

• A vulnerability scan is submitted as a penetration test: Scanning can flag possible weaknesses, but it does not show whether someone can actually exploit them.
  
• The report is too old: A major release, new login flow, cloud move, or fresh integration can make earlier results unreliable.
• The scope is too limited: Testing only the public website may leave out APIs, mobile apps, admin areas, cloud services, or internal systems.
  
• Third party systems are unclear: Suppliers or managed services need to agree on responsibility for testing.
  
• Serious findings stay open: Unresolved critical or high severity issues weaken the evidence.
• Fixes are not retested: A ticket marked complete does not confirm that the weakness has gone.
• Production testing is poorly controlled: Healthcare systems need clear limits, contacts, exclusions, and stop procedures.
• Other certifications are treated as substitutes: ISO 27001 or Cyber Essentials does not replace penetration testing when a specific test is required.
  
• Old DSPT guidance is used as the current rule: The relevant organisation type should come first with the 2026 to 2027 Version 9 evidence.
  
• CREST is assumed to be mandatory everywhere: Some NHS routes require CHECK or CREST, while others depend on the contract or assurance route.
  

How Qualysec Supports NHS Penetration Testing and Audit Readiness

Qualysec is a specialised penetration testing company and a CREST-accredited provider. This makes it suitable for NHS suppliers and organisations that need accredited testing for a contract or integration route.

Security testing can be scoped around the actual NHS environment, including:

• Web applications
• APIs
• Mobile applications
• External networks
• Cloud infrastructure
• IoT and connected systems

Reports can include confirmed findings, technical evidence, severity ratings, reproduction steps, and remediation guidance. Retesting can then confirm whether identified issues have been resolved.

This can help teams prepare technical evidence for NHS procurement, DTAC requirements, DSPT assurance, or specific integration checks.

Before commissioning a test, speak with Qualysec about the exact NHS contract or onboarding requirement so the scope matches what the buyer expects.

Conclusion

For NHS compliance security assurance, the biggest mistake is treating penetration testing as a routine annual task without checking what the organisation or supplier actually needs to prove.

The test should match the system under review and the NHS route involved. Where accredited third-party testing is required, the provider must meet that condition.

It is better to confirm scope, timing, and accreditation before testing begins than to discover during procurement that the evidence cannot be accepted. A well-planned engagement gives security teams something they can actually use during review, remediation, and future assurance work.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

 

FAQS

1. Does the NHS require penetration testing?

Not for every organisation in the same way. The requirement depends on the service being assessed and the NHS assurance route involved. Penetration testing may require procurement, technical assurance, integration, or other security requirements.

2. How often should NHS systems undergo penetration testing?

There is no single timetable for every NHS system. Some routes use an annual cycle. A fresh test may also be needed after a major technical change that could affect security, such as a new integration or significant infrastructure update.

3. What does an NHS penetration test include?

That depends on what is being assessed. The scope could include web applications, APIs, mobile apps, networks, cloud services, or connected devices. Testers may also examine access controls, business logic, privilege escalation, segmentation, and data exposure.

4. What security standards and frameworks apply to NHS penetration testing?

Several may apply, including DSPT, CAF, DTAC, and Cyber Essentials. Procurement terms or integration rules can add further requirements. These frameworks are not interchangeable because each one looks at a different part of security assurance.

5. What should an NHS penetration testing report contain?

A useful report should make it clear what the tester tested and what the tester found. It should include the scope, dates, methodology, evidence, severity, impact, remediation advice, and retest status. Accreditation details should appear where the NHS route requires them.

6. How can penetration testing help healthcare organisations prepare for NHS compliance audits?

It can uncover technical weaknesses before they become an audit issue. Teams can then fix those problems and keep evidence showing what changed. That supports audit readiness, but the test on its own does not prove full NHS compliance.