The NHS Data Security and Protection Toolkit, done honestly

Most organisations that complete the NHS Data Security and Protection Toolkit do it twice: once properly, and once the way it usually gets done, which is a scramble in the weeks before the deadline to find words that justify answers somebody has already decided. The Toolkit rewards the first approach and quietly punishes the second, because an assertion with no evidence behind it holds up perfectly well until the moment it matters, and then it does not hold up at all. This is a guide to what the DSPT actually asks of you, what honest completion involves, and the legal and operational duties that sit alongside it and are not discharged by submitting.

What the Toolkit is, and what it is not

The DSPT is an online annual self-assessment, published through NHS England, in which an organisation sets out how it meets national data security and protection standards. The long-standing assertion-based version is built around the National Data Guardian's ten data security standards, covering people, process and technology: leadership and responsibility, staff training, access control, data handling, incident response, business continuity, supplier assurance and the rest. You answer against each assertion, record the evidence behind your answer, and submit. Your resulting status is visible to the NHS bodies that commission or contract with you, which is why it functions in practice as a trading document.

Two things the DSPT is not. It is not a certification: nobody audits your estate as a condition of submission in the way a certification body does, and for most organisation categories there is no certificate at the end. And it is not a substitute for the law. UK GDPR, the Data Protection Act 2018 and the common-law duty of confidentiality apply to you whether or not you have ever opened the Toolkit. The DSPT is the mechanism by which the health system asks you to show your working.

That gap is where organisations get into trouble. A submission that says "standards met" creates a record, and a record that turns out to be unsupported is worse than no record at all. If an incident follows, the ICO, your commissioner and quite possibly your insurer will all read your most recent submission against what the incident revealed. An honest "not met, here is the plan" has never been the thing that caused the problem.

Who has to complete it, including suppliers

The expectation is broad. It covers organisations with access to NHS patient data or NHS systems, and that reaches a long way past NHS trusts: independent and private healthcare providers, clinical services businesses, primary care contractors, social care providers, pharmacies, charities delivering care, and the software, hosting, analytics, transcription, logistics and IT suppliers who hold or process NHS patient data under contract. If patient data touches your systems, the question is not whether the DSPT is relevant but which organisation category you submit under.

For suppliers the requirement usually arrives contractually rather than from a regulator. Completion of the Toolkit is written into NHS standard contract conditions and into integrated care board and trust procurement requirements, and it is Department of Health and Social Care policy that bodies processing NHS patient information provide assurance through the DSPT. So the practical answer to "do we have to?" is normally found in your own contract, in its data security, information governance and data processing clauses, and confirmed with the commissioner who will be looking at your status.

Two details catch suppliers out. The first is scope: if you are a processor rather than a controller, you still have to secure what you hold, and your customer's assurance obligations do not travel without you. The second is the shape of the question. A trust or an ICB is not asking whether you are a good company. It is asking whether it can evidence, to its own assessors, that the data it is accountable for is safe in your hands. Your submission is part of its evidence pack as well as yours. Our view of the wider sector picture sits on the healthcare sector page.

The direction of travel: alignment with the Cyber Assessment Framework

The Toolkit has been moving towards a model aligned with the NCSC Cyber Assessment Framework. Rather than a flat list of assertions, a CAF-aligned assessment is organised around the framework's objectives and principles, with contributing outcomes you have to demonstrate: managing security risk, protecting against attack, detecting events, minimising the impact of incidents, and the governance and assurance that holds it together. Alongside that, NHS England has been strengthening the assurance arrangements around submissions, including independent assessment for some organisation categories.

Treat this as direction of travel rather than a fixed state. Which categories are CAF-aligned, which version of the Toolkit and of the CAF is in force, what the interim and final submission points are, and where independent assessment applies have all changed between cycles and differ by organisation type. Check the current position on the DSPT website and in NHS England's own guidance before you plan a cycle, and ask your commissioner which category they expect you to submit under. Do not plan this year's work from last year's blog post, including this one.

What is stable is the underlying shift, and it is worth understanding even if your category has not moved yet. A CAF-style assessment asks what outcome you achieve, not what control you have bought. "We have endpoint protection" answers nothing; "we can detect and respond to malicious activity across the clinical estate, here is the coverage, here is the detection source, here is what happened the last three times something fired" answers the question. That is a higher evidential bar, and it is a reasonable one. It is also, usefully, the same bar your customers' due-diligence teams have been moving towards independently.

