If your pharmacy handles patient data, the Data Security and Protection Toolkit isn't optional. It's a condition of operating within the NHS. But knowing you need to be DSPT-compliant and knowing what that actually means for the software you choose are two very different things.

This post breaks down what DSPT compliance looks like in practice, and what to check before you commit to any pharmacy software platform.

What Is the DSPT and Why Does It Matter?

The Data Security and Protection Toolkit is NHS England's self-assessment framework for organisations that handle NHS patient data. It covers how data is stored, accessed, shared, and protected.

Submitting your DSPT assertion annually isn't just a box-ticking exercise. It demonstrates to your ICB, your patients, and NHS Digital that your organisation takes data security seriously. And increasingly, it's a prerequisite for NHS contracts and integrations.

The software you run in your pharmacy contributes directly to whether you can make those assertions confidently.

What to Look for in Pharmacy Software

1. Encrypted sessions and strict authentication

Your staff authentication should include mandatory two-factor authentication, not optional. Sessions should be time-limited, cookie flags should be set correctly (secure, httponly, same-site), and every login and logout should be recorded in an audit log with IP address and timestamp.

If a vendor can't tell you exactly how sessions work, that's a red flag.

2. Audit logging across all significant actions

DSPT assessments ask whether you can account for who accessed what and when. Your software should be doing that work for you automatically, covering queue operations, user changes, password resets, and feature configuration changes as a minimum.

3. Patient consent at the point of data collection

Any platform that collects patient information, whether through a kiosk or a public web portal, must present a privacy notice before collecting any data. That consent should be recorded, not just displayed. If your current software skips this step, your DSPT submission is on shaky ground.

4. A clear data subject rights workflow

Patients have the right to request their data and the right to erasure. Your software should support both without requiring a manual database intervention every time. Look for built-in subject access request handling and PII redaction tools.

5. Secure device management

If you run kiosk devices, each one should be provisioned individually with its own credentials, not sharing a single login. Devices should be revocable instantly if lost or compromised, and access tokens should expire automatically.

Questions to Ask Any Vendor

Before you commit, ask these directly:

Where exactly is patient data stored, and is that guaranteed in your contract?
Is two-factor authentication mandatory for all staff accounts?
What does your audit log cover, and can I see a sample?
How do you handle a subject access request or erasure request?
Has the platform been used in an NHS-compliant deployment before?

A vendor that hesitates or gives vague answers to any of these isn't ready for an NHS environment.

Compliance Is Not a Feature, It Is the Foundation

It's tempting to evaluate pharmacy software purely on usability and features. Queue management, appointment booking, analytics, all of that matters. But in an NHS setting, a platform that looks great but handles patient data carelessly is a liability, not an asset.

The right software makes your DSPT submission easier, not harder. It should be able to point you to exactly how each relevant assertion is satisfied, because the vendor built it that way from the start.