ANSI/AAMI SW96:2023 (medical device security risk management), explained

Per the scope language reproduced across AAMI's and standards-catalogue listings, SW96 "provides requirements and guidance when addressing design, production and post-production security risk management for medical devices within the risk management framework defined by ISO 14971." Concretely, that scope is described as covering:

• identifying threats, vulnerabilities and assets associated with a medical device and its components and supply chain vendors;
• estimating and evaluating the resulting security risks;
• determining appropriate security risk controls to reduce those risks; and
• implementing processes to manage and monitor fielded devices — whether they contain traditional software (including firmware), programmable logic, or hardware — for security vulnerabilities across the product's life.

An independent secondary analysis by a medical device security consultancy quotes the standard's own purpose statement directly: SW96 exists "to specify requirements ... on how medical device manufacturers should manage security risk throughout the life cycle of a medical device within the risk management framework defined by ISO 14971." That same analysis describes the standard devoting roughly 14 of its 61 pages to the security risk management process alone, a level of procedural detail it compares directly to ISO 14971 and contrasts with the shorter treatment in AAMI's earlier TIR57 and TIR97 reports.

Multiple independent summaries consistently describe SW96 as requiring three linked artifacts, mirroring the structure ISO 14971 already uses for safety risk management:

• a security risk management process that a manufacturer establishes and documents;
• a security risk management plan, developed in accordance with that process; and
• a security risk management file, maintained for each medical device system and subsystem, that incorporates the plan and the records demonstrating it was actually followed.

That same secondary analysis groups SW96's substantive requirements into four areas spanning the device life cycle: design-phase risk management (identification, assessment, control verification and residual-risk evaluation of security risks); post-production processes, covering both enterprise-wide security risk management and device design features that enable it; monitoring, control and coordination, including communication with healthcare delivery organizations (HDOs) operating the device; and patch delivery and end-of-life management, covering timely updates and safe decommissioning. Device and firmware teams already building a firmware SBOM and a vulnerability disclosure policy will recognize much of this as the same underlying lifecycle work SW96 asks to be formalized specifically as security risk management, not folded silently into a generic quality process.

SW96 does not replace AAMI's earlier guidance; it is explicitly meant to be used alongside it. AAMI's own catalogue description states the document "is intended to be used in conjunction with AAMI TIR57 and AAMI TIR97" — TIR57 (2016) covers the general security risk management principles, and TIR97 (2019) focuses specifically on postmarket risk management. The key difference is formal status: TIR57 and TIR97 are AAMI Technical Information Reports — informative, consensus guidance — while SW96 is a binding standard, the kind of document FDA's recognized-standards program is built to reference directly in a declaration of conformity.

SW96 also complements, rather than duplicates, IEC 81001-5-1, the joint IEC/ISO standard covering security activities in the health software life cycle. Where IEC 81001-5-1 defines the development-process activities a health software team performs at each life cycle stage, SW96 defines the risk management artifacts (process, plan, file) that sit inside ISO 14971's framework — a device maker working toward conformance with both is typically running IEC 81001-5-1's process activities to produce the evidence that feeds SW96's risk management file.

FDA added ANSI/AAMI SW96:2023 to its Recognized Consensus Standards database on 9 October 2023, and announced the recognition publicly on 7 November 2023. The addition was formalized in FDA's periodic Federal Register notice, "Food and Drug Administration Modernization Act of 1997: Modifications to the List of Recognized Standards, Recognition List Number: 061" (89 FR 15202, published 1 March 2024), which lists SW96:2023 as new entry Recognition No. 13-131 under category "Q. Software/Informatics," with "Complete" as its extent of recognition — meaning FDA recognizes the standard in its entirety, not just specific sections.

Recognition lets a manufacturer cite conformance to SW96 directly in a premarket submission's declaration of conformity, rather than describing an equivalent security risk management process from scratch. It is a separate mechanism from the statutory Section 524B "cyber device" premarket duties (SBOM, vulnerability-monitoring plan, patching process) that apply regardless of which standards a manufacturer cites — see FDA premarket cybersecurity for medical devices for that statutory baseline, which SW96 conformance can help satisfy but does not substitute for.