National foreword

This British Standard is the UK implementation of EN IEC 81001‑5‑1:2022. It is identical to IEC 81001‑5‑1:2021.

The UK participation in its preparation was entrusted to Technical Committee CH/62/1, Common aspects of Electrical Equipment used in Medical Practice.

A list of organizations represented on this committee can be obtained on request to its committee manager.

Contractual and legal considerations

This publication has been prepared in good faith, however no representation, warranty, assurance or undertaking (express or implied) is or will be made, and no responsibility or liability is or will be accepted by BSI in relation to the adequacy, accuracy, completeness or reasonableness of this publication. All and any such responsibility and liability is expressly disclaimed to the full extent permitted by the law.

This publication is provided as is, and is to be used at the recipient’s own risk.

The recipient is advised to consider seeking professional guidance with respect to its use of this publication.

This publication is not intended to constitute a contract. Users are responsible for its correct application.

Compliance with a British Standard cannot confer immunity from legal obligations.

This British Standard was published under the authority of the Standards Policy and Strategy Committee on 28 February 2022.

This European Standard was approved by CENELEC on 2022-01-20. CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CENELEC member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.

CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

European foreword

The text of document 62A/1458/FDIS, future edition 1 of IEC 81001‑5‑1, prepared by SC 62A "Common aspects of electrical equipment used in medical practice" of IEC/TC 62 "Electrical equipment in medical practice" was submitted to the IEC-CENELEC parallel vote and approved by CENELEC as EN IEC 81001‑5‑1:2022.

The following dates are fixed:

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.

Any feedback and questions on this document should be directed to the users’ national committee. A complete listing of these bodies can be found on the CENELEC website.

Endorsement notice

The text of the International Standard IEC 81001‑5‑1:2021 was approved by CENELEC as a European Standard without any modification.

In the official version, for Bibliography, the following notes have to be added for the standards indicated:

INTERPRETATION SHEET 1

This interpretation sheet has been prepared by subcommittee 62A: Common aspects of medical equipment, software, and systems, of IEC technical committee 62: Medical equipment, software, and systems.

The text of this interpretation sheet is based on the following documents:

Full information on the voting for the approval of this interpretation sheet can be found in the report on voting indicated in the above table.

This interpretation sheet is intended to clarify the following:

Requirements which are needed to provide essential accompanying documentation to the operators of the health software product regarding the transfer of risk related to software items from the manufacturer to the responsible organization or operator.
Requirements which are needed to maintain security of the health software product

Interpretation of IEC 81001‑5‑1:2021, Introduction, 0.2

The health software is part of a connected and complex healthcare ecosystem, which is integrated into a surrounding health it system and health it infrastructure. ISO 81001‑1 provides a definition of the sociotechnical ecosystem in which the health software operates in, and how to reference the security aspect of the health software within an IT-system inside a broader healthcare system.

Interpretation of IEC 81001‑5‑1:2021, 4.1

4.1.7 Disclosing SECURITY-related issues

NOTE 1 This activity is related to 9.3 through 9.5 where additional supporting details are provided.

NOTE 2 On a) “CVSS” and “ranking” address the rating of the severity and characteristics of security vulnerabilities.

4.1.9 accompanying documentation review

NOTE For clarification, the documents mentioned with “security guidelines” are detailed in 5.8.2 and 5.8.7.

Interpretation of IEC 81001‑5‑1:2021, 4.3

4.3 software item classification relating to risk transfer

NOTE 1 (foundations, intentions):

maintained software” and required software “includes supported software”. software item classification related to risk transfer from 4.3 is clarified as follows:

The software item classification categories are nested, but only to ensure clauses that explicitly mention a category are also understood to include the nested categories. Table 1 above notes all clauses that detail requirements specific to a software item classification and notes the implicit inclusion of nested categories. Further requirements of software item classification that are not explicit in an associated clause are not part of this document.
The manufacturer shall apply risk transfer activities for all software items according to their associated category. An organization’s policy and procedures may choose different terms for these classifications if clauses citing requirements for these software item classifications are satisfied. Risks for all SOFTWARE ITEMS should be identified and managed (5.2.3), updates for software items controlled by the manufacturer or PRODUCT user should be communicated (6.3.1) and updates to manufacturer provided software items should be made available (6.3.2) and have verifiable integrity (6.3.3). For 4.3, any declaration of conformance, or internal policy/procedure, should state the alternative terminology leveraged and how it maps to the specific software item categories when alternative approaches to maintained, supported and required software are utilized.

The following clarifying statements help illustrate how the implicit software category nesting affects the clauses that explicitly mention one of the software item classifications:

5.2.3 applies for all 3 categories of software. security Risks from required, supported and MAINTAINED software should be identified and managed.
6.3.1 applies to maintained software in addition to supported software. product users also should be notified about updates to maintained software and supported software.
6.3.2 & 6.3.3 applies only to maintained software.

