MDR/IVDR Cybersecurity Compliance Self-Assessment 🛡️

Cybersecurity is not optional under EU MDR and IVDR

If you’re building or maintaining medical or diagnostic devices — including Software as a Medical Device (SaMD) — your product must be secure by design and remain secure throughout its lifecycle.

This self-assessment checklist is your practical implementation guide, built from MDCG 2019-16 Rev. 1, and tailored for health-tech teams preparing for MDR/IVDR certification.

It covers the regulator’s expectations around:

- 🔐 Built-in security from the earliest design stages

- 📋 Integrated risk management across the lifecycle

- ✅ Verification and validation of security controls

- 📁 Comprehensive technical documentation

- 👥 User guidance on roles and responsibilities

- 🔄 Ongoing maintenance (monitoring, patching, vulnerability handling)-

⚠️ Note: Some sections are iterative (e.g., Secure-by-Design + Risk Management), while others (e.g., Technical File, IFU, Maintenance) are living artefacts that must be continuously updated.

How to use this checklist

https://storage.tally.so/6db6c4e6-ffa7-435b-bb1d-5fee5437279e/Screenshot-2025-06-02-at-13.20.11.png

https://storage.tally.so/8a5881a3-41ca-42e6-ac6b-da65ad094f19/MDR-cybersecurity-checklist-steps.png

✅ SECTION 1: Secure-by-Design

Overview: Build security into the architecture from day one; the device must stay secure on hostile networks. Design controls should eliminate or reduce risk by design and never compromise essential performance.

1.1 Do you maintain a dedicated cybersecurity requirements specification that defines security objectives (CIA), auth levels, cryptographic strength, logging needs, and update mechanisms?

A

✅ Yes, we have a versioned, traceable spec integrated with product requirements.

B

⚠️ Partially — we list some security needs, but it’s not structured or traceable.

C

❌ No — security isn’t defined formally in our system requirements.

1.2 Have you drafted system architecture and data-flow diagrams that mark trust boundaries, encryption points, identity providers, and the secure-boot chain?

A

✅ Yes — diagrams are up-to-date, annotated, and part of design documentation.

B

⚠️ Diagrams exist but are incomplete or lack security annotations.

C

❌ We don’t use annotated DFDs or architecture diagrams.

1.3 Do you implement secure-by-default configurations, runtime least privilege, separation of safety-critical modules, and secure key storage?

A

✅ Yes — these practices are standard and enforced through CI/CD pipelines or infrastructure.

B

⚠️ We use some of these practices inconsistently or only in production builds.

C

❌ We haven’t implemented secure defaults or isolation mechanisms.

1.4 Does your system include a cryptographically signed update mechanism with rollback capability and atomic integrity checks?

A

✅ Yes — secure updates are fully implemented and validated.

B

⚠️ We have update mechanisms, but lack signing, rollback, or validation features.

C

❌ Our system doesn’t support secure or signed updates.

1.5 Have you validated safety-cybersecurity interplay — such as what happens if a security control interferes with clinical access or emergency functionality?

A

✅ Yes — we’ve tested edge cases and have override mechanisms where needed.

B

⚠️ We’ve considered the issue but haven’t validated it or implemented failsafes.

C

❌ No — we haven’t addressed safety/security interaction.

🔐 SECTION 2: Security Risk Management

Overview: Extend the ISO 14971 risk file to cover cyber threats. Identify, score, mitigate and justify cyber risks within the overall benefit-risk analysis.

2.1 Have you extended your Risk Management Plan to include cybersecurity threats, roles, and acceptance criteria (e.g., “no unmitigated path to catastrophic harm”)?

A

✅ Yes – It’s fully defined, documented, and used.

B

⚠️ Partially – We’ve started defining this, but it’s not fully integrated.

C

❌ No – We haven’t expanded our plan to include cybersecurity.

2.2 Do you perform structured threat modeling that includes assets, attacker profiles, attack paths, and misuse scenarios?

A

✅ Yes – We have a comprehensive and documented threat model.

B

⚠️ Partially – We’ve done some threat modeling, but not consistently or fully.

C

❌ No – We haven’t formally modeled threats yet.

2.3 Are risks scored using both CVSS and a clinical impact scale to reflect technical and patient safety severity?

A

✅ Yes – We use both metrics across all scenarios.

B

⚠️ Partially – We use one scale or apply both inconsistently.

C

❌ No – We haven’t adapted our scoring to include both dimensions.

2.4 Do you use layered controls (design > protective > user info) and feed gaps back into earlier design phases?

A

✅ Yes – We follow this tiered approach and loop findings back.

B

⚠️ Partial – Some threats documented, but evaluation is inconsistent or incomplete

C

❌ No – Our controls aren’t layered or looped into development.

2.5 Are residual risks re-scored and justified in the benefit-risk analysis, with disclosures tagged for IFU (Instructions for Use)?

A

✅ Yes – Every residual risk is reviewed and documented in the B/R analysis and IFU.

