NHS procurement and your cybersecurity evidence pack: What assessors actually look for

NHS procurement teams ask for cybersecurity evidence earlier than most medtech companies expect. The Digital Technology Assessment Criteria (DTAC) lands during pilots, before contracts are signed, and often before anyone has started preparing for it. The companies that stall are often the same: technically capable, genuinely secure, but without a coherent evidence pack when someone asks for one.

We have sat inside enough of these procurement processes to know that the gap is rarely a technical one. It is almost always an evidence one.

This article focuses on what DTAC actually requires in terms of cybersecurity evidence, how the three phases of readiness work in practice, and where teams most commonly fall short. It sits alongside two companion articles: our piece on building a medical device cybersecurity evidence pack, which covers the full evidence picture across DTAC, EU MDR and FDA, and our article on EU MDR and NHS DTAC cybersecurity requirements, which covers how the two frameworks compare and where their evidence overlaps. This article goes deeper on the DTAC-specific preparation process.

Assessment and cybersecurity burden

DTAC is the standardised entry point for NHS and social care procurement of digital health technologies, covering four assessed pass/fail domains. The domain where medtech and SaMD (Software as a Medical Device) teams most commonly stall is Technical Security, specifically the cybersecurity questions in section C3.

DTAC domain	What is assessed
Clinical Safety (C1)	Risk management for clinical hazards introduced by the technology
Data Protection (C2)	Privacy by design, GDPR/DPA 2018 compliance, DPIAs, protection of individual rights
Technical Security (C3)	Cybersecurity posture: Cyber Essentials, penetration testing, access controls, MFA, logging
Interoperability (C4)	APIs, HL7/FHIR standards, integration security
Usability and Accessibility (D1)	A comparative scoring section, not a pass/fail domain. Covers NHS service standards and accessibility principles.

Sections C1 to C4 are the assessed pass/fail domains. Section D (Usability and Accessibility) is a comparative scoring section that does not contribute to the overall pass/fail assessment.

The four domains are not independent. A data protection weakness, such as undocumented data flows or a missing Data Protection Impact Assessment (DPIA), often surfaces as a gap that makes C3 conversations harder. A threat model built for C3 provides evidence that also supports C1 clinical safety questions. Building cybersecurity evidence in isolation, without the surrounding context of data flows and clinical risk, tends to produce a pack that answers the questions on the form but does not survive the follow-up conversation.

Our work with NHS suppliers focuses on C2 and C3, which together cover the evidence most frequently requested and most frequently missing.

For a detailed comparison of how DTAC sits alongside EU MDR and FDA evidence requirements, and where approximately 70% of core evidence is reusable across all three routes, see our EU MDR and NHS DTAC cybersecurity requirements article.

What DTAC C3 actually requires

DTAC Technical Security (C3) is built around five questions, each with a specific evidence output. Statements of intent are not sufficient. Note that DTAC version 2.0, published by NHS England on 24 February 2026, is mandatory from 6 April 2026. If your team mapped evidence to the previous form, re-map to the current question set before your next submission or pilot conversation.

Cyber Essentials (C3.1). A valid Cyber Essentials certificate is required for all products under assessment. The certificate must cover all systems and services under your control that support the development, production use and operational management of the product. Certification lasts 12 months; an expired certificate is treated the same as no certificate. Cyber Essentials has lead time. Treat it as a programme milestone with a tracked expiry date, not a checkbox to collect when a pilot is already planned.

NHS Cyber Security Charter (C3.2). Signing the NHS Cyber Security Charter for Suppliers allows you to skip the remaining C3 questions. For most medtech suppliers this route does not apply, but it is worth confirming before mapping your evidence requirements.

External penetration testing (C3.3). For internet-based or internet-accessible products, DTAC requires a third-party penetration test summary report from the previous 12 months, covering OWASP Top 10 vulnerabilities. The v2.0 form sets a clear bar: the report must show no vulnerabilities scoring 7.0 or above on the Common Vulnerability Scoring System (CVSS). A report with even one unresolved finding at that threshold does not pass C3.3.

