IEC 81001-5-1 Security Risk Assessment Guide

Security risk assessment guidance for medical devices comes from several standards that overlap in scope but serve different jobs: ISO 14971 governs safety and security risk management broadly, ANSI/AAMI SW96:2023 provides the software-specific security risk management methodology, and IEC 81001-5-1 tells you where, inside the IEC 62304 software lifecycle, each security activity has to occur. Teams that treat these as competing standards end up duplicating work or leaving gaps at the seams. This guide maps IEC 81001-5-1 activity by activity against the IEC 62304 lifecycle and explains what the FDA looks for as evidence.

What IEC 81001-5-1 actually is

IEC 81001-5-1:2021, "Health software and health IT systems safety, effectiveness and security - Part 5-1: Security - Activities in the product life cycle," is a horizontal standard developed jointly by IEC and ISO technical committees to close a gap that IEC 62304 left open: 62304 governs the software development lifecycle for safety, but it does not specify security-focused activities. IEC 81001-5-1 amends that by defining a set of security life cycle processes that attach to, and in most cases directly extend, the IEC 62304 process model.

Rather than introducing an entirely new lifecycle, IEC 81001-5-1 adds security-specific tasks to processes device manufacturers already run: development planning, requirements analysis, architectural and detailed design, verification, problem resolution, configuration management, and maintenance. This is why it reads as a companion standard rather than a standalone framework, and why manufacturers already IEC 62304-compliant find it more of an extension than a new program.

Activity-by-activity mapping to IEC 62304

The value of this mapping for a submission is that a reviewer working through your design history file does not have to hunt for a separate "security file"; each security artifact sits next to the corresponding 62304 artifact for the same lifecycle phase, and the traceability is one thread rather than two.

How it relates to ANSI/AAMI SW96:2023

ANSI/AAMI SW96:2023 replaced AAMI TIR57 as the current normative reference for software system security risk management for medical devices, and it and IEC 81001-5-1 are complementary rather than overlapping in the way people often assume:

• SW96 defines the methodology: how to identify assets, threats, and vulnerabilities, how to assess and rate security risk, how to define security controls, and how to feed the result into the ISO 14971 risk management file.
• IEC 81001-5-1 defines the placement: at which point in the IEC 62304 software lifecycle each SW96 activity occurs, and what lifecycle-process evidence has to exist as a result.

In practice, you run SW96's risk assessment methodology, and you document it at the lifecycle checkpoints IEC 81001-5-1 specifies. Manufacturers we work with often struggle when they run a single, end-of-development security risk assessment; IEC 81001-5-1 makes clear that the assessment has to start at requirements and be revisited at architecture, detailed design, and release, not performed once and stapled to the submission. For how SW96 supersedes the earlier TIR documents, see AAMI TIR57 vs. TIR97 Comparison and ISO 14971 vs. AAMI TIR57 Hazard Analysis.

How it relates to ISO 14971

ISO 14971:2019 is the umbrella standard for medical device risk management and covers safety risk broadly; it does not provide security-specific methodology. IEC 81001-5-1 and SW96 exist precisely to fill that gap while keeping the output compatible with the ISO 14971 risk management file structure. The practical requirement is that a security risk identified under an IEC 81001-5-1/SW96 process has to be expressed in the same harm-severity and probability terms as a safety risk in your ISO 14971 file, so that a security vulnerability that could plausibly lead to patient harm is evaluated, and its residual risk accepted or mitigated, through the same risk acceptability criteria the organization already uses for safety hazards. A security finding that never crosses into the ISO 14971 file, or that uses an incompatible severity scale, breaks the traceability reviewers expect and is a common source of deficiency comments.

What the FDA looks for as evidence

The February 3, 2026 premarket cybersecurity guidance does not cite IEC 81001-5-1 as a recognized consensus standard by name in every version, but its description of expected security lifecycle activities (security risk management integrated into the QMS, security requirements traced from risk analysis, architecture-level threat modeling, security testing proportional to risk, and a maintained SBOM feeding postmarket monitoring) maps closely enough to IEC 81001-5-1's structure that using it as your organizing framework produces the evidence the guidance actually asks for. Specifically, reviewers look for:

• A security risk management plan referenced from, or integrated with, your software development plan, not a standalone document with no lifecycle anchor.
• Security requirements traced to risk analysis outputs, not a generic list copied from a template.
• A threat model at the architecture level, showing trust boundaries, data flows, and attack surfaces, updated when the architecture changes materially.
• Security test evidence proportional to device risk, commonly including static analysis, penetration testing, and vulnerability scanning results tied back to specific security requirements, not a single generic pen test summary.
• A residual risk acceptance decision signed off at release, consistent with your ISO 14971 acceptability criteria.
• Evidence the security artifacts are under configuration management and get updated on subsequent releases, not generated once for the original submission and left static.

