Passing the NHS DTAC: A Cybersecurity Guide for Health-Tech Vendors

Your health-tech product may already be live, security-tested, and being used successfully. Then you start an NHS procurement process and discover that having a secure product is only part of the conversation. You need to show how that security is managed, what evidence supports your answers, and whether the product meets the NHS baseline for digital health technologies.

That is where the NHS DTAC becomes important. It gives NHS organisations a structured way to assess digital technologies across clinical safety, data protection, technical assurance, interoperability, usability, and accessibility. For vendors, it is important to have the right evidence ready when an NHS buyer asks for it.

This blog focuses on the security side of that assessment, including what NHS DTAC asks vendors to show, what evidence is worth preparing before procurement, where common misunderstandings arise, and how to approach the assessment without treating it as a form to complete at the last minute.

Why Does NHS DTAC Matter?

NHS DTAC (Digital Technology Assessment Criteria) matters especially for technical security. A vendor might have penetration testing, vulnerability management, access controls, and security policies in place. Those controls still need to be explained and supported with the right evidence. 

For vendors reviewing NHS England cyber security expectations, the assessment is tied to the product being considered, so generic company-level security claims may not tell the NHS enough about the technology it is actually procuring. NHS guidance also requires manufacturers to consider the criteria throughout the product lifecycle and maintain the relevant documentation and evidence.

DTAC 2026 Update

The 2026 update makes this even more relevant for vendors working from older DTAC material. NHS England introduced a refreshed DTAC form in February 2026, reducing the number of questions and removing some duplication with other assurance processes. The previous form was due to be retired by 6 April 2026.

The changes include:

• New Digital Technology Assessment Criteria form with reduction of questions by 25%.
• Clear guidance explaining the scope, purpose, and way of completing the DTAC assessment
• Scope matches NICE guidance and covers software-based digital health technologies under DTAC. 

Decoding Section C: What Are the DTAC Cyber Security Requirements?

What NHS DTAC security evidence should demonstrate

Technical security is one of the five areas covered by the NHS DTAC compliance. For vendors, the difficult part is usually not knowing that security matters. It is being able to show how the product is protected and what evidence supports those claims.

A useful way to approach the assessment is to look at the product from several angles:

1. How was security built into the product?

It is useful to be able to show how security has been considered during development, rather than trying to explain the product’s security controls for the first time when it reaches procurement.

Useful evidence can include:

• Security requirements and architecture documentation
• System and data-flow diagrams
• Authentication and access-control design
• Records of security risks identified during development
• Security testing and remediation records
• Policies or procedures that apply directly to the product

The important part is the connection between the control and the product. Saying that your organisation has a security policy is less useful than showing how that policy applies to the application being assessed.

2. Have you considered how the product could be attacked?

This is where threat modelling can add useful evidence. The team should be able to think through questions such as:

• What happens if a user account is compromised?
• Can one patient access another patient’s information?
• Which APIs are exposed outside the application?
• What happens if a third-party component is compromised?
• Where are the trust boundaries between the application, NHS systems, and external services?
• What would an attacker gain from compromising a particular component?

A threat model is most useful when it reflects the actual architecture and data flows of the product. A generic document copied from another application does little to show that the security risks of this product have been considered.

3. Can the application and its APIs withstand security testing?

Security documentation is useful, but it needs to be backed by testing. Depending on the technology, testing may need to consider:

• Authentication and authorisation
• Access-control weaknesses
• Injection vulnerabilities
• Exposure of sensitive information
• Session management
• API authentication and authorisation
• Input validation
• Mobile-specific security issues, where applicable
• Vulnerabilities in externally exposed components

Penetration testing can provide useful evidence because it examines the running application from an attacker’s perspective. But a penetration test is not proof that a product contains no vulnerabilities. It is an assessment of a defined scope at a particular point in time.

That means the report matters, but so do the scope, test date, findings, and evidence showing how identified vulnerabilities were handled.

4. How is information protected?

Security controls should follow the data through the product rather than stopping at the application boundary.

Look at:

• Data in transit: Is sensitive information protected when moving between systems?
• Data at rest: How is stored information protected?
• Access: Who can access the data, and under what conditions?
• Backups: Are backups protected to the same standard as production data?
• Logging: Can relevant access and security events be investigated?
• Deletion: What happens when information reaches the end of its required retention period?

