If you are a UK business building software that touches patient data, HIPAA is not your problem. It is American law and it does not apply here. Almost everything written about healthcare software compliance online is written for the US market, which is why so many UK founders arrive at their first NHS conversation with the wrong homework done.
What applies to you is a different stack: UK GDPR, the NHS Data Security and Protection Toolkit, the Digital Technology Assessment Criteria, and a set of clinical safety standards most people have never heard of until a procurement team asks for them.
This guide explains what actually applies, when each piece kicks in, and how much of it you can safely ignore depending on what your software does.
The first question: who are you selling to?
Your obligations depend far less on what your software does than on who uses it. The same appointment booking system carries completely different requirements depending on whether it sits in an NHS trust, a private clinic, or a physiotherapist's spare room.
Three broad situations:
- You are selling to the NHS. This is the heaviest path. Expect DTAC, DSPT, clinical safety standards and evidence of security testing before anyone signs anything.
- You are selling to private healthcare. No NHS frameworks apply automatically, but UK GDPR still does, and health data is treated as a special category with extra conditions attached.
- You are building something health adjacent with no clinical use. A gym booking app, a wellbeing tracker, a staff rota. UK GDPR applies as it would to any business, and that is usually the end of it.
Get this question answered honestly before you build anything, because the difference between the first and third path is months of work.
UK GDPR and health data
Health data is not ordinary personal data. Under UK GDPR it is special category data, which means you need a lawful basis to process it and a separate additional condition on top.
In practice, for a UK business handling patient information, that translates into a few concrete obligations. You need to document what data you hold and why. You need a Data Protection Impact Assessment for anything high risk, which processing health data at scale usually is. You need a privacy notice that actually describes what happens to the data.
If something goes wrong, you report a personal data breach to the Information Commissioner's Office within 72 hours of becoming aware of it. That is the deadline people underestimate. Seventy two hours includes the weekend, and the clock starts when you become aware, not when you finish investigating.
None of this is optional and none of it depends on the NHS being involved.
DSPT: the NHS data security assessment
The Data Security and Protection Toolkit is an annual self assessment you complete if you handle NHS patient data or connect to NHS systems. You are aiming for a status of Standards Met.
Two things surprise suppliers here. The first is that for IT suppliers an independent audit is required to reach Standards Met, so this is not simply a form you fill in yourself. The second is that existing certifications help but do not replace it. Holding ISO 27001 or Cyber Essentials Plus reduces the scope of what you have to evidence separately, which is worth having, but neither substitutes for the toolkit.
Worth knowing: Cyber Essentials Plus no longer counts as equivalent evidence for the multi factor authentication requirement, so if you were relying on that, you now need to show the control separately.
DTAC: the NHS assurance framework
The Digital Technology Assessment Criteria is the national framework NHS buyers use to assess a digital health product before purchasing it. If you want to sell software into the NHS, you will meet it.
DTAC covers five areas: clinical safety, data protection, technical security, interoperability, and usability and accessibility. It is best understood as a wrapper. It does not invent new requirements so much as collect evidence from frameworks that already exist, which means a supplier with DSPT, Cyber Essentials, a recent penetration test and clinical safety documentation in order is most of the way through it already.
NHS England published version 2 in February 2026 and the previous version stopped being accepted from 6 April 2026. The new form is about a quarter shorter, mainly because questions duplicating DSPT were removed. That sounds like good news, and it partly is, but it also means the remaining questions carry more weight. Vague answers that survived the old form do not survive this one.
One important clarification: DTAC sits alongside other approvals rather than replacing them. Passing it does not exempt you from medical device rules or data protection law.
Clinical safety: the standards nobody expects
If your software could contribute to patient harm, UK clinical risk management standards apply, and they require a named Clinical Safety Officer who is a registered clinician with clinical risk management training.
This is the requirement that stops projects dead, because it cannot be solved by the development team. DCB0129 applies to manufacturers and suppliers building health IT products. DCB0160 applies to the organisation deploying it. You need documentation showing you identified clinical risks, assessed them and mitigated them.
Founders routinely discover this late, usually when a trust asks for a clinical safety case and there is no clinician anywhere near the project. If your product is heading toward clinical use, sort this early.
When your software becomes a medical device
Software crosses into medical device territory based on what it is intended to do, not how complex it is. A simple tool that helps diagnose or make treatment decisions can be regulated. A sophisticated system that only stores and displays records often is not.
If your software is a medical device under UK rules, you need UKCA or CE marking before clinical deployment, and that is a regulatory process with its own timeline. The MHRA is the relevant regulator.
This is genuinely a judgement call and it is one worth getting right early, because retrofitting it is expensive. The current DTAC form includes a decision tree to help suppliers work out whether their product qualifies, which is a reasonable starting point.
What this means for your architecture
The expensive mistake is treating compliance as paperwork you produce after the software is built. Most of these requirements are decisions about how the system works, and they are far cheaper to design in than to retrofit.
The ones that shape the build:
- Access control. Role based permissions and multi factor authentication, with the ability to review and revoke access. This affects your data model, not just your login page.
- Audit logging. A record of who accessed or changed what, and when, stored so that it cannot be quietly edited afterwards. Adding this later means touching every part of the system that reads patient data.
- Encryption. Data protected both in storage and in transit, with keys managed separately from the data they protect.
- Backups you have actually restored. A backup nobody has tested is a guess. Restore it into a separate environment and confirm the records come back intact.
- Knowing where the data lives. Every third party service in your stack that can see patient data is part of your compliance position, including the ones you added for analytics.
How much of this do you actually need?
Be honest about which path you are on, because the answer changes the cost by an order of magnitude.
A private clinic wanting a booking system and customer portal needs solid UK GDPR practice, sensible security and a clear DPIA. That is achievable and proportionate.
A product intended for NHS deployment needs the full stack, and the assurance work runs alongside development rather than after it. That is a different project with a different budget, and anyone telling you otherwise is either inexperienced or hoping you will not notice until you are committed.
The worst outcome is building the first thing while assuming you can upgrade it into the second later. The data model, the audit layer and the access control usually have to be rebuilt, which is why the retrofit costs so much more than doing it properly at the start.
Where Rinaztec fits
We build custom software, business systems and AI automations for UK companies, and we work with businesses that handle sensitive data including healthcare.
Our approach is to start with the operational problem and be straight with you about scope. If you are building a booking system for a private clinic, we will build you a secure, well designed system without loading it with NHS assurance work you do not need. If you are heading for NHS deployment, we will tell you early what that path involves, including the parts that need a clinician rather than a developer.
We are a software team, not a regulatory consultancy or a law firm. For clinical safety sign off and formal regulatory advice you need the right specialists, and we would rather point you to them than pretend otherwise. What we do is build the software properly so that the compliance work has something solid to sit on.
If you are planning something that touches patient data and you are not sure which path you are on, that is a useful conversation to have before you start building.
- Email: riaz@rinaztec.com
- Get in touch: rinaztec.com/contact
- What we do: rinaztec.com/services
Tell us who will use the software and what data it handles, and we will tell you honestly what you are looking at.
This article is general information about UK requirements, not legal or regulatory advice. Frameworks change, and DTAC in particular was updated in 2026. Check the current NHS England and ICO guidance for your specific situation.