The DSPT for a small organisation: where the evidence already is, and where people get stuck

Background

The Data Security and Protection Toolkit is how an organisation that handles NHS patient data shows it looks after that data. For a big trust it's a programme of work with a team behind it. For an independent clinic, a dental or physio practice, a care provider or a small supplier to the NHS, it's usually one person doing it alongside their real job, with a deadline in June.

I'm Head of IT for a healthcare group with seventy-plus clinics, and the DSPT is mine. What follows is the approach I'd take for a small organisation, written for the person who's been handed it.

Two things to know before you start:

• Not everyone gets the same toolkit. Since the 2024-25 cycle, NHS trusts, ICBs, commissioning support units, arm's length bodies, genomics organisations and Operators of Essential Services complete a version aligned to the NCSC's Cyber Assessment Framework. Smaller organisations keep a more prescriptive, controls-based version. Your organisation type, set when you register, decides which one you see.
• The toolkit's own wording is the source of truth. Read each item as written for your organisation type. Guides (this one included) can't know exactly which items your type is shown this year.

Setup

Find the evidence you already have

Most small organisations have more evidence than they think. It's just scattered: a policy in a shared drive, a training report in an HR system, an invoice that proves a backup service exists.

Before answering anything, make one folder and fill it with what exists:

• Policies: data protection, information security, acceptable use, records retention, business continuity.
• Registers: who has access to what, devices, the systems and suppliers that hold patient data, where each one stores it.
• Records: training completions, the last time a backup was restored, the last time someone's access was removed when they left.
• Contracts: the data processing terms with each supplier that touches patient data.

Then go through the toolkit item by item and point each one at a file. The items with nothing to point at are your real work list.

A prompt that helps with the policy part. Remove names, patient details and anything confidential first, or use an AI tool your organisation has approved for this kind of document.

Below is one of our policies, with names removed.
For each requirement in it, list:
- the requirement, quoted
- the evidence that would prove we follow it in practice
  (a record, a report, a screenshot, a log)
- who in a small organisation would normally hold that evidence
Do not invent requirements that aren't in the text. If a section is
too vague to evidence, say so and quote it.

[PASTE POLICY]

It won't tell you whether you comply. It gives you a list of what to go and find.

Registers you'll keep using

Two registers carry a lot of the toolkit, and both get easier if they're kept all year instead of rebuilt in May:

• An information asset register. Each system or store of personal data, what's in it, who owns it, where it's hosted and who the supplier is.
• A register of sites and what's at them. Devices, network kit, contracts and the checks done at each location. With more than one site, this is where gaps hide.

A spreadsheet is fine for both, as long as someone owns it. If you run several sites, Estate, a premises register I'm building (in beta), keeps each site's contracts, assets, documents, audits and compliance records attached to the site itself.

The technical items people get stuck on

These come up in some form for nearly everyone, and they take the longest because they need doing, not just writing down.

• Multi-factor authentication. NHS England made MFA its first directive national policy for the toolkit. Turn it on for email and every system that holds patient data, and keep a short exception register for anything that can't use it, with the reason and what you do instead. More on choosing MFA that holds up in MFA that actually stops something.
• Backups you've restored. A backup nobody has restored is a hope. Do a test restore of something real, write down the date, what you restored and how long it took. That note is the evidence.
• Unsupported software. Any device or system past its end-of-support date needs replacing, isolating or explaining with a plan and a date. Make the list before you're asked.
• Patching. Show that updates are applied, and how quickly critical ones go on. A screenshot of a device management report beats a sentence saying "we patch regularly".
• Training figures. Data security training for staff, with a record of who completed it and when. The figure needs to be provable on the day you submit, so chase completions early. I'm building Learning Platform for exactly this kind of "prove who completed what" (it's in progress, not ready yet).
• Leavers. Access removed on the day someone leaves, with a record. If that's manual today, it's worth automating; the JML guide shows one way to do it in Microsoft 365.

Cyber Essentials alongside it

Cyber Essentials and the DSPT ask about a lot of the same controls: MFA, patching, supported software, firewalls, admin accounts. Doing both in the same year means one set of fixes. I took the group I work for through Cyber Essentials Plus, and the overlap is the main reason I'd plan them together.

Submitting on time

The deadline for the 2025-26 toolkit was 30 June 2026, and it's been the end of June for several years. Check the current cycle's date on the toolkit itself, then work back from it:

• Three months out: evidence folder built, gaps listed with owners.
• Six weeks out: technical fixes done, training chased.
• Two weeks out: every item answered, someone else reads it through.