A gap we see often: threat models and security risk assessments produced for the initial submission are never revisited when the architecture changes in a later release, which means the security evidence silently goes stale while the safety risk file continues to be maintained. IEC 81001-5-1's lifecycle placement is specifically designed to prevent that by tying the security activity to the same triggers (architecture change, requirements change, maintenance release) that already require a safety risk file update.

Common pitfalls

• Running one security risk assessment at the end of development instead of at each lifecycle checkpoint IEC 81001-5-1 specifies, which produces a document that cannot show how design decisions were actually informed by risk.
• Treating SOUP/third-party components as out of scope for security requirements, when IEC 81001-5-1 explicitly extends requirements analysis to include them; this is a frequent source of SBOM and vulnerability-management gaps.
• Keeping security risk and safety risk in separate files with incompatible severity scales, breaking the ISO 14971 traceability reviewers expect.
• Skipping the maintenance-process mapping, so postmarket monitoring and CVD intake are run by a different team using different criteria than the development-time security risk assessment, producing inconsistent risk ratings for the same class of finding.
• No configuration management for security artifacts, so a reviewer cannot tell which threat model version corresponds to which released build.

How Blue Goat Cyber approaches IEC 81001-5-1 security risk assessments

We map every security life cycle activity directly onto your existing IEC 62304 process set rather than layering on a parallel security program, because that mapping is what makes the resulting evidence legible to an FDA reviewer and sustainable for your engineering team after clearance. We run the ANSI/AAMI SW96:2023 methodology at each checkpoint IEC 81001-5-1 specifies, from requirements through release and into maintenance, and we keep the output expressed in the same harm-severity terms as your ISO 14971 risk management file so security and safety risk are one traceable thread, not two. Threat modeling, security requirements traceability, and security test planning are typically the highest-leverage places to start; see STRIDE Threat Modeling for Medical Devices for the architecture-level activity and Penetration Testing for Medical Devices for the system-level testing activity. For a full premarket build-out, our FDA Premarket Cybersecurity Services engagement runs this mapping end to end, and our Threat Modeling Services cover the architecture-level activity independently if that is your immediate gap.

Where this fits in the cluster

• STRIDE Threat Modeling for Medical Devices
• AAMI TIR57 vs. TIR97 Comparison
• ISO 14971 vs. AAMI TIR57 Hazard Analysis
• Penetration Testing for Medical Devices
• Postmarket Cybersecurity Monitoring for Medical Devices

FAQ

How does IEC 81001-5-1 differ from ISO 14971?

ISO 14971 is the umbrella risk management standard covering safety broadly and does not define security-specific methodology. IEC 81001-5-1 defines where, inside the IEC 62304 software lifecycle, security activities have to occur and what they have to produce. Security findings developed under IEC 81001-5-1 still have to be expressed in ISO 14971's harm-severity and risk-acceptability terms so the two risk files are traceable to each other.

Is IEC 81001-5-1 mandatory for FDA medical device submissions?

The FDA does not name IEC 81001-5-1 as a mandatory recognized consensus standard in every context, but the security lifecycle activities described in the February 3, 2026 premarket cybersecurity guidance map closely onto it. Using it as your organizing framework is a practical way to produce the evidence structure reviewers expect, even where it is not cited as a strict requirement for your specific device type.

What specific security life cycle activities does IEC 81001-5-1 require?

It attaches security tasks to each IEC 62304 process: a security risk management plan at development planning, security requirements derived from risk analysis, architecture-level threat modeling, secure detailed design and coding practices, security-focused integration and system testing, release criteria tied to residual risk acceptance, and postmarket vulnerability monitoring and patch management under the maintenance process.

How do you integrate threat modeling into an IEC 81001-5-1 assessment?

Threat modeling sits at the architectural design activity in IEC 81001-5-1's mapping. It should identify trust boundaries, data flows, and attack surfaces for the device architecture, feed directly into security requirements and test planning for the phases that follow, and be revisited whenever the architecture changes materially, not produced once and left unrevised for the life of the device.

Does IEC 81001-5-1 replace AAMI SW96?

No. SW96 provides the security risk management methodology, and IEC 81001-5-1 defines the lifecycle placement for applying that methodology inside IEC 62304 processes. Manufacturers run SW96's assessment approach at the checkpoints IEC 81001-5-1 specifies; the two standards are meant to be used together, not as alternatives.

Sources & primary references

• IEC 81001-5-1:2021, Health software and health IT systems safety, effectiveness and security - Part 5-1: Security - Activities in the product life cycle
• IEC 62304:2006+AMD1:2015, Medical device software - Software life cycle processes
• ANSI/AAMI SW96:2023, Medical Device Security Risk Management
• ISO 14971:2019, Application of Risk Management to Medical Devices
• Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (FDA, February 3, 2026 final guidance)