The scope of that test matters as much as the report itself. A test completed before a new API, a remote access route, or a cloud migration covers a system that no longer exists. An outdated scope raises more questions than it answers, and procurement teams notice.

A report from a CREST-accredited provider is strongly advisable. NHS procurement panels are increasingly familiar with CREST as the quality benchmark, and a non-accredited report can prompt follow-up questions that slow the process.

Secure software development (C3.4). You must confirm adherence to the DSIT/NCSC Software Security Code of Practice across all four of its themes: secure design and development, secure build environment, secure deployment and maintenance, and communication with customers. This is a confirmation statement, but it must be backed by documented practice. Assertion without evidence is a gap.

Operational security controls (C3.5, C3.5.1 and C3.6). For C3.5, you must confirm a plan for implementing MFA for all account types, preferably through identity federation. C3.5.1 asks specifically whether all supplier accounts with privileged access to the product have MFA enabled. C3.6 requires that logging and reporting requirements have been defined and are in place.

The three phases of DTAC evidence readiness

Treating DTAC as a form to complete is the wrong frame. It is a programme of work with three distinct phases, each building on the last.

Phase 1: Define and organise

The goal of Phase 1 is to make your product assessable before procurement pressure arrives. The output is an evidence index: a single document recording what exists, who owns it, when it was last reviewed, and which product version it applies to.

The highest-leverage starting point is the system boundary diagram. A diagram showing your device, companion app, cloud backend, APIs, integrations and the trust boundaries between them sets the scope for everything downstream: the threat model, the penetration test scope, the shared responsibility split, and the data flow diagram that C2 will also need. Without a clear boundary, your threat model is underdefined, your test scope is ambiguous, and your procurement answers will be inconsistent. Our medical device system boundaries article covers the full boundary definition process, including a worked responsibility matrix.

Phase 1 also includes: downloading the current DTAC question set and mapping existing evidence to it, confirming your Cyber Essentials position and renewal timeline, and planning external assurance activities early enough that lead times do not block a pilot date.

Phase 2: Implement and prove controls

Phase 2 turns the threat model and risk register from Phase 1 into implemented, operational controls and the objective evidence that assessment conversations require.

Two workstreams run in parallel. The first is implementation: identity and access controls including MFA and least privilege, secure-by-default configuration baselines for cloud, APIs and administrative interfaces, secure development controls aligned to the DSIT Code of Practice, dependency management to support the Software Bill of Materials (SBOM) and vulnerability response, a defined logging specification, and an incident reporting route with named roles.

The second is generating objective evidence: the penetration test scoped to the current system boundary, the SBOM per release linked to a CVE (Common Vulnerabilities and Exposures) monitoring workflow, the remediation log showing findings closed and re-tested, and the C3.4 confirmation statement.

In practice, this is how we structured the security programme for Adaptix's Ortho350 regulatory submission.

One thing medtech teams consistently underestimate at this stage is patch management. Deploying a security patch to a fleet of live devices is not the same as pushing an app update. Devices in clinical use, subject to uptime requirements, or requiring clinical safety validation before a patch goes live cannot meet the Cyber Essentials requirement of patching high and critical vulnerabilities within 14 days without building that validation time in from the start. That 14-day window is now an automatic failure condition under Cyber Essentials v3.3, effective 27 April 2026, with no tolerance for gaps that previously existed. For a medtech team deploying across NHS trusts with monthly IT change control windows, that window can be structurally impossible to meet without a tiered policy and a documented exception process. A tiered, honest policy that reflects your actual deployment constraints, with documented exception handling for clinically justified delays, is both more credible and more defensible.

Phase 3: Package for review and maintain as a lifecycle asset

Phase 3 turns implemented controls and objective proof into a pack that assessors can navigate, and a process that keeps the pack current as the product evolves.

