Medical Device Cybersecurity Evidence Packs: What to Include 

Your security can be excellent and still fail the review. That sentence catches teams out more than any technical gap. For medtech and Software-as-a-Medical-Device (SaMD) companies, cybersecurity is now part of market access. Procurement teams, notified bodies and regulators all expect to see it. But what they assess is not the quality of your engineering. It is the quality of your evidence, and the two are not the same thing. 

Most of the delays we see at Cyber Alchemy do not come from insecure products. They come from secure products whose security was never written down in a way a reviewer can follow: scattered documents, threat models tied to an architecture you shipped two releases ago, a penetration test that did not cover your current API. The work was done. The evidence story was not. A medical device cybersecurity evidence pack is how you close that gap, and this article sets out exactly what belongs in one. 

This is written for medtech, SaMD and digital health teams preparing for NHS procurement, technical assurance, regulatory submission or market expansion: the people who will be asked, often at the worst possible moment, to prove that their product is safe to deploy and maintain. For the wider context around device security, our Essential Guide to SaMD and Medical Device Security is a useful companion to this article. 

What is a medical device cybersecurity evidence pack?

A medical device cybersecurity evidence pack is a structured, versioned set of documents, records and technical artefacts that demonstrate how cybersecurity is managed across the product lifecycle. It exists to answer the practical questions that healthcare buyers, NHS procurement teams, notified bodies, FDA reviewers and your own governance functions keep coming back to: 

• What does the product connect to, and where does sensitive or clinical data flow? 
• Which parts of the system do you control, and which does the customer control? 
• What risks have been identified, and what controls reduce them? 
• How have those controls been tested, and does the test scope match what you actually shipped? 
• How are vulnerabilities monitored and patched after launch? 
• How does the evidence stay current as the product changes? 

It does not need to be elaborate. It needs to be clear, current and navigable, so a reviewer can understand the product, follow the risk logic and see where each piece of evidence sits. In effect, the pack is the bridge between cybersecurity work and market access: the thing that lets you reuse one body of work across several gates instead of re-evidencing from zero every time someone new asks a question. 

Why evidence packs matter for DTAC, EU MDR and FDA readiness

Different markets ask for cybersecurity evidence in different ways, but they are pulling on the same underlying truth. Understanding how each gate frames the question helps you build a pack that travels. 

NHS DTAC, and the 2026 transition you cannot ignore

The Digital Technology Assessment Criteria (DTAC) is the standardised entry point for NHS and social care procurement of digital health technologies, covering five domains: clinical safety, data protection, technical security, interoperability, and usability and accessibility. It tends to probe both your organisational posture (can you operate securely?) and product-level controls (testing, patching, monitoring, incident response), often early, during pilots. 

This is a live issue right now. NHS England published DTAC version 2.0 on 24 February 2026, trimming roughly a quarter of the questions and removing duplication. The previous form must not be used from 6 April 2026. If the NHS is anywhere in your near-term plan, treat DTAC readiness as a programme with artefacts, owners and a refresh cadence, not a questionnaire you fill in the week before a pilot. 

EU MDR, explicit cybersecurity expectation

The EU Medical Device Regulation places cybersecurity inside lifecycle risk management and technical documentation. Two clauses in the General Safety and Performance Requirements do the heavy lifting. GSPR 17.2 calls for a state-of-the-art approach to the software development lifecycle, including information security, verification and validation. GSPR 17.4 requires you to define the minimum hardware, IT network and IT security conditions needed to run the software safely. The guidance document MDCG 2019-16 fleshes this out, including the expectation of “timely” security patching and the integration of cybersecurity risks into your ISO 14971 risk management file, not a separate security silo. 

“State of the art” here does not mean cutting-edge technology. It means current, generally accepted practice for your device type and risk profile, demonstrated through recognised standards, established controls and documented justification for any deviations. We cover the GB and EU picture in more depth in our article on EU MDR and NHS DTAC cybersecurity requirements. 

FDA Section 524B, the SBOM has teeth

FDA Section 524B, the SBOM has teeth 

In the US, Section 524B of the FD&C Act requires sponsors of premarket submissions for “cyber devices” to include a plan to monitor and address post-market vulnerabilities, processes to provide updates and patches, and a software bill of materials (SBOM) covering commercial, open-source and off-the-shelf components. The FDA’s final guidance, issued 27 June 2025, is explicit that an inadequate SBOM can trigger a Refuse to Accept decision or a technical screening hold. The SBOM is not a submission formality. It is a gate. 

One more reason to build it once

The UK position is shifting in a way that rewards a portable evidence base. Around 90% of medical devices used in Great Britain are CE-marked, and the MHRA is consulting (16 February to 10 April 2026) on indefinite recognition of CE-marked devices in GB, alongside transitional CE acceptance already running to 30 June 2028 for most devices and 30 June 2030 for some classes. The practical message: build your evidence so it maps cleanly to EU MDR expectations, and you keep the most optionality across markets with the least rework. 