What honest completion involves

The mechanics are not difficult. The discipline is.

Honest completion means that for every answer, there is something a third party could inspect and reach the same conclusion you did. In practice that is a small, boring library:

• •Dated policies that people have actually seen. A data protection and information security policy set, with a review date that has not passed, and a record of who has read it.
• •Training completion, not training availability. The report that shows which staff, including locums, bank and agency workers, completed data security training and when.
• •Named access reviews. Evidence that someone reviewed who has access to patient data, found leavers and over-privileged accounts, and removed them, with dates.
• •A real asset and data picture. What systems hold patient data, who the supplier is, where it sits, and under what contract.
• •Patch and vulnerability evidence. What was outstanding, for how long, and what you did about the things you cannot patch.
• •Restore test results. Not the backup job's green tick, but the outcome of an actual restore, with the time it took.
• •Incident records. Including the small ones, and what changed as a result.
• •Supplier assurance records. The DSPT status, certification or security evidence you hold for each supplier who touches patient data.

The common failure mode is narrow and predictable: an assertion with nothing behind it. It is rarely dishonest in intent. Someone answers for how the organisation is supposed to work, in good faith, because the policy says so and nobody has checked. The policy requires annual access reviews, so the answer is yes, and the last review was eighteen months ago. Training is mandatory, so the answer is yes, and the agency staff who cover nights were never enrolled. Backups run nightly, so recovery is assured, and nobody has restored anything since the system was installed.

The fix is to invert the order of work. Gather the evidence first, then answer. Where the evidence does not support the answer you wanted, record the gap and attach an improvement plan with an owner, a date and the money behind it. An unmet standard with a credible plan is a defensible, grown-up position. A met standard with nothing behind it is a liability you have signed.

The legal layer the Toolkit sits on

Health data is special-category personal data. Processing it needs a lawful basis under Article 6 of UK GDPR and a separate condition under Article 9, with the additional conditions set out in the Data Protection Act 2018 where they apply. That means the usual obligations carry extra weight here: data protection impact assessments for higher-risk processing, data minimisation that is genuinely enforced rather than aspirational, retention schedules that someone applies, records of processing that match reality, and processor contracts with the required terms. Our UK GDPR page sets out how we approach that work.

Then there is the obligation people forget. The common-law duty of confidentiality is separate from data protection law and is not discharged by satisfying it. Information a patient provides in confidence may generally only be used for purposes they would reasonably expect, unless there is consent, a statutory basis, or an overriding public interest. You can be entirely correct on your Article 9 condition and still be in breach of confidence. This matters most at the edges of a business: secondary use of data for service improvement or research, sharing with a partner organisation, analytics performed by a supplier, a case study, a demonstration environment populated with real records. If a new use of patient data is being proposed, the confidentiality question needs asking explicitly and answering in writing, not folded into the data protection assessment and assumed to be covered.

The 72-hour clock

Where a personal data breach is likely to result in a risk to people's rights and freedoms, UK GDPR requires notification to the ICO without undue delay and, where feasible, not later than 72 hours after you become aware of it. Where the risk to individuals is high, you also have to inform the affected people without undue delay. Health and care organisations with a DSPT account can report through the Toolkit's own incident reporting tool, which routes the notification to the ICO and, depending on the answers given, to other national bodies. The route is a convenience. The duty, and the clock, are yours.

Three things decide whether 72 hours is comfortable or impossible, and all three are decided before anything happens. The first is detection: the clock starts when you become aware, so an organisation that finds out from a patient has already lost most of its window. The second is the ability to establish scope quickly, which depends on logging and on knowing where patient data lives. The third is a decision-making structure, so that the judgement about whether the threshold is met is made by a named person with authority, out of hours, on a Saturday, rather than debated by email for two days. Rehearse the first few hours specifically, including the notification decision. It is the part of incident response most often left to improvisation and the part with a statutory deadline attached.

Ransomware in a clinical setting is a patient-safety issue