B

⚠️ Partially – Some residual risks are tracked, but not fully documented.

C

❌ No – We haven’t formalized this residual risk process.

2.6 Do you maintain bidirectional traceability between the risk file and your design/testing changes?

A

✅ Yes – Any change to design or testing triggers a risk file update (and vice versa).

B

⚠️ Partially – There’s some tracking, but not fully bidirectional.

C

❌ No – Updates aren’t consistently reflected in both places.

🌐 SECTION 3: Minimum IT Requirements & Operating Environment

Overview: Specify only the essential external IT/network conditions. Everything else should be embedded in the product itself.

3.1 Have you listed all intended operating environments (e.g., hospital LAN, clinic PC, patient home Wi-Fi, cloud infrastructure)?

Have you evaluated each identified threat for potential impact, likelihood of exploitation, and preconditions — and documented the rationale behind risk scoring?

3.1 Have you listed all intended operating environments (e.g., hospital LAN, clinic PC, patient home Wi-Fi, cloud infrastructure)?

A

✅ Yes - a complete list has been documented

B

⚠️ Partially — some environments are listed, but documentation is incomplete or lacks specific network characteristics.

C

❌ No — we have not formally identified or documented the operating environments.

3.2 Have you defined minimum IT specifications such as OS version, patch level, processor/RAM, browser requirements, and time sync dependencies?

A

✅ Yes – All relevant system specs are defined.

B

⚠️ Partially – Some specs are included, but others are missing or outdated.

C

❌ No – Minimum IT specs haven’t been established.

3.3 Have you mapped required external IT security controls (e.g., antivirus, firewall, VPN) to the specific residual risks identified in your cybersecurity risk file?

A

✅ Yes – Each external control is clearly linked to a residual risk.

B

⚠️ Partially – Some linkages exist, but not across the full set of risks.

C

❌ No – We haven’t mapped external controls to risk items.

3.4 Have you drafted a "Minimum IT Requirements" section for your IFU or Admin Deployment Guide?

A

✅ Yes – Documentation is complete and clearly communicates IT needs.

B

⚠️ Partially – We have a draft or partial guidance in place.

C

❌ No – No IT requirements documentation exists for users/admins.

3.5 Do you validate the product in its lowest-spec environment and re-test after major OS/platform changes?

A

✅ Yes – We test against minimum environments and revalidate after key updates.

B

⚠️ Partially – Some low-spec testing is done, but not systematically.

C

❌ No – No structured validation on low-end environments or after platform changes.

🧪 SECTION 4: Security Verification & Validation

Overview: Demonstrate that security controls are effective — and uncover unknown vulnerabilities — through continuous, structured testing.

4.1 Do you run static code analysis (SAST) and software composition analysis (SCA) during development (CI), with full scans before release?

A

✅ Yes – Both are integrated into CI and used pre-release.

B

⚠️ Partially – One of the two is run, or only manually.

C

❌ No – We don’t consistently perform SAST or SCA.

4.2 Have you created and executed a formal Security Test Plan that includes feature tests (auth, crypto, logging, update), fuzzing, dynamic scanning, and penetration testing?

A

✅ Yes – All testing layers are covered in a documented plan.

B

⚠️ Partially – Some test types are included, but not all.

C

❌ No – We don’t have a dedicated security test plan.

4.3 Have you performed at least one penetration test of the integrated system using qualified testers?

A

✅ Yes – A formal pentest was performed and documented.

B

⚠️ Partially – Only internal or informal testing done.

C

❌ No – We haven’t conducted a pentest yet.

4.4 Do you handle findings with either fixes or documented risk acceptance, and update your cybersecurity risk file accordingly?

A

✅ Yes – All findings are addressed and traced in the Risk Table.

B

⚠️ Partially – Fixes are made, but traceability or risk acceptance is inconsistent.

C

❌ No – Findings are not systematically tracked or resolved.

4.5 Do you re-run regression tests after fixes and archive the results in your Technical Documentation?

A

✅ Yes – Regression tests are consistently re-run and logged.

B

⚠️ Partially – Some retesting is done, but not consistently or archived.

C

❌ No – We don’t perform formal regression testing after fixes.

📁 SECTION 5: Technical Documentation (Living)

Overview: Assemble all cybersecurity artifacts in your Annex II Technical File for Notified Body review and audits.

5.1 Have you created a structured Technical File index that includes: device description, cyber design, risk management, verification & validation, labeling, and PMS/PSIRT plans?

A

✅ Yes – All required sections are included and well-organized.

B

⚠️ Partially – Most sections are present, but not all are structured or up to date.

C

❌ No – The cybersecurity portion of our Technical File is not organized or complete.

5.2 Have you inserted your cybersecurity risk file, SBOM, system architecture, security test evidence, and an MDR/IVDR compliance matrix into the Technical File?

A

✅ Yes – All core cybersecurity documents are included and properly referenced.

B

