NHS-compliant software is not defined by a single framework. It requires satisfying several overlapping assurance regimes that address different aspects of how a system handles data, manages risk, and demonstrates clinical safety. Understanding what each regime requires, and how they interact, is a prerequisite for building software that will pass assessment without repeated remediation cycles.
Healthcare software compliance is routinely treated as a checklist to be completed before go-live rather than a design constraint to be satisfied throughout development. The consequences are predictable. Programmes reach the assurance stage having made architectural decisions that are difficult to reverse, carrying data flows that were never mapped, and lacking the audit infrastructure assessors will expect. Retrofitting compliance onto a system that was not built for it is significantly more expensive than building it in, and in a clinical context the risks extend beyond cost.
What Compliance Actually Requires
The starting point is recognising that compliance in healthcare is not a point-in-time achievement. DTAC compliance, DSPT submission, and GDPR obligations are all ongoing. A system that passes assessment at launch can fall out of compliance through a configuration change, a new data flow, or a shift in the regulatory environment that was not tracked. Governance frameworks exist to make compliance maintainable over time, not just achievable at a single moment.
That requires three things from the outset: a data map that accounts for every personal and sensitive data flow the system touches, an audit infrastructure that produces evidence without manual intervention, and a risk management process embedded in the development lifecycle rather than run separately from it. Programmes that treat these as documentation exercises tend to produce frameworks that look complete on paper but do not reflect how the system behaves. NHS-compliant software demands that these foundations are real, not theoretical.
DTAC Compliance and the Digital Technology Assessment Criteria
DTAC is the NHS England framework that health and care organisations use to assess digital technologies before procurement or deployment. It covers clinical safety, data protection, technical security, interoperability, and usability, and requires suppliers to provide evidence across all five domains rather than self-certifying against a subset.
The clinical safety component is where many suppliers underestimate the work. DCB0129 requires a clinical safety case supported by a hazard log, a clinical risk management plan, and a named Clinical Safety Officer. The hazard log needs to reflect actual system behaviour, which means the people writing it need to understand how the software makes decisions and what happens when inputs are missing, malformed, or contradictory.
The data protection component maps closely to GDPR and requires a Data Protection Impact Assessment for any processing likely to result in high risk to individuals. In a healthcare context, processing of special category data under Article 9 is the norm, which means the DPIA is not optional and the lawful basis for processing must be established and documented for every data flow the system touches.
DSPT Support and the Data Security and Protection Toolkit
The DSPT is the self-assessment framework NHS organisations use to demonstrate they meet the National Data Guardian’s data security standards. The controls an organisation can assert depend partly on how the software they procure is designed and configured.
Access control, audit logging, encryption at rest and in transit, and data retention and deletion capabilities are all areas where software design directly affects what an NHS organisation can claim in its DSPT submission. A system that does not produce tamper-evident audit logs, or that does not support role-based access control at sufficient granularity, creates gaps in the assurance position that cannot be closed by policy alone. NHS-compliant software supports the organisation’s DSPT obligations rather than creating exceptions to them.
Why NHS-Compliant Software Must Be Built In From the Start
The programmes that navigate assurance most efficiently treat compliance as an architecture concern from the first sprint: defining the data model with GDPR obligations in mind, instrumenting audit logging as a core infrastructure component, integrating clinical safety review into the development process, and maintaining the hazard log as a live document rather than a one-time deliverable.
DTAC assessment, DSPT alignment, DCB0129 clinical safety, and GDPR compliance are related but distinct, and satisfying one does not automatically satisfy the others. A governance framework that maps the requirements of each regime against the system’s actual behaviour, and tracks compliance continuously rather than at assessment points, is what makes NHS-compliant software maintainable over its operational lifetime.
Our Expertise
We provide Fractional CTO and advisory services that embed compliance and governance into healthcare software programmes from the outset. That covers DTAC compliance preparation across all five domains, DSPT support for NHS organisations and their suppliers, GDPR obligations including DPIA production and lawful basis mapping, DCB0129 clinical safety case development, and the technical architecture decisions that make those frameworks maintainable rather than theoretical.
See It in Practice
A UK healthcare services provider needed to modernise the integration layer around a long-established NAV-based ERP without disrupting live clinical operations. Compliance was not a post-delivery concern: the programme required DSPT-aligned access controls, tamper-evident audit trails, and clinical safety assurance from the first release.
The architecture we delivered addressed governance requirements at every layer. Microsoft Entra ID enforced least-privilege access across all services. Key Vault managed secrets without exposing them to application code. Azure Monitor and Application Insights produced immutable, correlated audit records across all service boundaries, providing the evidence base that both operational teams and compliance reviewers needed. Every data flow was documented, every access decision was logged, and the system was designed to support the organisation’s DSPT submission rather than create exceptions to it.
Read the full case study → Legacy Healthcare ERP Integration on Microsoft Azure