There is also an important distinction here. Data protection and technical security are related, but they are separate DTAC areas. A vendor should not treat a privacy policy as evidence that its technical controls are adequate, or assume that technical controls alone satisfy its data-protection obligations.

5. What happens when the product runs in the cloud?

Using AWS, Microsoft Azure, Google Cloud, or another provider does not make security the provider’s responsibility from end to end. The vendor needs to understand which controls belong to the cloud provider and which remain its responsibility.

For example:

• Are storage resources appropriately restricted?
• Are databases exposed to the public internet?
• Is privileged access controlled?
• Are unnecessary services disabled?
• Is cloud activity monitored?
• Are secrets and credentials handled securely?
• Are production and non-production environments appropriately separated?

The same principle applies to third-party software and services. An ISO 27001 certificate held by a supplier does not automatically show that the supplier’s component has been securely configured within your product.

6. Can you detect and respond when something goes wrong?

Preventing an incident is only part of technical security. The NHS buyer may also need confidence that the vendor has processes for:

• Detecting suspicious activity
• Investigating security events
• Escalating incidents
• Containing an incident
• Restoring affected services
• Recording what happened and what was changed afterwards

The evidence will vary according to the product and its architecture. A small standalone application may have a different monitoring profile from a platform handling sensitive information across several NHS integrations.

What should you have ready?

Step-by-Step Security Plan to Clear Your DTAC Audit

DTAC preparation should start well before a formal assessment or NHS procurement review. Security evidence is much easier to produce when it comes from work your engineering and security teams already carry out, rather than being assembled from scratch at the end.

The following steps give a practical way to organise that work.

Step 1: Perform Thorough Application Threat Modelling

Threat modelling gives your team a structured way to examine how the product could be attacked and what could happen if a particular control failed. It is especially useful for health-tech products because the impact of a security incident can extend beyond the application itself.

Product’s Actual Architecture

Start with the product’s actual architecture rather than a generic threat-model template. Identify:

• The information the application handles, such as patient or staff data
• Systems and services the application connects to
• Trust boundaries between users, your infrastructure, and external systems
• Privileged accounts and administrative functions
• APIs and other externally exposed interfaces
• Third-party services and dependencies
• What an attacker could gain from compromising each component

Then work through credible attack paths. For example, if a patient portal exposes an API for retrieving records, ask what happens if an attacker obtains a valid session, manipulates an object identifier or finds a way around authorisation checks.

For each material threat, record the risk, existing controls and any further treatment required. You can also record residual risk where the threat cannot be eliminated.

Key Questions for the Threat Model

A useful threat model should leave the team able to answer questions such as:

• Which assets would cause the greatest harm if compromised?
• Where could an attacker cross from one part of the system into another?
• Which controls prevent unauthorised access?
• What happens if a privileged account is compromised?
• Which risks need additional testing?

Keep the model tied to the product version being assessed. If the architecture changes materially, the threat model should be reviewed rather than left as a document created during the original development cycle.

Useful evidence: architecture diagrams, data-flow diagrams, threat-model documentation, risk assessments and records showing how identified risks were treated.

Note: The time required depends heavily on the size and complexity of the product. A simple application and a platform integrating with several NHS services should not be given the same timeline.

Step 2: Fix Open Web & Mobile Vulnerabilities

Security testing should happen before the DTAC submission is assembled, not after an assessor has identified a weakness.

Web Application Security Testing

For a web application, testing should consider areas such as:

• Authentication and session management
• Access-control weaknesses
• Injection vulnerabilities
• Security misconfiguration
• Cross-site scripting
• Sensitive information exposure
• Insecure file handling
• Business-logic flaws
• Vulnerable or outdated dependencies
• API security

Mobile Application Security Testing

If the product includes a mobile application, the testing scope needs to account for the mobile attack surface as well. That can include insecure local storage, weak authentication, insecure network communication, improper cryptographic use, exposed secrets, reverse-engineering risks, and weaknesses specific to the mobile platform.

Automated Scanning and Manual Testing

