What does an auditor check for IEC 81001-5-1?
IEC 81001-5-1:2021 · Audit preparation and notified body assessment
Key point
An IEC 81001-5-1 audit — whether conducted by a notified body under EU MDR, an FDA inspector, or an internal auditor — focuses on three things: does the documented security programme meet the standard's requirements; is there objective evidence that the programme was actually executed; and are the resulting security risks acceptable. Documentation without execution, or execution without documentation, will generate findings.
How notified bodies assess cybersecurity under EU MDR
Notified bodies assessing conformity with EU MDR are required to evaluate cybersecurity as part of their Technical Documentation review. Under MDCG guidance documents (particularly MDCG 2019-16 and MDCG 2021-31 on cybersecurity), notified bodies must verify that the manufacturer has implemented cybersecurity measures proportionate to the risk profile of the device. IEC 81001-5-1 is the primary harmonised standard against which this assessment is made.
The notified body will typically assign a cybersecurity specialist reviewer for devices that are internet-connected, process patient data, or are used in critical care environments. The review is documentation-led: the auditor will request a defined set of documents and cross-check them for consistency and completeness.
Key documentation expected
| Document | IEC 81001-5-1 clause | What the auditor looks for |
|---|---|---|
| Security Plan | §5.1 | Scope definition, activity schedule, resource assignments, pass/fail criteria for each security activity, relationship to Software Development Plan |
| TARA Report | §5.2 | Asset inventory, threat actor profiles, attack surface analysis, STRIDE enumeration, risk estimates, control assignments, residual risk acceptability statement |
| Security Requirements Specification | §5.2 | Formal requirements traceable to TARA findings; each requirement has a unique ID, rationale, and acceptance criteria |
| Security Architecture Document | §5.3 | Trust boundary diagrams, data flow diagrams, authentication and authorisation model, encryption at rest and in transit, network segmentation |
| Security Test Report | §5.5 | Coverage of all security requirements; SAST scan results; pentest scope, methodology, findings, and remediation evidence; vulnerability scan results |
| SBOM | §5.6 | All third-party components listed with name, version, licence, and known CVEs at time of release; machine-readable format (SPDX/CycloneDX) |
| Customer Security Manual | §5.6 | Minimum IT requirements for deployment (OS, network, authentication); update obligations; incident reporting contact |
| Vulnerability Management Procedure | §5.7 | CVE monitoring process; assessment and escalation criteria; patch release timeline commitments; CVD policy and contact point |
| Security Risk Management Report | §5.6 | Summary linking all identified security risks to controls, showing residual risk is acceptable; cross-reference to ISO 14971 RMF where patient safety is impacted |
Process evidence the auditor will request
Documentation alone is insufficient. The auditor will request objective evidence that the processes were actually followed. Typical evidence requests include:
- SAST tool configuration and scan results for the released version — not just a summary, but the raw output showing which rules were checked and how findings were resolved
- Software composition analysis (SCA) scan results with evidence that all HIGH/CRITICAL CVEs in SOUP components were assessed and either patched or formally accepted
- Penetration test report with a scope statement, tester credentials, methodology, findings (including unexploited findings), and a remediation evidence log
- Code review records with security-focused review criteria — ideally showing a security champion or security reviewer as a mandatory approver in the development workflow
- Records of TARA review meetings or update activities triggered by architecture changes
- Examples of vulnerability monitoring activity: CVE notification emails, internal assessment records, and resolution tickets
- Evidence of the CVD process: the public disclosure channel (URL), at least one example of a received report and the response workflow
- Personnel training records showing that developers, testers, and RA/QA staff received security awareness training
Common nonconformities
Based on notified body and PSIRT experience, the following are the most frequently cited IEC 81001-5-1 nonconformities:
| Nonconformity | Root cause | Typical severity |
|---|---|---|
| TARA not updated after significant architecture change | TARA treated as a one-time document rather than a living record | Major |
| Security requirements not traceable to TARA findings | Security requirements written independently of TARA, or TARA performed after requirements were fixed | Major |
| SBOM incomplete or not machine-readable | Manual SBOM creation; transitive dependencies not included | Major |
| No public CVD channel | CVD process exists internally but not publicly disclosed — violates §5.7 and ISO/IEC 29147 | Major |
| Penetration test scope too narrow | Pentest limited to web UI only; network interfaces, authentication endpoints, and update mechanism not tested | Major |
| SOUP CVE monitoring not documented | Developers monitor CVEs informally with no records; cannot demonstrate compliance with §5.7 | Minor to Major |
| Security test report references requirements not in the Security Requirements Specification | Security testing added post-hoc without tracing back to formal requirements | Minor |
| Customer Security Manual missing or generic | Document exists but does not specify minimum OS versions, network requirements, or update obligations | Minor |
| Security risks with patient safety impact not cross-referenced in ISO 14971 RMF | Security and safety risk management operated as entirely separate silos | Major |
Practical preparation checklist
Use the following checklist to self-assess readiness before a notified body or internal audit:
- Security Plan approved and linked to Software Development Plan
- TARA report exists, is version-controlled, and was updated after the last architecture change
- Security Requirements Specification with unique IDs and TARA traceability exists
- Security Architecture Document includes trust boundaries, data flows, and cryptographic controls
- SAST tool integrated into CI/CD pipeline with policy on blocking HIGH/CRITICAL findings
- SCA tool integrated with records of CVE assessment for all SOUP components
- Penetration test completed within last 12 months (or for each major release) by qualified tester
- SBOM in SPDX or CycloneDX format generated for the released version
- Customer Security Manual published and version-controlled
- CVD policy published at a permanent URL and linked from product documentation
- Vulnerability monitoring subscription active for all SOUP components
- Security training records for all development and RA/QA staff
- Security risks with patient safety consequences cross-referenced in ISO 14971 RMF
Frequency and triggers for re-assessment
IEC 81001-5-1 does not define a fixed re-assessment interval, but the following events should trigger a security review and TARA update: major software version release; addition of new SOUP components; significant change to network architecture or deployment model; newly disclosed vulnerability with HIGH/CRITICAL severity in a SOUP component; confirmed exploitation of a vulnerability in the deployed product; and changes to applicable regulations or harmonised standards.