Information governance work tends to frame risk as confidentiality: who saw what. In a clinical setting the sharper risk is availability. If clinicians cannot reach records, results, prescribing or scheduling, the consequence is cancelled appointments, slower diagnostic turnaround, and clinical decisions taken with less information than normal. That is a patient-safety consequence, and it happens whether or not a single record leaves the building.

Which changes what continuity planning has to cover. The honest questions are operational, not technical:

• •Can the service run on paper, and for how long? Not in principle. Are the forms available offline and printed, do current staff know the process, and at what point does degraded working become unsafe?
• •What is the clinical priority order for recovery? Which systems come back first, decided by clinical impact with clinical input, agreed in advance and written down.
• •How is the paper record reconciled afterwards? Recovery is not the end. Everything recorded during the outage has to get back into the record accurately, and that work is substantial and frequently unplanned.
• •How do you communicate when the systems you would use are down? To staff, to patients with appointments, to commissioners, and to partner organisations who depend on you.
• •When did you last prove the restore? With a result and a measured duration, not an assumption.
• •What does your supplier owe you, and when? If the system is hosted, your recovery time is their contractual commitment, and you should know what it is before you need it.

The controls underneath this are ordinary and well understood: multi-factor authentication, prompt patching of anything exposed, isolated and immutable backups, segmentation so a foothold in the office estate cannot reach clinical systems, hardened endpoint protection, and monitoring that would actually notice. Our ransomware readiness checklist works through them in sequence. What makes the clinical version harder is the equipment: medical devices and clinical systems that cannot be patched on an IT schedule or taken offline during a working day. The answer there is architecture and monitoring around the device rather than an agent on it, and 24×7 managed detection and response across the estate so that something unusual on an unpatched segment is seen the same night.

Supplier assurance flows downhill

The DSPT asks you to assure your own suppliers, and NHS and ICB contracts push requirements down the chain. So a company supplying the NHS is usually standing in two places at once: answering its customer's assurance requirements, and imposing equivalent requirements on its own subcontractors. Both halves have to be real.

The upstream half is contractual reading. Know what your agreement actually commits you to: DSPT submission and category, Cyber Essentials or Cyber Essentials Plus, ISO 27001 where it is specified, incident notification timeframes to your customer that may be considerably shorter than 72 hours, audit and inspection rights, data location restrictions, and sub-processor approval. Incident notification clauses are the ones that most often surprise people after the fact.

The downstream half is a register and a routine. For every supplier who holds or can reach patient data: what they hold, what their current assurance position is, when it was last checked, what their notification obligation to you is, and whether they can subcontract. The recurring problem is the long tail, the small suppliers nobody classified as critical, the archiving company, the transcription service, the analytics tool somebody connected to the patient administration system two years ago. Those are the ones with no evidence on file, and the ones a serious assessment finds.

Where certification is the right answer to a contractual requirement, it is delivered through certified assessment partners, with us coordinating the work, holding the evidence and remaining your single point of accountability for the outcome. The same applies to independent assessment of a DSPT submission where your category requires it: the assessor is independent by design, and your job, which we do with you, is to make sure what they inspect is true.

Making it a position rather than an annual event

The reason the DSPT gets done badly is structural, not cultural. An annual submission invites annual effort, and an organisation that assembles its evidence in May is describing a controls environment it no longer has by September. Access drifts, staff change, suppliers get added, a system gets replaced, the patch backlog grows. The submission ages out immediately, and the next cycle starts from the same cold floor.

The alternative is to run the evidence continuously, which is also what the CAF-aligned direction of travel assumes. Access reviews on a calendar with an owner. Training completion checked monthly, including bank and agency staff. Restore tests scheduled and recorded. Supplier assurance refreshed as contracts renew rather than when the Toolkit asks. Incidents logged however small. Done that way, submission is a reporting exercise against evidence that already exists, and the much more common requests, a commissioner's questionnaire, a new contract's security annexe, an insurer at renewal, are answerable in an afternoon.

That is the model behind continuous compliance, and it is the most useful thing to take from this: the DSPT is not the goal. Being able to show, at any point in the year and to anyone who asks, that patient data is safe with you and that care continues when systems do not, is the goal. The Toolkit is one view of it. If you want to know where you currently stand, the compliance readiness self-assessment is a fifteen-minute starting point, and if you would rather talk it through with a senior advisor who has done this with NHS suppliers before, book a call.