Automated scanning has a place here, especially for finding known vulnerabilities and common configuration problems. It should not be treated as a substitute for manual testing. Automated tools generally work within predefined checks; a skilled tester can investigate how individual functions interact and whether the application behaves securely when someone uses it in an unintended way.

Vulnerability Remediation

The remediation process matters just as much as finding vulnerabilities. A useful record should show:

• What was discovered
• How the finding was assessed
• Which component was affected
• What was changed
• Whether the fix was retested
• Whether any residual risk was accepted

Avoid inventing a universal deadline such as ‘all high vulnerabilities must be fixed within two weeks’. The right remediation window depends on the severity and exploitability of the finding, exposure of the affected system, available mitigations, and your own risk-management process.

Useful evidence: penetration-test reports, vulnerability-management records, remediation tickets, retest results, and relevant dependency/security-scanning records.

Step 3: Secure Your APIs

For a health-tech product that exchanges information with NHS systems or other external services, API security deserves specific attention. An API can expose sensitive functions even when the user-facing application itself appears well protected.

API Security Assessment Areas

The assessment should consider whether:

• Authentication is enforced where required
• Authorisation is checked for every sensitive operation
• Users cannot manipulate identifiers to access another user’s records
• Sensitive information is not unnecessarily returned in responses
• Input is validated and handled safely
• Transport security is appropriately configured
• Rate limiting or other abuse controls are used where the risk warrants them
• Error messages avoid exposing unnecessary technical information
• Security-relevant events can be logged and investigated
• Older API versions are retired or controlled when they are no longer supported

One area worth testing carefully is object-level authorisation. An API may correctly establish that a user is logged in while still failing to check whether that user is allowed to access the particular record requested.

For example, changing an identifier in a request should not allow one patient, clinician or organisation to retrieve another party’s information. This type of access-control flaw can be missed when testing focuses mainly on whether authentication works.

API testing should therefore include both automated checks and manual testing of application logic. The exact scope will depend on the APIs exposed by the product and the systems they connect to.

Useful evidence: API test results, penetration-testing findings, authentication and authorisation documentation, API specifications and remediation records.

Step 4: Engage a Third-Party VAPT Provider

Independent security testing can provide useful assurance before an NHS procurement or DTAC review, especially where the product handles sensitive information or exposes several external interfaces. For vendors choosing a health-tech penetration testing provider, the focus should be on the provider’s technical testing experience rather than simply offering a generic vulnerability scan.

A provider should be able to show relevant technical testing experience rather than simply offering a generic vulnerability scan. Before engagement, ask for the proposed testing scope. You should know which applications, APIs, environments, and authentication paths will actually be tested, rather than assuming they are all included.

What to Consider When Selecting a VAPT Provider

When selecting one, consider:

• Experience testing health-tech or similarly sensitive applications
• Capability across web, mobile, API, and cloud environments where relevant
• A clearly defined testing methodology
• Appropriate tester qualifications and professional credentials
• Clear reporting of technical evidence and risk
• A retesting process after remediation
• The ability to explain findings to both technical and non-technical stakeholders

Define the VAPT Scope

The scope needs to match the product. Depending on the architecture, that could include:

• Web application penetration testing
• Mobile application testing
• API testing
• External infrastructure testing
• Cloud configuration review
• Testing of relevant integrations
• Authentication and authorisation testing

Social engineering or threat-intelligence work should not be added simply to make the VAPT scope look more thorough. Include additional testing where it answers a genuine risk question for the product.

Timing also matters. Leaving penetration testing until immediately before submission leaves little room to investigate findings, make changes, and perform a meaningful retest. Building the testing into the development and release cycle gives the team more room to deal with problems properly.

When the testing is complete, retain the report and supporting evidence. The report should make clear what was tested, the scope and limitations, when testing took place, what was found, and how findings were handled.

Note: do not treat a penetration-test report as a certificate that proves the application is secure. It is evidence from a defined assessment at a particular point in time. Its usefulness depends on the scope, methodology, findings, and the actions taken afterwards.

How Qualysec Helps You Clear DTAC Without the Stress

One of the harder parts of preparing for DTAC is finding out that having security controls is not the same as having security evidence.

You may already have a penetration-test report. Your developers may have fixed several findings. You may have policies, vulnerability scans, and cloud controls in place. Then someone asks a simple question. Can you show evidence that the product was tested, the findings were addressed, and the fixes were verified?

