What NHS Software Compliance Actually Means
The Data Security and Protection Toolkit (DSPT)
What the DSPT Is
DSPT Compliance Levels
What Developers Need to Evidence
Annual Submission Cycle
DCB Standards: Clinical Safety for Software
DCB0129 and DCB0160 Explained
What DCB0129 Requires
Common Hazards Developers Overlook
Who Needs a Clinical Safety Officer
Integrating Compliance Into the Development Lifecycle
Shift Compliance Left
Architecture Decisions That Matter for Compliance
Managing Third-Party Dependencies
NHS App and API Integration Requirements
Common Compliance Failures and How to Avoid Them
Legacy Systems and Compliance Debt
Working With NHS Procurement and Due Diligence
How WireApps Supports Health Tech Scale-Ups
FAQs
Where to Start
Building software for the NHS is not like building software for any other sector. NHS software compliance sits at the intersection of patient safety, data protection law, and clinical governance — and getting it wrong carries consequences that go well beyond a failed audit. This guide covers the two frameworks developers encounter most often: the Data Security and Protection Toolkit (DSPT) and the DCB standards published by NHS England. Whether you are building a new digital health product or modernising an existing clinical system, understanding these requirements before you write a line of code will save you significant rework later.
What NHS Software Compliance Actually Means
"NHS software compliance" covers a broad set of obligations. At its core, it means demonstrating that your software handles patient data securely, meets clinical safety standards, and operates within the governance frameworks the NHS requires of its technology suppliers and partners.
There are three layers to this:
Data security and information governance — primarily governed by the DSPT
Clinical safety — governed by DCB0129 (for manufacturers) and DCB0160 (for deploying organisations)
Integration and interoperability — governed by NHS England's API standards, HL7 FHIR R4 requirements, and the NHS login / NHS App ecosystem rules
Most developers focus on the first two. The third becomes relevant when your product needs to connect to Spine, GP Connect, or the NHS App. All three can apply simultaneously to the same product.
The Data Security and Protection Toolkit (DSPT)
What the DSPT Is
The DSPT is an online self-assessment tool managed by NHS England. It measures whether organisations that access NHS patient data are meeting the National Data Guardian's ten data security standards. Any organisation that processes NHS patient data — including software suppliers with access to that data — must complete a DSPT submission annually.
The ten standards cover:
People: ensuring staff understand their data security responsibilities
Process: having clear policies and documented procedures
Technology: securing systems, devices, and networks that hold or process patient data
For software developers, the technology standards are the most directly relevant. These include requirements around access control, audit logging, encryption at rest and in transit, patch management, and business continuity.
DSPT Compliance Levels
Submissions are assessed against one of three statuses:
Standards Not Met — the organisation has not completed the assessment or has failed mandatory assertions
Standards Met — all mandatory assertions have been completed and evidenced
Standards Exceeded (formerly "Approaching Standards") — the organisation has gone beyond mandatory requirements
NHS commissioners and NHS Digital integrations typically require "Standards Met" as a minimum condition of contract. Some NHS trust procurement teams will not progress a supplier evaluation if the DSPT status is not current.
What Developers Need to Evidence
The DSPT is not purely a policy exercise. Several assertions require technical evidence, including:
Multi-factor authentication on systems holding patient data
Encryption of data at rest (AES-256 is the accepted standard) and in transit (TLS 1.2 minimum, TLS 1.3 preferred)
Audit trails recording who accessed what data and when, retained for a minimum period
Penetration testing by a CREST-accredited or equivalent provider, with documented remediation of findings
A documented business continuity and disaster recovery plan with tested recovery time objectives
Data processing agreements with all sub-processors, including cloud infrastructure providers
If your product runs on AWS, Azure, or GCP, you need to document that your specific cloud configuration meets these requirements — not simply that the cloud provider itself holds certifications. The DSPT assesses your configuration, not the underlying platform.
Annual Submission Cycle
DSPT submissions run on a financial year cycle, with the deadline typically falling in late June. Organisations that miss the deadline or submit with "Standards Not Met" status risk losing their NHS data sharing agreements. For software suppliers, that can mean losing access to test environments or being removed from NHS procurement frameworks entirely.
Build your compliance calendar to allow at least six to eight weeks for evidence gathering, internal review, and remediation of any gaps before the submission deadline.
DCB Standards: Clinical Safety for Software
DCB0129 and DCB0160 Explained
DCB standards are clinical safety standards published by NHS England under the direction of the Chief Clinical Information Officer. Two standards apply directly to software.
DCB0129 applies to manufacturers of health IT systems. If you are building software that will be used in clinical settings — anything from a patient-facing app to a clinical decision support tool to an electronic patient record module — DCB0129 requires you to demonstrate that you have a clinical safety management system and that you have assessed and mitigated the clinical risks your software introduces.
DCB0160 applies to deploying organisations — NHS trusts, GP practices, integrated care boards — that implement health IT systems. It requires the deploying organisation to assess the clinical risks of deploying a specific system in their specific context.
As a software developer or supplier, DCB0129 is your primary obligation. DCB0160 is your customer's obligation, but your documentation feeds directly into their process.
What DCB0129 Requires
DCB0129 compliance involves three core deliverables.
1. Clinical Safety Management System (CSMS)
A documented set of policies, processes, and responsibilities for managing clinical safety throughout your product's lifecycle. This covers how you identify, assess, and mitigate clinical hazards, how you handle safety-related incidents, and how you manage changes to the software that could introduce new risks.
2. Clinical Hazard Log
A structured log of every clinical hazard your software could introduce or contribute to. Each hazard must be assessed for likelihood and severity, with mitigations documented and evidenced. The hazard log is a living document — it must be updated with each significant release.
3. Clinical Safety Case Report
A formal report, signed off by a Clinical Safety Officer (CSO), that summarises the hazard assessment and argues that the residual risk from your software is acceptable. The CSO must be a qualified clinician registered with a UK professional body.
Common Hazards Developers Overlook
Clinical hazard identification is where many development teams struggle. The most commonly missed hazards include:
Incorrect data display — showing a value in the wrong unit (mg vs mcg, for example) or without sufficient context
Timeout and session handling — a session that expires mid-workflow could leave a clinician acting on stale data
Notification failures — an alert that fails silently rather than surfacing an error state
Data migration errors — incorrect mapping of legacy data during a system migration that corrupts clinical records
Interoperability mismatches — receiving a FHIR resource with an unexpected code system and defaulting to a null or incorrect value
The standard does not expect zero risk. It expects that you have identified the risks, assessed them honestly, and put mitigations in place that reduce residual risk to an acceptable level.
Who Needs a Clinical Safety Officer
Your CSO must be a registered clinician — a doctor, nurse, pharmacist, or other regulated health professional — with training in clinical risk management. For most software companies, this means either hiring a part-time CSO or engaging a specialist clinical safety consultancy.
The CSO does not need to be an employee. Many health tech scale-ups use fractional or consulting CSOs, particularly in the early stages of product development. What matters is that the CSO has genuine clinical knowledge relevant to your product domain and the authority and independence to raise safety concerns.
Integrating Compliance Into the Development Lifecycle
Shift Compliance Left
The most expensive way to achieve NHS software compliance is to build your product first and then attempt to retrofit the documentation. Clinical hazard logs, audit logging, encryption, and access control are architectural decisions. Make them late and you are not just writing documentation — you are doing rework.
The practical approach is to treat DSPT and DCB requirements as acceptance criteria alongside functional requirements. Before a feature goes into a sprint, ask: does this feature handle patient data? Does it introduce a new clinical workflow? If yes, the hazard assessment and the technical controls are part of the definition of done.
Architecture Decisions That Matter for Compliance
Several architectural choices have a direct bearing on your compliance posture.
Audit logging needs to be designed at the data layer, not bolted on at the application layer. Every access to patient-identifiable data should generate an immutable audit record with a timestamp, user identity, and the action taken. Centralised log management — a SIEM or equivalent — is increasingly expected by NHS trust security teams.
Role-based access control (RBAC) must be granular enough to enforce the principle of least privilege. Clinicians should only see data relevant to their patients and their role. Administrators should not have read access to clinical records unless their role requires it.
Data residency matters. NHS contracts typically require patient data to remain within the UK or the EEA. If your infrastructure uses a US-based cloud region or a CDN that caches data outside these boundaries, you have a compliance gap.
Penetration testing should be scheduled into your release cycle, not treated as a one-time event. The DSPT requires evidence of regular testing. Annual testing is the minimum; for products handling sensitive clinical data, quarterly or per-major-release testing is a more defensible position.
Managing Third-Party Dependencies
Your compliance obligations extend to your supply chain. If you use a third-party analytics SDK, a customer support platform, or a cloud-based AI service that processes patient data, you need a data processing agreement with that provider and you need to assess whether their security posture meets DSPT requirements.
This is particularly relevant for teams integrating AI capabilities into clinical workflows. An AI model that processes patient data — even transiently, for inference — is a data processor under UK GDPR and must be assessed accordingly. The clinical safety implications of AI-generated outputs also need to be addressed in your hazard log.
For a detailed look at how AI agent integration intersects with engineering governance, this practical guide for engineering teams covers the architectural and process considerations worth reviewing before you build.
NHS App and API Integration Requirements
If your product integrates with NHS login, the NHS App, or NHS England APIs, there is an additional layer of technical compliance beyond DSPT and DCB.
NHS login requires your application to complete a conformance assessment, which includes a security review, a data minimisation assessment, and testing against the NHS login integration environment. The level of assurance required — P5, P9, or P12 — depends on the sensitivity of the data your product accesses.
NHS England's FHIR APIs require conformance to specific implementation guides, which define the resource profiles, search parameters, and interaction patterns your system must support. Conformance is tested against NHS England's Spine integration environments before production access is granted.
These integration requirements sit alongside DSPT and DCB compliance — not instead of them. A product can be DSPT-compliant and DCB0129-compliant and still fail the NHS login conformance assessment if the integration implementation is incorrect.
Common Compliance Failures and How to Avoid Them
The following failures appear repeatedly in NHS supplier audits and trust procurement evaluations.
Outdated DSPT submission. The submission lapses because no one owns the renewal process. Assign a named owner, set calendar reminders, and treat the DSPT renewal as a product milestone.
Hazard log written once and never updated. DCB0129 requires the hazard log to reflect the current state of the product. A log written at initial release and untouched through subsequent versions is non-compliant.
Encryption in transit not enforced. TLS is configured but not enforced — HTTP connections are still accepted. A straightforward fix, but it appears regularly in penetration test findings.
No documented data retention and deletion policy. NHS contracts specify retention periods for patient data. No automated deletion process and no documented policy means a compliance gap.
Sub-processor agreements missing. Cloud infrastructure, logging services, error tracking tools, and email providers that touch patient data all need DPAs. Many teams have agreements with their primary cloud provider but have missed secondary services.
Clinical Safety Officer not engaged until late. The CSO signs off the Clinical Safety Case Report. Bring them in after the hazard log has been written and the product has been built, and they are reviewing a fait accompli rather than genuinely assessing risk. Engage the CSO during design, not at sign-off.
Legacy Systems and Compliance Debt
Many NHS software suppliers are not building greenfield products. They are maintaining systems built years before DSPT and DCB standards existed in their current form, trying to bring those systems into compliance while continuing to support live clinical users.
This is one of the harder compliance challenges in health tech. The approach that works is phased: assess the current state honestly, prioritise the highest-risk gaps — clinical safety and data security before documentation gaps — and build a remediation roadmap with clear milestones.
A structured modernisation approach can help here. The 12-week legacy modernisation framework outlines how to sequence technical debt reduction without disrupting live operations — a pattern that applies directly to compliance remediation in clinical systems.
The worst outcome is discovering compliance gaps during a trust procurement evaluation or, worse, during an incident investigation. The second worst is knowing the gaps exist and having no plan to close them.
Working With NHS Procurement and Due Diligence
NHS procurement teams are more technically sophisticated than they were five years ago. Procurement evaluations for clinical software now routinely include:
DSPT status verification, checked directly against the NHS Digital portal
Request for the Clinical Safety Case Report and Hazard Log
Evidence of penetration testing with a CREST-accredited provider
Data processing agreements and sub-processor lists
Business continuity documentation with tested RTOs
Prepare these documents as a compliance pack that can be shared quickly. Delays in providing documentation are read as gaps in compliance readiness, even when the underlying product is sound.
If your product is being evaluated for a framework agreement — G-Cloud, NHS Shared Business Services, or a trust-specific framework — the compliance documentation requirements are typically specified in the invitation to tender. Read them before you respond, not after.
How WireApps Supports Health Tech Scale-Ups
Building a compliant NHS product requires both technical depth and governance discipline. The architecture decisions that underpin DSPT compliance — audit logging, RBAC, encryption, infrastructure as code — are engineering decisions, not policy decisions. The clinical safety process requires someone who understands what the software actually does, not just what the documentation says it does.
We work with health tech scale-ups at the point where these two worlds collide: when the product is live, the commercial opportunity is real, and compliance requirements are blocking the next stage of growth. Our healthcare software compliance work covers how we approach this in practice.
Whether you need a Fractional CTO to own the technical compliance strategy, an engineering pod to implement the required controls, or a QA team to run the evidence gathering for a DSPT submission, the engagement structures at wireapps.co.uk are built to fit the specific stage you are at.
FAQs
What is the DSPT and who needs to complete it?
The Data Security and Protection Toolkit is an annual self-assessment managed by NHS England. Any organisation that accesses NHS patient data — including software suppliers with access to that data — must complete a submission each year. The assessment measures compliance with the National Data Guardian's ten data security standards across people, processes, and technology.
What is the difference between DCB0129 and DCB0160?
DCB0129 applies to manufacturers and developers of health IT systems. It requires you to maintain a clinical safety management system, a hazard log, and a clinical safety case report signed by a qualified Clinical Safety Officer. DCB0160 applies to NHS organisations that deploy health IT systems. As a software supplier, DCB0129 is your direct obligation; DCB0160 is your customer's, though your documentation feeds directly into their process.
Does my product need to comply with both DSPT and DCB standards?
In most cases, yes. DSPT covers data security and information governance. DCB0129 covers clinical safety. If your product handles patient data and is used in a clinical setting, both frameworks apply. They are complementary, not alternatives.
What does a Clinical Safety Officer need to be qualified to do?
A CSO must be a registered clinician — a doctor, nurse, pharmacist, or other regulated health professional — with training in clinical risk management. They do not need to be a full-time employee. Many health tech companies use fractional or consulting CSOs, particularly early in product development.
What encryption standards does the DSPT require?
The DSPT requires encryption of patient data at rest and in transit. AES-256 is the accepted standard for data at rest. TLS 1.2 is the minimum for data in transit, with TLS 1.3 strongly preferred. HTTP connections to systems holding patient data should not be accepted.
How often does penetration testing need to happen for DSPT compliance?
The DSPT requires evidence of regular penetration testing by a qualified provider, with documented remediation of findings. Annual testing is the minimum standard. For products handling sensitive clinical data, testing per major release or quarterly is a more defensible position — particularly during NHS trust procurement evaluations.
What happens if our DSPT submission lapses?
An expired or "Standards Not Met" DSPT status can result in the suspension of NHS data sharing agreements and removal from NHS procurement frameworks. Some NHS trusts will halt supplier evaluations immediately if the DSPT status is not current. Treat the annual renewal as a product milestone with a named owner, not an administrative task.
Where to Start
NHS software compliance is not a one-time exercise. It is an ongoing discipline that runs parallel to product development. The teams that handle it well treat DSPT and DCB requirements as engineering constraints from the start — not governance checkboxes at the end.
If compliance is currently blocking a procurement, an integration, or a funding round, the place to start is an honest assessment of where the gaps are. That assessment needs to cover architecture, documentation, and process simultaneously — because the gaps are rarely in just one of those areas.
Share