⚠️ Partially – Some documents are included, but the file is incomplete.

C

❌ No – Most cybersecurity documentation is missing from the Technical File.

5.3 Do you maintain a revision log for the cybersecurity documentation, updating it after patches, security incidents, or design changes?

A

✅ Yes – We track and log every change to the cyber documentation.

B

⚠️ Partially – Some changes are logged, but the record isn’t consistent.

C

❌ No – We don’t maintain a revision history for cybersecurity documentation.

📄 SECTION 6: Instructions for Use (IFU) & User Info (Living)

Overview: Equip users with cybersecurity responsibilities, IT requirements, and clear residual-risk warnings.

6.1 Does your IFU include clear cybersecurity-related warnings and precautions (e.g. residual risks, known limitations, or misuse scenarios)?

A

✅ Yes – Warnings are present, visible, and product-specific.

B

⚠️ Partially – Some cyber-risk content is included, but not comprehensive.

C

❌ No – We haven’t added cybersecurity warnings to the IFU.

6.2 Have you embedded the Minimum IT Requirements from Section 3 (e.g. OS, specs, browser, network controls) into the IFU or Admin Manual?

A

✅ Yes – Minimum IT specs are clearly documented for users/admins.

B

⚠️ Partially – Some requirements are included but incomplete or buried.

C

❌ No – There’s no mention of IT requirements in our user materials.

6.3 Does your documentation provide practical operational guidance (e.g., change default credentials, user management, update procedures, backup/restore, incident response contact)?

A

✅ Yes – We offer clear, step-by-step cybersecurity guidance.

B

⚠️ Partially – Some guidance is included, but it lacks completeness or clarity.

C

❌ No – We don’t provide this kind of cybersecurity user guidance.

6.4 Do you reference the Admin Manual for deeper technical guidance (e.g., SBOM, open ports, logging behavior, hardening tips)?

A

✅ Yes – The Admin Manual is linked or referenced in the IFU/user guidance.

B

⚠️ Partially – Admin content exists but isn’t clearly connected or accessible.

C

❌ No – We haven’t prepared or referenced an Admin Manual.

🔄 SECTION 7: Post-Market Maintenance (Living)

Overview: Operate one integrated system that monitors, triages, patches, and fulfils EU vigilance duties across the entire product lifecycle. (PMS • Vigilance • PSIRT • Updates)

🔍 7.1.1 Prepare & Monitor

7.1.1 Does your PMS Plan include cyber elements (CERT feeds, SBOM monitoring, telemetry, cyber complaint fields)?

A

✅ Yes – Fully integrated into PMS Plan

B

⚠️ Partially – Some elements included

C

❌ No – No cyber additions to PMS Plan

7.1.2 Have you published the product’s support lifetime and patch SLA (e.g. critical issues patched within 60 days)?

A

✅ Yes – Clearly defined and shared

B

⚠️ Partially – Defined internally only

C

❌ No – Not defined or communicated

7.1.3 Is there a public vulnerability-disclosure channel (PSIRT email or web form)?

A

✅ Yes – Publicly accessible and maintained

B

⚠️ Partially – Exists but unclear or informal

C

❌ No – No external reporting mechanism

🛑 7.2 Intake & Triage

7.2.1 Do you log every vulnerability or incident and score them using CVSS × clinical impact?

A

✅ Yes – Logged and scored with combined model

B

⚠️ Partially – Logs exist, scoring inconsistent

C

❌ No – No structured intake or scoring

7.2.2 Do you submit vigilance reports within 15 days and issue FSCA where applicable?

A

✅ Yes – MDR timelines and FSCA followed

B

⚠️ Partially – Procedure exists but inconsistently applied

C

❌ No – No defined vigilance process

🛠️ 7.3 Remediate & Release

7.3.1 Are patches or mitigations validated and cryptographically signed before delivery?

A

✅ Yes – Fully validated and signed

B

⚠️ Partially – Some validation or no signing

C

❌ No – Unstructured patch delivery

7.3.2 Do you issue advisories or FSCA with risk explanations and update instructions?

A

✅ Yes – Clear, user-oriented communication

B

⚠️ Partially – Some notices, not systematic

C

❌ No – No advisories or risk updates issued

7.3.3 Do you monitor how many customers adopt the update or patch?

A

✅ Yes – Rollout and adoption tracked

B

⚠️ Partially – Some follow-up, no system

C

❌ No – No visibility post-release

🔁 7.4 Feedback & Documentation

7.4.1 Do you update the Risk Table, Technical File, IFU, and SBOM after patches or incidents?

A

✅ Yes – Revisions logged across all files

B

⚠️ Partially – Updates occur, but inconsistently

C

❌ No – Files not updated after changes

7.4.2 Are cyber incident trends summarized in PSUR/PMS reports and used in future design?

A

✅ Yes – Informs next dev cycle

B

⚠️ Partially – Reviewed but not acted o

C

❌ No – No formal trend analysis