Annex I, Section 17.2 of MDR 2017/745 forced a reality check for us. It’s short on prescriptive steps and long on outcome: devices must be protected from unauthorised access and ensure integrity and confidentiality where necessary for safety. To be fair, that’s exactly how it should be written — but in practice this means manufacturers must translate high-level language into concrete evidence the notified body and auditors can accept.
I support Class IIa/IIb Technical Files under MDR every week. Here’s the pragmatic checklist I use when I review a Technical File for cyber requirements, the standards I map to, and how I fold cyber work into change control and CAPA so it’s audit-ready.
Start with the risk assessment — map cyber to ISO 14971
Annex I is about safety and performance. Cybersecurity becomes a safety issue when a compromised confidentiality, integrity or availability impacts clinical performance.
- Update your hazard log so cyber-threats feed into ISO 14971 risk analysis (unauthorised access, corrupted data, denial of service, degraded performance).
- For each hazard, capture:
- exploit scenario (how could an attacker cause harm?)
- severity and probability (clinical impact + attack feasibility)
- existing controls and residual risk
In practice this means your risk management report must show traceability: cyber hazard → risk control (technical, procedural) → verification evidence.
Standards I reference: ISO 14971 (risk management), IEC 62304 (software lifecycle), and where applicable IEC 81001-5-1 (health software cybersecurity). These aren’t mandatory citations in the MDR text, but they are what notified bodies expect to see referenced.
Provide architecture and data-flow evidence
A sentence in the IFU won’t cut it. Notified bodies ask to see how the device is built and where data sits.
Include in the Technical File:
- block diagram of network interfaces, protocols, and data flows
- components that process or store patient data (local, cloud, third-party)
- trust boundaries and where authentication, encryption, and integrity checks apply
This is the document reviewers look at first. If the diagram is vague, expect follow-up questions.
Show threat modelling and verification
Threat modelling (even a lightweight STRIDE-style exercise) is useful because it links threats to mitigations.
Verification evidence that I file:
- results of static/dynamic code analysis where relevant
- penetration test summary and remediation log (don’t include raw exploit PoCs in the file)
- secure configuration checks for deployed devices or cloud services
- cryptography validation (algorithms used, key lengths, where keys are stored)
- SBOM (software bill of materials) and third-party component checks
Notified bodies increasingly request an SBOM. If you don’t have one, at least document your approach to third-party components and known-vulnerability checks.
Patch and vulnerability management — documented, measured, repeatable
Annex I implies maintenance and updates are part of safety. Your Technical File should include your vulnerability-handling process:
- defined timelines for triage, investigation, and remediation depending on severity
- channels for coordinated vulnerability disclosure (how external researchers contact you)
- criteria for field updates vs. recall
- evidence that updates are validated (change control, regression testing, deployment plan)
Connect this to CAPA and change control. Cyber incidents should create a CAPA, link to risk assessment updates, and include a root-cause and verification of effectiveness. An eQMS that supports CAPA-driven risk assessment and connected workflow makes demonstrating this traceability far easier.
Authentication, access control, and logging
Annex I’s confidentiality and integrity expectations translate to certain baseline controls:
- strong authentication; evidence of password policies, multi‑factor where needed
- least-privilege access model for clinical vs. admin functions
- tamper-evident audit logs — and importantly, a process to review logs tied to incidents
- secure default configurations and documented hardening guides
Audit logs and access records are also useful evidence for post-market surveillance if an incident occurs.
Clinical impact and post-market plans
If a vulnerability could affect clinical outcomes, your PMS/PMCF and vigilance planning must reflect that.
- include cyber-related scenarios in your PSUR and PMS reports where appropriate
- describe how you will assess clinical impact of known vulnerabilities (e.g. degraded measurements, misdiagnosis)
- ensure your vigilance procedures capture cyber incidents that meet MDR reporting thresholds
Practical tips from the notified-body trenches
From recent audits, the things that trigger extra scrutiny are:
- missing or superficial SBOMs
- vague update/patch timelines
- no trace from a penetration test to a CVE remediation record
- architecture diagrams that don’t show where patient data is decrypted
Small teams: don’t try to be exhaustive. Focus on the threats that map to patient harm and show a repeatable process to handle the rest.
What to put in the Technical File — concise checklist
- Risk management updates with cyber hazard traceability (ISO 14971)
- Architecture and data-flow diagrams
- Threat model and verification activities (pentest summary, SAST/DAST)
- SBOM and third-party component checks
- Vulnerability management policy + evidence of recent incidents handled
- Change control records for patches (with test evidence)
- Authentication, encryption, and logging descriptions
- PMS/PSUR linkage where cyber incidents affect clinical performance
Final practical note
Cybersecurity under Annex I is less about one checkbox and more about connecting the dots across risk management, software lifecycle, and post-market activities. If that connection is weak, the notified body will ask for proof — and that proof is mostly documentation showing you’ve done the assessment, implemented controls, and can respond.
How are you demonstrating SBOM and vulnerability timelines in your Technical File — and what did your notified body ask for that surprised you?