The common thread: every gate wants to see that cybersecurity is identified, controlled, tested and maintained, not claimed. Build a single strong evidence base, then tailor the packaging for each route. 

What belongs in a cybersecurity evidence pack?

The exact contents depend on the product, deployment model, target market and clinical risk profile. A cloud-hosted SaMD platform will weight things differently from a connected device with firmware and hospital-network dependencies. But most packs share the same core categories: 

Artefact	What it shows
Product and deployment summary	What the product is, who uses it, and how it is deployed (cloud, on-device, hybrid).
System boundary diagram	Device, app, cloud, APIs, integrations and the trust boundaries between them.
Data flow diagram	Where clinical and personal data is created, transmitted, stored and processed.
Shared responsibility matrix	What you secure versus what the customer or host is responsible for.
Threat model	Stated assumptions, top abuse cases, aligned to a recognised framework such as STRIDE.
Cybersecurity risk register	Identified risks, severity, and residual risk decisions, linked to ISO 14971 where safety is affected.
Risk-control traceability matrix	Threat, then mitigation, then design requirement, then verification evidence, in a single table.
SBOM and vulnerability monitoring records	A release-tied SBOM plus a CVE triage log showing decisions made.
Security testing and remediation evidence	What was tested, when, why the scope matches the boundary, findings, and re-test confirmation.
Secure update and patch policy	How updates are delivered, with severity tiers and timelines you can actually meet in clinical deployment.
Incident response and disclosure process	Your VDP/PSIRT route and an incident playbook, ideally with rehearsal evidence.
Supplier and outsourced developer evidence	Contracted security obligations, SBOM and test deliverables from third parties.
Post-market monitoring process	What triggers a security impact assessment, and when you re-test.
Change log and evidence review dates	Owner, last-reviewed date and product version for every artefact.

These artefacts are most useful when they connect. The system boundary informs the data flow diagram; the data flow diagram supports the threat model; the threat model feeds the risk register; the risk register links to controls, testing and residual-risk decisions; the SBOM connects to vulnerability monitoring and patching; and the change log keeps the whole pack aligned with the product as it evolves. That connected chain, not the page count, is what makes a pack credible. 

Defining the system boundary is usually the highest-leverage first step, because it sets the scope for everything else and clarifies who is responsible for what. Our System Boundaries guide includes a worked “who controls what” table and an example boundary diagram you can adapt. 

What a strong evidence pack must demonstrate

A strong pack is a review tool, not an archive, and the qualities that make it reviewable are not optional polish. A traceable, version-controlled, release-tied evidence chain is a requirement in its own right. EU MDR expects a state-of-the-art lifecycle with verification, validation and risk management you can trace from threat to control to evidence, and the FDA expects architecture views, threat modelling and that same traceability inside a 510(k) submission for a cyber device. Get this wrong and you are not losing marks for tidiness, you are failing to demonstrate conformity. A well-built pack lets a buyer, assessor or reviewer quickly answer three questions: What is the current product and deployment model? What risks have been identified and controlled? And what evidence proves those controls work and are maintained? 

That last point is where most packs quietly fail. A threat model for an old architecture is not enough. A penetration test that did not include the current API or remote-access route raises more questions than it answers. An SBOM not tied to a release cannot reliably support vulnerability triage. So every artefact should make clear: 

• Which product version it applies to 
• Who owns it 
• When it was last reviewed 
• What changed since the previous version 
• Where the supporting evidence is stored 
• Which risks, controls and tests it links to 

This matters more for medical devices than almost any other product class, because they are not one-off releases. They are maintained across a deployed lifetime, during which new vulnerabilities, integrations, dependencies, hosting changes and clinical use cases all move the evidence picture. Release-tied evidence is the only kind that survives that. 

A worked example: why a living SBOM beats a perfect one

When Log4j was disclosed in December 2021, a critical flaw in one of the most widely used software libraries in existence, manufacturers without a maintained, release-tied SBOM spent weeks in manual investigation just trying to establish whether their devices were affected. Teams with an automated SBOM linked to a CVE-monitoring workflow answered the same question in minutes. 

The lesson reviewers have absorbed since: one worked example showing detection, assessment, decision and closure is worth more than a flawless SBOM last touched eighteen months ago. Under both EU MDR and FDA 524B, the SBOM obligation runs across the lifecycle, not just at submission. Generate it automatically at each build, link it to triage, and document the decisions. 

Common evidence pack problems

Most teams discover their evidence gaps only when they are already under procurement or regulatory pressure, exactly when gaps are hardest to fix and decisions that were never documented have to be reconstructed from memory. The recurring patterns: 

• Evidence scattered across different teams, tools and drives 
• Documents that no longer match the current product version 
• Missing system boundaries or unclear shared responsibilities 
• Threat models created once and never updated 
• SBOMs not tied to releases 
• Penetration-test scopes that do not match the current architecture 
• Patch policies that promise timelines the team cannot evidence 
• Security claims unsupported by documentation 
• No named owner or review date for key artefacts 

