A cybersecurity compliance checklist for medical device startups in 2026 has to cover five phases: design, development, verification, submission, and post-market. Each line item traces to a specific authoritative source: MDR Annex I Section 17, EN IEC 81001-5-1:2022, MDCG 2019-16 Rev.1, the GDPR, or EN ISO 14971:2019+A11:2021. This post provides the phase-by-phase checklist and the source mapping notified bodies expect to see.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • MDR Annex I Section 17.2 and 17.4 are the two General Safety and Performance Requirements that anchor every line item in this checklist.
  • EN IEC 81001-5-1:2022 is the secure software lifecycle standard that structures the phases. MDCG 2019-16 Rev.1 is the interpretive guidance.
  • The checklist is divided into five phases: design, development, verification, submission, post-market.
  • Every line item maps to one specific source. If a line item does not trace back to a source, it does not belong on the checklist.
  • Startups that work this checklist through their stage-gate reviews walk into notified body audits with a coherent cybersecurity story.
  • This is the closing post for the Subtract to Ship cybersecurity cluster. It consolidates every other post in the cluster into one working document.

Why a checklist, and why phase-by-phase (Hook)

Most cybersecurity checklists for medical devices are flat lists. Forty or fifty items, no sequencing, no source mapping, no indication of when a founder is supposed to do any of them. Teams read the list, feel overwhelmed, pick the easy items, and end up with a half-covered technical file.

Felix sees the same pattern in Subtract to Ship coaching engagements. The fix is to sequence the work against the actual product lifecycle. Some cybersecurity work only makes sense during design. Some only makes sense after verification. Post-market items are invisible until the device is in users' hands. Mixing them up in one list flattens the priority and makes nothing get done well.

Tibor adds the source mapping. Every line item on this checklist exists because a specific authoritative source says it has to exist. When a notified body auditor asks "why is this in your file," the answer is on the page. That is the difference between a compliance checklist and a Subtract to Ship compliance checklist.

The anchor sources (Surface)

Five sources underpin the checklist. Every line item maps to at least one of them.

MDR Annex I Section 17.2. Software must be developed and manufactured in accordance with the state of the art, taking into account the principles of development lifecycle, risk management including information security, verification, and validation.

MDR Annex I Section 17.4. Manufacturers must set out minimum requirements concerning hardware, IT network characteristics, and IT security measures, including protection against unauthorised access, necessary to run the software as intended.

EN IEC 81001-5-1:2022. The health software security lifecycle standard. Structures the work across planning, requirements, architecture, implementation, verification, release, and post-market activities. The notified body will compare the technical file against this structure.

MDCG 2019-16 Rev.1 (December 2019, revised July 2020). Cybersecurity for medical devices guidance. Maps closely onto EN IEC 81001-5-1. Useful as a translation layer between the standard and the GSPRs.

EN ISO 14971:2019+A11:2021. Risk management. Cybersecurity hazards live in the same risk file as electrical, mechanical, and usability hazards.

Regulation (EU) 2016/679 (GDPR). Applies in parallel to MDR whenever personal data is processed. Usually missed by first-time founders as Tibor has observed across multiple audits.

The phase-by-phase checklist (Test)

Phase 1: Design

Goal of this phase: make cybersecurity decisions that are cheap now and expensive to retrofit later.

  • [ ] Intended use analysis documents connectivity. Every data interface, every radio, every update channel listed. Source: MDR Annex I Section 17.4.
  • [ ] Threat model exists. At least STRIDE-level analysis, covering confidentiality, integrity, and availability. Source: EN IEC 81001-5-1:2022 Clause 5.
  • [ ] Security requirements specification drafted. Derived from the threat model, traceable to hazards. Source: EN IEC 81001-5-1:2022 Clause 5.
  • [ ] Cybersecurity risks in the ISO 14971 risk file. Not a separate document. Same file, same scoring. Source: EN ISO 14971:2019+A11:2021.
  • [ ] GDPR data flow map drafted. Every personal data element classified. Source: GDPR Articles 5, 25, 32.
  • [ ] Secure update mechanism decided. Signed, verified, rollback-capable, documented in the architecture. Source: MDCG 2019-16 Rev.1 Section 4.
  • [ ] Security architecture document drafted. How trust boundaries, cryptography, and authentication are structured. Source: EN IEC 81001-5-1:2022 Clause 5.4.