The assembly work: a cover sheet, evidence index and navigation notes so reviewers can orient quickly, completed DTAC responses with direct links to stable evidence, a remediation log with re-test records closing high-risk findings, and a version-frozen release reviewed internally before it goes out.

The maintenance work is where most teams lose ground after an initial submission. Define refresh triggers before the pack goes out: new release, new integration, significant architectural change, new vulnerability class. Assign owners. Set review dates. Track changes in a change log. The question "what changed since your last submission?" is routine in follow-up procurement conversations. If you cannot answer it with a change log, the gap is visible.

The penetration test scope problem, illustrated

A SaMD company enters NHS procurement with a penetration test report completed nine months ago. The report is strong: no critical findings, all remediations confirmed.

The procurement lead asks two questions. Does the scope cover the cloud API introduced in the v3.0 release five months ago? Does it cover the remote support route used by the engineering team for device maintenance?

The answer to both is no. The test was scoped to the original system boundary, which predates both components. The report, which was accurate when it was produced, now evidences a system that is no longer what is deployed.

The result is not a failed assessment. It is a paused one, with a request for a scoped re-test before the pilot can proceed. A pilot planned for the following month slips by a quarter.

The fix is not a more thorough test. It is a test scope that is updated whenever the system boundary changes, with a defined trigger in the evidence maintenance process.

Evidence preparation checklist

Use this before entering any NHS procurement conversation.

Evidence foundation

• System boundary diagram current, covering device, app, cloud, APIs, integrations and trust boundaries
• Data flow diagram showing where clinical and personal data is created, transmitted, stored and processed
• Shared responsibility matrix defining what you control versus what the customer or host environment controls

Cyber Essentials

• Valid Cyber Essentials certificate obtained, covering all systems and services supporting the product
• Certificate expiry date in the evidence index with a renewal prompt

Penetration testing

• External penetration test completed within the past 12 months by a third-party provider, preferably CREST-accredited
• Test scope confirmed to match the current system boundary, including all APIs and remote access routes
• No vulnerabilities scoring 7.0 or above on CVSS confirmed in the summary report
• Findings remediated and re-test confirmation documented

Secure software development

• C3.4 confirmation statement drafted covering all four DSIT Code of Practice themes
• Documented practices in place to back each theme, not stated by assertion only

Operational controls

• MFA plan in place for all account types, preferably through identity federation (C3.5)
• MFA confirmed on all supplier accounts with privileged access to the product (C3.5.1)
• Logging specification documented: what events, where, retention period, access controls (C3.6)
• Incident reporting route defined with named roles and clinical safety escalation where relevant

Post-deployment readiness

• Patch policy documented with tiered SLAs that reflect actual clinical deployment constraints
• SBOM produced per release and linked to a CVE monitoring workflow with documented triage decisions
• Vulnerability Disclosure Policy (VDP) or security contact published

Evidence maintenance

• Evidence index with owners, last-reviewed dates and product version references
• Refresh triggers defined and assigned to named owners
• Change log in place recording what changed, when, and which artefacts were updated

Common evidence mistakes

Starting too late. Four to six months is a realistic preparation timeline from zero evidence to a submittable pack. Cyber Essentials certification and penetration testing both carry lead times that are invisible until they block a pilot date. The moment a procurement conversation is imminent is already too late to begin.

Scoping the penetration test to an outdated boundary. A test completed before a major integration, a new API or a cloud migration may cover less than half the current attack surface. The test scope and the current system boundary must match at the point of submission, not at the point the test was originally commissioned. And if the test was not conducted by a CREST-accredited provider, expect follow-up questions.

Missing the CVSS threshold. The DTAC v2.0 form is explicit: the penetration test report must show no vulnerabilities scoring 7.0 or above on CVSS. An otherwise strong report with one unresolved finding at that level does not pass C3.3. Remediation and re-test evidence must be in place before submission.