None of these necessarily means the product is insecure. But they make it harder to assess, and in procurement and regulatory settings, “hard to assess” behaves a lot like “not proven”. The most expensive version of this is the patch policy. Write “14 days” to look credible, miss it once for a clinically sensible reason, and you have a finding. Cyber Essentials Plus, which DTAC submissions often lean on, requires high and critical updates within 14 days, so an over-promised policy can collide with reality fast. The fix is not a weaker policy. It is an honest one, with severity tiers mapped to how your devices actually deploy and a documented exception process. 

Build the evidence before the pressure starts

The worst time to build a cybersecurity evidence pack is when a procurement team, notified body or regulator is already asking for it. Timelines are tight, commercial teams are waiting, and engineers get pulled into urgent documentation work that interrupts the roadmap. Missing evidence delays pilots, creates rework and raises avoidable questions during assessment. 

The alternative is to build evidence as the product develops. Define system boundaries during architecture. Map data flows before integrations get complex. Threat-model alongside design decisions. Generate the SBOM with each release. Maintain testing evidence, remediation records, patch processes and incident plans as part of the normal lifecycle. Done this way, cybersecurity evidence becomes part of your operating model rather than a last-minute scramble, and aligning it with the DSIT Software Security Code of Practice (secure design and development, build-environment security, secure deployment and maintenance, and communication with customers) gives you a recognised structure to build against. 

For medtech and SaMD teams, the shift is simple: security work matters; security evidence is what gets reviewed. Invest in both, in parallel. 

Free download: 10 Core Procurement Artefacts 

This is the checklist we use to keep procurement and assurance work from becoming a last-minute scramble. It covers the ten artefacts most frequently requested across DTAC, EU MDR and private procurement: security architecture and boundaries, threat model and risk register, a risk-control traceability matrix, SBOM and vulnerability monitoring, a VDP/PSIRT route, secure update and patch policy, security test evidence, logging and monitoring approach, supplier security controls, and an incident response playbook with rehearsal evidence, plus a suggested cadence for keeping them current. 

►  Download the 10 Core Procurement Artefacts (PDF) 

FAQs 

What is a medical device cybersecurity evidence pack? 

A structured, versioned set of documents and technical artefacts that demonstrate how cybersecurity is managed across the product lifecycle, from system boundaries and threat models through to testing, SBOM, patching and post-market monitoring. Its job is to let a buyer or reviewer follow a clear, release-tied evidence story rather than take security on trust. 

What cybersecurity evidence does NHS DTAC require? 

DTAC looks for both organisational posture and product-level controls: typically a Cyber Essentials position, penetration and vulnerability testing evidence, alignment with the DSIT Software Security Code of Practice, and defined logging and reporting. Note that DTAC version 2.0 (published 24 February 2026) must be used from 6 April 2026; the previous form should be retired. 

What does EU MDR require for cybersecurity? 

EU MDR expects a state-of-the-art approach to the software lifecycle and information security (GSPR 17.2) and a defined set of minimum IT and security requirements for safe operation (GSPR 17.4), with MDCG 2019-16 providing detail. Cybersecurity risks affecting patient safety should also appear in your ISO 14971 risk management file. 

Does an FDA submission need an SBOM? 

Yes. Under Section 524B, premarket submissions for cyber devices must include an SBOM covering commercial, open-source and off-the-shelf components, plus a post-market vulnerability monitoring plan and update and patch processes. The FDA’s June 2025 final guidance is clear that an inadequate SBOM can lead to a Refuse to Accept decision. 

How often should penetration testing be repeated? 

There is no single universal interval, though at least annually is a common baseline. What matters more is a defensible cadence plus triggers tied to change (major releases, new integrations, significant architectural changes, or new vulnerability classes) and a test scope that matches your current system boundary. 

How do we stop the evidence going stale after go-live? 

Treat the pack as a maintained asset, not a one-off deliverable: assign owners, define refresh triggers, and tie updates to release management and post-market monitoring. Every artefact should reference the product version it covers. 

Next step: book a review 

If you want a clear, evidence-first view of what will satisfy assessors and procurement teams, and what would be wasted effort, book a review with Cyber Alchemy. In 30 minutes we will: 

• Map your route to market and the gates that apply to it 
• Identify the gaps most likely to generate findings or procurement friction 
• Advise on what to build now versus what to defer, so you avoid future-market overbuild 

►  Speak to Cyber Alchemy about building a review-ready evidence pack: book a review 

About the author 

Luke Hill, Senior Security Consultant at Cyber Alchemy 

Luke brings deep expertise in security consultancy, penetration testing and regulatory-aligned security measures across the health and social care sector. He leads Cyber Alchemy’s technical and regulatory work in the medtech space, supporting a broad range of companies in building resilient devices and applications that comply with complex UK, US and EU requirements. 

Related case study: See how Cyber Alchemy supported Adaptix with medtech cybersecurity and assurance work in practice. Read the Adaptix case study.