What is DTAC?
The Digital Technology Assessment Criteria is the assessment an NHS organisation uses to decide whether a digital product is safe and appropriate to adopt. The buyer works through it. You supply the evidence.
It covers clinical safety, data protection, technical security, interoperability, and usability and accessibility, drawing each of those from requirements that already exist elsewhere in law, standards and NHS policy.
That last point is the one worth holding onto. DTAC did not invent a new compliance regime. It assembled the existing ones into a single form so that a buyer does not have to know five separate frameworks to make a purchasing decision.
Is DTAC mandatory?
No, and yes, and the distinction matters when you are negotiating.
There is no statute that requires DTAC. It is a framework NHS organisations use, not a legal instrument, and you will not be prosecuted for failing one.
Commercially, it functions as a requirement. Buyers use it, procurement processes reference it, and a supplier without a credible DTAC position generally does not reach a contract.
Why the distinction is useful in practice: there is no regulator to appeal to and no formal right of review. You are dealing with a customer applying their own process. That changes how you handle disagreements about scope. It is a commercial conversation, not a regulatory one.
DTAC, DSPT, DCB0129: which is which?
These three get used as though they were interchangeable, including by people who should know better. They are not.
Two consequences fall out of this table.
A strong DSPT position does not prepare you for DTAC. Different scope, different level. One describes an organisation, the other describes a product.
Medical device classification is a separate question entirely. DTAC does not determine whether your product is a regulated device, and passing it does not answer that question. If some of your functionality interprets clinical data rather than storing it, that is a different determination on a different timeline.
Who applies DTAC, and at what point?
The buying organisation applies it, which means the trigger is commercial rather than calendar based. It arrives when a trust, an integrated care board or another NHS body is considering adopting your product.
The practical implication is uncomfortable for a lot of teams: DTAC arrives when you are close to a sale, and several of its requirements take months to satisfy. By the time the questionnaire is in front of you, the items with external lead times are already on the critical path.
That is the argument for treating it as a roadmap input rather than a sales artefact.
Which parts are documentation, and which are product decisions?
This is the distinction that determines your timeline, and it is the reason the same assessment takes one team three weeks and another team two quarters.
-
Mostly documentation Describing your data flows, stating your lawful basis, setting out retention, listing subprocessors, explaining your development practices. If the thing exists, writing it down is days of work by someone who knows the system.
-
Mostly configuration Log retention, encryption settings, access controls that exist but are not evidenced. Days to weeks, and it is DevOps work rather than product work.
-
Product decisions with long lead times Three items reliably fall here, and they are the ones teams discover last:
-
Clinical safety requires a clinical safety officer, who must be a suitably qualified clinician, plus a hazard log and a clinical safety case. You cannot write your way to this with an engineering team. If you do not have that person, you are recruiting or contracting, and that is a lead time rather than a task.
-
Accessibility is where retrofitting hurts most. Keyboard navigation, focus management and screen reader support are architectural in a way that surprises people who have only thought about accessibility as a styling concern. This is frequently weeks of real engineering.
-
Penetration testing needs booking, executing and remediating, against your current architecture rather than the one you had two years ago. The queue is the constraint.
Everything else can run in parallel behind those three.
When should DTAC enter your roadmap?
Earlier than it enters your inbox.
The three long lead time items above do not care when you found out about them, and none of them compress under pressure. A team that identifies its clinical safety officer, books its penetration test and audits its accessibility before a buyer asks has removed the only parts of DTAC that cannot be done quickly.
The rest is describing a system you already built. That part is genuinely fast, provided the system was built with these questions in mind from the start.
See what applies to your product
Frequently asked questions
Is NHS DTAC legally required?
No. DTAC is an assessment framework that NHS organisations apply when adopting digital products, not a statutory requirement. In practice it functions as a commercial gate, because buyers use it as part of procurement and suppliers without a credible position generally do not reach contract.
How long does DTAC take to prepare for?
It depends almost entirely on whether the requirements land in documentation, configuration or product change. Documentation is days. Configuration is days to weeks. Clinical safety officer arrangements, accessibility remediation and penetration testing carry external lead times measured in months, and they are the items that determine the answer.
Does passing DTAC mean my product is not a medical device?
No. Medical device classification is a separate determination under a different framework. DTAC does not address it, and passing DTAC says nothing about whether your product falls in scope of medical device regulation. :::