Writing a patch policy you cannot demonstrate. Committing to a patching timeline when your clinical safety validation process takes longer creates a finding at the next audit. Our patch management article covers the SLA-setting process in detail. The short version: a tiered, honest SLA you can evidence is always more credible than an aspirational one you cannot.

Letting Cyber Essentials lapse. An expired certificate creates the same evidence gap as no certificate. Track expiry dates in the evidence index with a renewal prompt, not in someone's calendar.

Building the pack for one tender and leaving it to drift. An evidence pack that was accurate when produced and has not been updated through subsequent product releases is a liability at the next procurement cycle. Define the owner, the refresh cadence and the triggers before the pack goes out.

FAQs

What cybersecurity evidence does DTAC C3 require?
DTAC C3 Technical Security requires: a valid Cyber Essentials certificate covering all systems supporting the product (C3.1), confirmation of NHS Cyber Security Charter status (C3.2), an external penetration test summary from the past 12 months covering OWASP Top 10 vulnerabilities with no findings scoring 7.0 or above on CVSS for internet-accessible products (C3.3), a confirmation of adherence to all four themes of the DSIT Software Security Code of Practice (C3.4), and a confirmed MFA plan and logging requirements (C3.5, C3.5.1 and C3.6).

When in the NHS procurement process does DTAC apply?
DTAC applies during procurement and due diligence for digital health technologies, including at pilot stage, before a commercial agreement is in place. Individual NHS Trusts may apply the criteria with some variation, but the four pass/fail domains and core evidence requirements are consistent.

Does every product need an external penetration test for DTAC?
DTAC C3.3 requires an external penetration test for internet-based or internet-accessible products, covering OWASP Top 10 vulnerabilities, from the past 12 months. The report must show no vulnerabilities scoring 7.0 or above on CVSS. Products that are not internet-accessible may not require external testing under C3.3, but the broader C3 requirements still apply and NHS procurement teams often probe testing evidence in supplementary conversations regardless of product type.

How long does DTAC evidence preparation take?
Four to six months is a realistic timeline from zero to a submittable evidence pack, assuming no major pre-existing security gaps. Cyber Essentials certification and external penetration testing are the typical pacing items. Teams that begin preparation only when a pilot is announced almost always find one or both creates a delay.

What did DTAC v2.0 change?
DTAC version 2.0, published 24 February 2026 and mandatory from 6 April 2026, reduced the question set and removed duplication across domains. The four assessed pass/fail domains and their core evidence requirements are unchanged. If your team mapped evidence to the previous version, that mapping needs reviewing before the next submission.

Does DTAC require post-deployment security monitoring?
DTAC v2.0 does not include a standalone post-market monitoring requirement in its assessed criteria, but C3.4 (secure deployment and maintenance) and C3.6 (logging and reporting requirements) both address it indirectly. NHS procurement teams routinely ask supplementary questions about how vulnerabilities are handled after go-live. A defined vulnerability triage process, a patch policy and an SBOM linked to ongoing CVE monitoring are expected in practice even where they are not mandatory on the form.

How does DTAC relate to EU MDR and FDA evidence requirements?
DTAC is a buying and due diligence requirement. EU MDR and FDA are regulatory pathways. They differ in purpose and process but overlap heavily in the evidence they draw on. Around 70% of core cybersecurity evidence is reusable across all three routes with tailoring rather than rebuilding. Our medical device cybersecurity evidence pack article covers the full artefact set, and our EU MDR and DTAC article covers the market-by-market differences in detail.

Book a DTAC evidence review

If you want a clear view of where your evidence stands before a procurement conversation starts, book a review with Cyber Alchemy. In 30 minutes we will:

• Map your current evidence against DTAC C3 requirements and identify the gaps most likely to delay a pilot
• Confirm your Cyber Essentials position and penetration testing timeline relative to any planned procurement dates
• Show you how to structure your evidence base so it serves DTAC now and travels to EU MDR and FDA without being rebuilt from scratch

► Speak to Cyber Alchemy about DTAC readiness: book a review