This is where Qualysec can help.

When your existing security testing leaves unanswered questions

A generic vulnerability scan is rarely enough to understand how a health-tech application behaves when someone deliberately tries to misuse it. Qualysec’s advanced penetration testing covers web applications, APIs, mobile applications, AI/ML, and cloud environments, with the scope tailored to the technology being assessed.

An application may be secure while an API exposes another user’s records, or a mobile app may handle credentials differently from the web version.

Qualysec’s testing can help identify those issues before they become part of an NHS procurement process.

When a vulnerability has been fixed, but you still need to prove it

A common problem after penetration testing is the hand-off between security and development. A finding gets marked ‘fixed’ in a ticket, but the evidence that the fix was actually tested can be missing.

Qualysec guides fixing the findings and retesting so that fixes can be validated after the development team has made its changes. The resulting evidence gives the vendor a clearer record of the original finding and its resolution. That gives the security and procurement teams a clearer trail from the original finding through remediation to the final retest.

When your security evidence is spread across different places

DTAC preparation becomes harder when the evidence sits in separate reports, tickets, and security documents with no clear connection between them.

Qualysec’s role is narrower and more useful. Test the relevant technology, document what was found, and verify the fixes where required. The resulting security evidence can then support the wider DTAC submission rather than leaving the vendor to explain untested security claims.

Qualysec also has experience with healthcare technology. The company tested Android and iOS applications for a healthcare IoT product, including communication between the devices and cloud endpoints.

For a health-tech vendor preparing for NHS procurement, the useful question is whether the product has been tested from an attacker’s perspective and whether there is clear evidence of what happened after the findings were identified.

Conclusion

For a health-tech vendor, preparing for NHS DTAC is not simply about completing another assurance form. The harder question is whether the security work behind your product can stand up to scrutiny when an NHS organisation asks how the application is protected, what risks have been identified, and what evidence supports your answers.

That is why security preparation should happen before the assessment is in front of you. Start with the product’s architecture and attack surface, then check whether the important risks have been considered and whether the application and APIs have been tested against them. If vulnerabilities are found, allow enough time for remediation and retesting. Keeping the evidence alongside that work also makes the final DTAC submission much easier to support.

It is also worth remembering that DTAC is not the finish line for product security. Applications change, dependencies are updated, new integrations are introduced, and new vulnerabilities appear. A penetration test completed several months ago cannot tell you whether the product is still secure today. NHS guidance also expects relevant DTAC requirements to be considered throughout the product lifecycle, so security evidence should not be treated as a one-time exercise.

For vendors entering the NHS market, the strongest position is not having a perfectly polished DTAC file. It is knowing what your product is exposed to, understanding how those risks are being managed, and being able to show the evidence when it is requested.

If you are preparing your health-tech product for DTAC and need independent security testing, Qualysec can assess your web applications, APIs, mobile applications and cloud environments, with remediation testing available where vulnerabilities are identified.

Speak Directly With Qualysec’s Certified Security Experts

Discover vulnerabilities before attackers exploit them

Schedule Free Consultation
→

Frequently Asked Questions (FAQ)

1. What is the main purpose of the NHS DTAC?

The NHS DTAC helps NHS organisations assess digital health technologies across clinical safety, data protection, technical assurance, interoperability, and usability and accessibility before adoption. It provides a structured assurance framework for evaluating whether a technology is suitable.

2. Is an independent penetration test mandatory for DTAC?

Not universally. DTAC does not state that every vendor must obtain an independent penetration test. However, the right security testing can provide useful evidence for technical assurance, especially for products with significant application, API, or infrastructure exposure.

3. How long does a typical DTAC cybersecurity audit take?

There is no standard DTAC timeline that applies to every technology. The time required depends on the product, evidence available, assessment process, and any issues requiring further work. Vendors should allow additional time where remediation or clarification is needed.

4. What security evidence should a vendor prepare for DTAC?

The evidence depends on the technology and assessment, but may include security policies, architecture documentation, risk assessments, penetration-testing reports, vulnerability records, remediation evidence, and relevant access-control or incident-response documentation. These can also support wider digital health compliance with UK requirements.