If you process NHS patient data, you complete the Data Security and Protection Toolkit annually, and your answers are expected to rest on evidence rather than intent. NHS England has been moving the toolkit onto the NCSC’s Cyber Assessment Framework, which shifts the emphasis from ticking statements to demonstrating outcomes. Technical testing is one of the clearest ways to demonstrate several of them.
Who has to complete it
Every organisation with access to NHS patient data or systems, which reaches far beyond trusts. Software suppliers, managed service providers, transcription services, private clinics delivering NHS work and research organisations all fall in scope, usually because a contract requires it. Submissions run on an annual cycle with a published deadline, and the status you achieve is visible to the organisations that buy from you. That visibility is the practical driver: a supplier showing anything other than standards met will be asked about it during procurement. Contracts increasingly name the toolkit directly, which turns the submission into a commercial deadline.
Where testing evidence fits
The framework asks whether you understand your systems, protect them, detect problems and can respond. Penetration testing evidences the protection objective directly for internet-facing services and for applications handling patient data, and vulnerability scanning evidences the ongoing management side. What assessors and buyers look for is dated, specific material: the scope tested, the findings, who fixed them and when, and confirmation that fixes were verified. A report with no remediation record is weaker evidence than a report with findings that were closed.
“Suppliers often ask whether a scan will satisfy the toolkit. It can support the vulnerability management answers and it does not stand in for testing an application that handles patient data. Buyers in this sector have become good at spotting the difference, and being asked to explain it during a tender is a poor time to discover the gap.”
William Fieldhouse, Director, Aardwolf Security Ltd
The gaps that come up most
Three recur across suppliers of every size. An asset register that does not include cloud services bought by individual teams, which makes the understanding objective impossible to answer honestly. Unsupported software still in use with no documented plan, which is a common finding in clinical settings where an application is tied to a device. Testing evidence that has expired, where the last report predates significant changes to the system. None of these are difficult to fix given a few months of notice, and all of them are painful when discovered a fortnight before a submission deadline.
Preparing without a last-minute scramble
Work backwards from the deadline and treat evidence as something you gather all year. Book testing early enough that remediation and a retest fit before submission, which realistically means starting three months ahead. Keep vulnerability scanning and assessmentrunning continuously so the trend data exists rather than being generated in a panic. If your last test predates a significant release, ask for a testing quote now rather than in the final month, since good testers are booked several weeks ahead and the toolkit deadline is the same date for everyone.
Frequently asked questions about the DSPT
These questions come up whenever a supplier faces the toolkit for the first time.
Does the toolkit require an external penetration test?
It expects evidence that your security controls work, and independent testing is the normal way to provide it for systems that face the internet or process patient data. Internal checks alone are usually challenged.
How does it relate to Cyber Essentials?
They overlap and neither replaces the other. Certification gives you a recognised baseline that supports several toolkit answers, while the toolkit asks broader questions about how you handle patient data specifically.