Phase 2: Development

Goal of this phase: implement the design decisions without introducing new vulnerabilities.

  • [ ] Secure coding standard adopted. C, C++, Python, Rust, whatever the stack is, a written coding standard exists. Source: EN IEC 81001-5-1:2022 Clause 5.5.
  • [ ] SBOM generated from the EN 62304 configuration management record. Not a separate document. A view of the configuration items. Source: EN 62304:2006+A1:2015 Clause 5, MDCG 2019-16 Rev.1 Section 4.
  • [ ] SOUP components assessed for known vulnerabilities before inclusion. CVE feed checked on the day of inclusion. Source: EN 62304:2006+A1:2015 Clause 8, MDCG 2019-16 Rev.1 Section 4.
  • [ ] Code review process documented. Every security-relevant change reviewed by a second engineer. Source: EN IEC 81001-5-1:2022 Clause 5.5.
  • [ ] Static code analysis in the pipeline. Runs on every commit, findings triaged. Source: EN IEC 81001-5-1:2022 Clause 5.5.
  • [ ] Secrets management documented. No hardcoded credentials, no secrets in the repository. Source: EN IEC 81001-5-1:2022 Clause 5.5.
  • [ ] Change control linked to cybersecurity risk review. Every software change triggers a check against the threat model. Source: EN ISO 14971:2019+A11:2021 Clause 10.

Phase 3: Verification

Goal of this phase: produce the evidence that the implementation meets the security requirements.

  • [ ] Security test cases written against the security requirements specification. Traceable, repeatable, automated where possible. Source: EN IEC 81001-5-1:2022 Clause 5.6.
  • [ ] Unit-level security tests in the CI pipeline. Alongside functional tests. Source: EN IEC 81001-5-1:2022 Clause 5.6.
  • [ ] Integration-level security tests. Trust boundary crossings, authentication paths, cryptographic operations. Source: EN IEC 81001-5-1:2022 Clause 5.6.
  • [ ] System-level penetration test by a qualified third party. Report dated within the last twelve months before submission. Source: MDCG 2019-16 Rev.1 Section 5.
  • [ ] Penetration test findings triaged against the risk file. Accepted, mitigated, or residual risk justified. Source: EN ISO 14971:2019+A11:2021 Clause 7.
  • [ ] Verification report integrating all cybersecurity test results. One document, one traceability matrix. Source: EN IEC 81001-5-1:2022 Clause 5.7.

Phase 4: Submission

Goal of this phase: give the notified body a cybersecurity package that is complete, self-contained, and cross-referenced.

  • [ ] Cybersecurity section of the technical file exists as a distinct chapter. Not scattered across other sections. Source: MDR Annex II, MDCG 2019-16 Rev.1 Section 3.
  • [ ] Traceability matrix from GSPR Annex I Section 17 to evidence. One row per GSPR clause, evidence referenced. Source: MDR Annex II.
  • [ ] SBOM attached and current as of the submission date. Not stale. Source: MDCG 2019-16 Rev.1 Section 4.
  • [ ] Threat model attached and current. Not a document from eighteen months ago. Source: EN IEC 81001-5-1:2022 Clause 5.2.
  • [ ] Risk file shows cybersecurity hazards integrated with other hazards. Same scoring, same format. Source: EN ISO 14971:2019+A11:2021.
  • [ ] Instructions for use document the security boundary conditions. What the user is responsible for, what the manufacturer is responsible for. Source: MDR Annex I Section 23, MDCG 2019-16 Rev.1 Section 6.
  • [ ] Labelling includes IT security information per Annex I Section 17.4. Source: MDR Annex I Section 17.4.

Phase 5: Post-market