NOTE 2 (explain practical consequences)

It is generally understood that along with purchasing, installing, and using health software, the risk related to its use over time (often constrained by legal provisions) transitions to the operator. For the purposes of information security, manufacturers depend on information from suppliers of software items (being a logical part of the health software) for certain post-market activities, such as 9.3, to maintain a secure state.

Similarly, operators depend on information from manufacturers regarding which software items are intended to be used with health software product, which kind of support the manufacturer declares for these software items and which are not supported. Therefore, aspects of risk transfer of the health software from the manufacturer to the operator is addressed by the categories introduced in 4.3 and the associated clauses citing the software item classifications.

For technical or organizational reasons, it is possible that operators wish to be in control of when or whether a new security update is being installed on related systems where the manufacturer does not provide the security updates. As an example, updates to a database shared among several devices and services require good planning such that both selection and timing of updates cannot be left in the hands of a single manufacturer. This is a reason for introducing the category of supported software.

For technical or organizational reasons, manufacturers in some cases are not in a position to obtain security notifications or security updates for certain software items. This is a reason for introducing the category of required software. When vulnerabilities for such (“end-of-support” or otherwise unsupported) software become known, manufacturers can still select other means of maintaining the overall security of the health software product.

Over the health software life cycle, the manufacturer can update the software item categorization, which is typically done by downgrading software items from maintained to supported, from maintained to required or supported to required. When this happens, the requirements from associated clauses shall be evaluated to ensure appropriate risk transfer from manufacturers to operators.

NOTE 3 (distinguish from transitional software)

For clarification, Transitional (Annex F) is an attribute applied to the whole health software product – independent of the above categories for software items. The term “transitional“ does not specify a fourth category for software items – rather it is a circumstance in which the manufacturer developed the health software product before IEC 81001‑5‑1 existed. Therefore, Transitional health software (Annex F) is an alternative approach for evaluating health software that was “developed without following all of the activities defined in of IEC 81001‑5‑1:2021, Clause 4 to Clause 9.

Interpretation of IEC 81001‑5‑1:2021, 6.1

6.2.1 Monitoring public incident reports

NOTE For clarification, this activity specifies “review of the information” rather than review of the source.

FOREWORD

The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.
The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees.
IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.
In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.
IEC itself does not provide any attestation of conformity. Independent certification bodies provide conformity assessment services and, in some areas, access to IEC marks of conformity. IEC is not responsible for any services carried out by independent certification bodies.
All users should ensure that they have the latest edition of this publication.
No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.
Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication.
Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

International Standard IEC 81001‑5‑1 has been prepared by a Joint Working Group of IEC subcommittee 62A: Common aspects of electrical equipment used in medical practice, of IEC technical committee 62: Electrical equipment in medical practice, and ISO technical committee 215: Health informatics.

It is published as a double logo standard.

The text of this document is based on the following documents:

Full information on the voting for its approval can be found in the report on voting indicated in the above table.

The language used for the development of this International Standard is English.

This document was drafted in accordance with ISO/IEC Directives, Part 2, and developed in accordance with ISO/IEC Directives, Part 1 and ISO/IEC Directives, IEC Supplement, available at www.iec.ch/members_experts/refdocs. The main document types developed by IEC are described in greater detail at www.iec.ch/standardsdev/publications.

In this document, the following print types are used:

requirements and definitions: roman type;
informative material appearing outside of tables, such as notes, examples and references: in smaller type. Normative text of tables is also in a smaller type;
terms defined in Clause 3 of the general standard, in this particular standard or as noted: small capitals.

A list of all parts in the IEC 81001 series, published under the general title Health software and health IT systems safety, effectiveness and security, can be found on the IEC website.

The committee has decided that the contents of this document will remain unchanged until the stability date indicated on the IEC website under webstore.iec.ch in the data related to the specific document. At this date, the document will be

reconfirmed,
withdrawn,
replaced by a revised edition, or
amended.

IMPORTANT — The "colour inside" logo on the cover page of this document indicates that it contains colours which are considered to be useful for the correct understanding of its contents. Users should therefore print this document using a colour printer.

INTRODUCTION

0.1 Structure

PROCESS standards for health software provide a specification of activities that will be performed by the manufacturer – including software incorporated in medical devices –as a part of a development life cycle. The normative clauses of this document are intended to provide minimum best practices for a secure software life cycle. Local legislation and regulation are considered.

PROCESS requirements (Clause 4 through Clause 9) have been derived from the IEC 62443‑4‑1 [11] ¹product life cycle management. Implementations of these specifications can extend existing processes at the manufacturer’s organization – notably existing processes conforming to IEC 62304 [8]. This document can therefore support conformance to IEC 62443‑4‑1 [11].

Normative clauses of this document specify activities that are the responsibility of the manufacturer. The health software life cycle can be part of an incorporating product project. Some activities specified in this document depend on input and support from the product life cycle (for example to define specific criteria). Examples include:

risk management;
requirements;
testing;
post-release (after first placing health software on the market).

In cases where activities for health software need support from processes at the product level, Clause 4 through Clause 9 of this document specify respective requirements beyond the health software life cycle.

Similar to IEC 62304 [8], this document does not prescribe a specific system of PROCESSES, but Clause 4 through Clause 9 of this document specify activities that are performed during the health software life cycle.

Clause 4 specifies that manufacturers develop and maintain health software within a quality management system (see 4.1) and a risk management system (4.2).

Clause 5 through Clause 8 specify activities and resulting output as part of the software LIFE cycle process implemented by the manufacturer. These specifications are arranged in the ordering of IEC 62304 [8].

Clause 9 specifies activities and resulting output as part of the problem resolution process implemented by the manufacturer.

The scope of this document is limited to health software and its connectivity to its intended environment of use, based on IEC 62304 [8], but with emphasis on cybersecurity.

For expression of provisions in this document,

“can” is used to describe a possibility or capability; and
“must” is used to express an external constraint.

NOTE health software can be placed on the market as software, as part of a medical device, as part of hardware specifically intended for health use, as a medical device (SaMD), or as a product for other health use. (See Figure 2).

0.2 Field of application

This document applies to the development and maintenance of health software by a manufacturer, but recognizes the critical importance of bi-lateral communication with organizations (e.g. healthcare delivery organizations, hdos) who have security responsibilities for the health software and the systems it is incorporated into, once the software has been developed and released. The ISO/IEC 81001‑5 series of standards (for which this is part -1), is therefore being designed to include future parts addressing security that apply to the implementation, operations and use phases of the LIFE CYCLE for organizations such as HDOs.

A medical device software is a subset of health software. A practical Venn diagram of health software types is shown in Figure 1. Therefore, this document applies to:

software as part of a medical device;
software as part of hardware specifically intended for health use;
software as a medical device (SaMD); and
software-only product for other health use.

NOTE In this document, the scope of software considered part of the life cycle activities for secure health software is larger and includes more software (drivers, platforms, operating systems) than for safety, because for security the focus will be on any use including foreseeable unauthorized access rather than just the intended use.

0.3 Conformance

Conformance with this document focuses on the implementation of requirements regarding processes, activities, and tasks – and can be claimed in one of two alternative ways:

for health software by implementing requirements in Clause 4 through Clause 9 of this document,
for transitional health software by only implementing the processes, activities, and tasks identified in Annex F.

This document is designed to assist in the implementation of the processes required by IEC 62443‑4‑1, however, conformance to this document is not necessarily a sufficient condition for conformance to IEC 62443‑4‑1 [11]. More guidance on coverage can be found in Annex D.

MANUFACTURERS can implement the specifications for Annex E in order to achieve conformance of documentation to IEC 62443‑4‑1 [11].

Clause 4 through Clause 9 of this document require establishing one or more processes that include identified activities. Per these normative parts of this document, the life cycle processes implement these activities. None of the requirements in this document requires to implement these activities as one single process or as separate processes. The activities specified in this document will typically be part of an existing life cycle process.

1 Scope

This document defines the life cycle requirements for development and maintenance of health software needed to support conformance to IEC 62443‑4‑1 [11] – taking the specific needs for health software into account. The set of processes, activities, and tasks described in this document establishes a common framework for secure health software life cycle processes. An informal overview of activities for health software is shown in Figure 2.

The purpose is to increase the cybersecurity of health software by establishing certain activities and TASKS in the health software life cycle processes and also by increasing the security of software life cycle processes themselves.

It is important to maintain an appropriate balance of the key properties safety, effectiveness and security as discussed in ISO 81001‑1 [17].

This document excludes specification of accompanying documentation contents.

2 Normative references

3 Terms and definitions

4 General requirements

4.1 Quality management

4.2 Security risk management

4.3 Software item classification relating to risk transfer

5 Software development process

5.1 Software development planning

5.2 Health software requirements analysis

5.3 Software architectural design

5.4 Software design

5.5 Software unit implementation and verification

5.6 Software integration testing

5.7 Software system testing

5.8 Software release

6 Software maintenance process

6.1 Establish software maintenance plan

6.2 Problem and modification analysis

6.3 Modification implementation

7 Security risk management process

7.1 Risk management context

7.2 Identification of vulnerabilities, threats and associated adverse impacts

7.3 Estimation and evaluation of security risk

7.4 Controlling security risks

7.5 Monitoring the effectiveness of risk controls

8 Software configuration management process

9 Software problem resolution process

9.1 Overview

9.2 Receiving notifications about vulnerabilities

9.3 Reviewing vulnerabilities

9.4 Analysing vulnerabilities

9.5 Addressing security-related issues

Bibliography

BS EN IEC 81001-5-1:2022

Health software and health IT systems safety, effectiveness and security - Security. Activities in the product life cycle

Current

Published:

28 Feb 2026