Goal of this phase: keep the device secure through its entire commercial life.

  • [ ] Post-market cybersecurity plan exists as part of the PMS plan. Not a separate document. Source: MDR Article 83, Annex III.
  • [ ] CVE monitoring subscribed for every component in the SBOM. Service levels documented. Source: MDCG 2019-16 Rev.1 Section 5.
  • [ ] Vulnerability triage procedure documented. Time from CVE publication to triage to decision to patch. Source: MDCG 2019-16 Rev.1 Section 5.
  • [ ] Incident response plan written and practised at least annually. Named decision-maker, escalation path, pre-drafted templates. Source: MDCG 2019-16 Rev.1 Section 5.
  • [ ] Serious incident reporting path aligned with MDR Article 87 deadlines. Source: MDR Articles 87, 88.
  • [ ] Secure update mechanism in operation. Signed, verified, tested rollback. Source: MDCG 2019-16 Rev.1 Section 4.
  • [ ] Periodic threat model refresh, at least annually. Source: EN IEC 81001-5-1:2022 Clause 9.
  • [ ] Penetration test on an annual cadence plus on significant change. Source: MDCG 2019-16 Rev.1 Section 5.
  • [ ] GDPR processing records maintained and reviewed. Source: GDPR Article 30.

The Subtract to Ship wrapper (Ship)

Felix frames this checklist as the minimum viable cybersecurity story a startup can tell a notified body. Not the maximum. The maximum is always bigger, always more expensive, always less useful than it looks. The minimum viable story has five characteristics, and Tibor uses them as the mental checklist when reviewing a technical file:

  1. Integrated, not bolted on. Cybersecurity lives inside the risk file, the configuration management record, and the PMS plan. Not in a separate binder.
  2. Current, not stale. Every document dated within the last twelve months, or with a documented reason for not being.
  3. Traceable, not orphaned. Every line item on the checklist maps to a specific authoritative source. Every piece of evidence maps to a specific line item.
  4. Living, not frozen. The checklist is worked during stage-gate reviews, not once at submission.
  5. Honest, not aspirational. If a control is not yet in place, the risk file says so explicitly. Notified bodies trust an honest gap more than a dressed-up one.

Reality Check

Work through the five phases. Count the boxes the startup can honestly tick today. Every unticked box is either a Subtract to Ship candidate or a finding in waiting.

  1. Design phase: of seven items, how many are in place?
  2. Development phase: of seven items, how many are in place?
  3. Verification phase: of six items, how many are in place?
  4. Submission phase: of seven items, how many are in place?
  5. Post-market phase: of nine items, how many are in place?
  6. Which phase has the highest number of unticked boxes, and is that the phase closest to where the startup currently sits in the product lifecycle?
  7. Is every ticked box supported by a dated artefact Tibor could open during a notified body audit?

A startup that can tick thirty-plus of the thirty-six items, with dated evidence, has a credible cybersecurity story. Anything below twenty is a warning sign. Anything below ten is a stop-and-fix situation.

Frequently Asked Questions

Is this checklist enough to pass a notified body audit? Completed honestly, with dated evidence attached to each line item, it is the minimum viable set. Notified bodies sometimes ask for additional device-specific items, but the team that has worked this checklist will have the foundation to respond quickly.

Does every Class I device need every item? The line items scale with risk. A Class I non-measuring, non-connected device can justify skipping several post-market items. A Class IIa connected device cannot. The test is not class, it is the threat model output.

How long does building the full checklist from scratch take? Felix has seen disciplined teams cover the design and development phases in four to six weeks once a secure development lifecycle is adopted. Verification and submission phases add another four to eight weeks depending on pentest scheduling. Post-market phase is ongoing by definition.

Can we outsource cybersecurity to a consultant? Parts of it, yes. Threat modelling, penetration testing, and GDPR mapping are natural outsourcing candidates. The integration into the risk file, the SBOM generation, and the day-to-day secure development lifecycle are not. Those stay in-house because they are tied to the code.

Is this checklist the same as the FDA Section 524B requirements? No. They overlap heavily but diverge on specific documentation expectations. A dual-market startup builds to the superset and maintains two traceability matrices, one to MDR Annex I and one to FDA 524B.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I Section 17.2, Section 17.4, Section 23. Annex II, Annex III. Articles 10, 83, 87, 88.
  2. MDCG 2019-16 Rev.1, Guidance on Cybersecurity for medical devices (December 2019, revised July 2020).
  3. EN IEC 81001-5-1:2022, Health software and health IT systems safety, effectiveness and security. Part 5-1: Security. Activities in the product life cycle.
  4. EN 62304:2006+A1:2015, Medical device software. Software life cycle processes.
  5. EN ISO 14971:2019+A11:2021, Medical devices. Application of risk management to medical devices.
  6. Regulation (EU) 2016/679, General Data Protection Regulation. Articles 5, 25, 30, 32.