ISO 13485 is the first step for Medical Device Software Compliance

Why ISO 13485 Is Not Enough Alone

ISO 13485:2016 is the internationally recognised quality management system (QMS) standard for medical device manufacturers, providing the governance framework needed to develop, manufacture, and maintain compliant medical devices. However, for organisations developing Software as a Medical Device (SaMD), connected medical devices, or AI-enabled technologies, ISO 13485 alone is not enough.

A quality management system establishes the processes through which products are designed and controlled, but it does not provide detailed requirements for software development, cybersecurity, risk management, or artificial intelligence. These disciplines are addressed through complementary standards, including IEC 62304 for the software lifecycle, ISO 14971 for medical device risk management, IEC 81001-5-1 for health software cybersecurity, and emerging AI-specific governance and assurance frameworks.

For regulatory affairs, quality, engineering, and software leaders preparing products for UKCA marking, EU MDR compliance, FDA Quality Management System Regulation (QMSR), or AI and machine learning submissions, understanding how these standards fit together is essential. Rather than viewing them as separate compliance exercises, successful manufacturers build an integrated quality, software engineering, cybersecurity, and risk management system that satisfies regulatory expectations while supporting the delivery of safe, secure, and effective medical technologies.

ISO 13485 Software Scope: SaMD vs SiMD

ISO 13485 applies to manufacturers of medical devices, regardless of whether those devices are hardware, software, or a combination of both. This means it is equally relevant to organisations developing Software as a Medical Device (SaMD), Software in a Medical Device (SiMD), and medical devices containing embedded software.

SaMD is software that performs a medical purpose without being part of a physical medical device. Examples include clinical decision support software, diagnostic algorithms, and AI-enabled imaging applications. SiMD refers to software that forms part of a medical device, such as the operating software within an infusion pump, patient monitor, or imaging system. Embedded software is the software integrated into the device's hardware to enable its intended medical function. Although the terminology differs, all fall within the scope of ISO 13485 where they form part of a regulated medical device.

For software manufacturers, ISO 13485 establishes the quality management framework governing activities such as design and development controls, document and record control, supplier management, corrective and preventive actions (CAPA), complaint handling, and post-market surveillance. These processes ensure software is developed, released, maintained, and continually improved within a controlled quality system.

However, ISO 13485 deliberately does not prescribe how software should be engineered. It defines the quality processes surrounding development but stops short of specifying software lifecycle activities such as architecture, implementation, verification, configuration management, maintenance, or software problem resolution.

This is where IEC 62304 takes over. IEC 62304 defines the software development lifecycle expected for medical device software and assumes those activities are performed within an established quality management system. While the standard does not mandate ISO 13485 specifically, ISO 13485 is the internationally recognised QMS most commonly adopted to meet this expectation and demonstrate regulatory compliance.

IEC 62304, Safety Classes and SOUP

IEC 62304:2006+A1:2015 is the internationally recognised standard defining the software lifecycle processes for medical device software. It provides a structured framework for planning, developing, testing, releasing, maintaining, and updating software throughout its lifecycle. The standard is widely recognised by regulators and notified bodies when assessing software medical devices. A second edition of IEC 62304 is currently under development, reflecting changes in modern software engineering, cybersecurity, and agile development practices.

Unlike ISO 13485, which establishes the quality management system surrounding development, IEC 62304 focuses on how medical device software should be engineered. It defines lifecycle processes covering software development, software maintenance, software risk management, software configuration management, and software problem resolution. Together, these processes help ensure software changes remain controlled, traceable, and appropriately verified throughout the product's lifetime.

A key concept within IEC 62304 is the software safety classification. Software is assigned one of three classes according to the potential consequences of a software failure.

• Class A - No injury or damage to health is possible if the software fails. An example might be a reporting dashboard that displays historical information without influencing clinical decisions.

• Class B - A software failure could result in non-serious injury. For example, medication tracking software that supports clinicians but where additional safeguards exist to detect errors.

• Class C - A software failure could result in death or serious injury. A typical example is software controlling a closed-loop insulin delivery or dosing system.

It is important not to confuse the IEC 62304 software safety class with the medical device classification under the EU Medical Device Regulation (MDR). IEC 62304 classes reflect the potential consequences of software failure, whereas the MDR classifies the overall medical device according to regulatory risk classification rules, including Rule 11 for software. Although related, the two classifications serve different purposes and should be assessed independently.

IEC 62304 also introduces the concept of SOUP (Software of Unknown Provenance). SOUP includes software components that were not developed under the manufacturer's own quality management system, such as third-party libraries, open-source packages, commercial frameworks, operating systems, and legacy code. Manufacturers remain responsible for identifying every SOUP component, assessing associated risks, implementing appropriate risk controls, and monitoring those components throughout the product lifecycle for vulnerabilities, defects, updates, and obsolescence. Maintaining a documented SOUP list is widely regarded as an essential part of demonstrating compliance with IEC 62304 and supporting ongoing software maintenance and post-market activities.

Cybersecurity and IEC 81001-5-1

Cybersecurity is no longer a separate workstream that can be addressed immediately before regulatory submission. For manufacturers developing Software as a Medical Device (SaMD), connected medical devices, or AI-enabled products, cybersecurity should be embedded throughout the software quality management system and software development lifecycle. Secure development is now a regulatory expectation, not an optional enhancement.

This is where IEC 81001-5-1 complements IEC 62304. While IEC 62304 defines the processes for developing and maintaining medical device software, IEC 81001-5-1 provides requirements for incorporating cybersecurity into the health software lifecycle. Together, the standards encourage manufacturers to integrate security activities from initial design through deployment, maintenance, and post-market support.

In practice, this includes undertaking threat modelling to identify potential attack paths, adopting secure coding practices, implementing security testing, managing software vulnerabilities throughout the product lifecycle, and maintaining visibility of third-party software components through a Software Bill of Materials (SBOM). These activities help demonstrate that cybersecurity risks have been systematically identified, assessed, and controlled rather than addressed retrospectively.

These expectations align with international regulatory guidance. Within Europe, the EU Medical Device Regulation (MDR) Annex I requires manufacturers to reduce risks associated with unauthorised access and ensure devices are designed with appropriate protection against cybersecurity threats. The MDCG 2019-16 guidance expands on these principles for cybersecurity in medical devices. In the United States, the FDA's 2023 Premarket Cybersecurity Guidance sets out detailed expectations for secure product development, cybersecurity risk management, SBOM documentation, and coordinated vulnerability handling throughout the product lifecycle.

As cybersecurity regulation continues to evolve, manufacturers should also understand wider legal obligations beyond medical device legislation. Requirements such as NIS2 are increasing governance expectations for organisations operating critical technologies, including potential executive accountability. Our guide to NIS2 executive liability explores these responsibilities, while our overview of cybersecurity regulations summarises the wider UK and EU regulatory landscape affecting health technology manufacturers.

AI/ML Medical Device Software

Artificial intelligence (AI) and machine learning (ML) introduce challenges that extend beyond traditional software development. Unlike conventional software, some AI systems can change their behaviour as new data becomes available or as models are retrained. Even where deployed models remain "locked", manufacturers must manage risks such as model drift, data drift, performance degradation, and changes to training datasets. As a result, AI requires quality management systems that provide robust governance over data, algorithms, validation, and change control throughout the product lifecycle.

ISO 13485 provides the framework for managing these activities through document control, design controls, risk management, supplier oversight, verification, validation, and post-market surveillance. However, AI-specific processes must be layered onto this foundation to ensure changes remain controlled and clinically justified.

Regulators increasingly expect manufacturers to follow the Good Machine Learning Practice (GMLP) principles published by international regulators. At a high level, these principles promote multidisciplinary development teams, high-quality and representative datasets, robust software engineering, appropriate model training, independent testing, clinical relevance, transparency, human factors, ongoing performance monitoring, and continuous risk management across the AI lifecycle.

In the United States, the FDA has also developed the concept of Predetermined Change Control Plans (PCCPs) for certain AI-enabled medical devices. A PCCP defines, in advance, the modifications that may be made to an AI model after deployment, together with the methods used to implement and validate those changes. Rather than replacing existing quality processes, PCCPs sit within an organisation's wider ISO 13485 design and change control system, providing a structured mechanism for managing authorised algorithm updates.

Within Europe, the EU AI Act classifies most AI systems that are medical devices regulated under the EU Medical Device Regulation (MDR) as high-risk AI systems. Manufacturers therefore need to consider AI Act obligations alongside MDR conformity assessment rather than treating them as separate compliance programmes. In practice, notified bodies increasingly expect evidence that training and validation datasets are appropriate, bias has been considered and mitigated where relevant, model performance has been clinically validated, and ongoing monitoring supports continued safety and effectiveness throughout the product lifecycle.

Integrated Lifecycle: 13485, 62304, 14971

The most effective medical device manufacturers do not treat ISO 13485, IEC 62304, ISO 14971, and IEC 81001-5-1 as separate compliance exercises. Instead, they build an integrated management system in which each standard has a distinct role. ISO 13485 provides the quality management system (QMS) that governs product development and lifecycle management. IEC 62304 defines the software development lifecycle. ISO 14971 establishes the framework for identifying, evaluating, controlling, and monitoring medical device risks. IEC 81001-5-1 overlays cybersecurity activities across the software lifecycle to help ensure health software is designed, developed, and maintained securely.

In practice, the software lifecycle described by IEC 62304 sits within the broader design and development controls established by ISO 13485. The QMS defines how projects are planned, documented, reviewed, approved, and maintained, while IEC 62304 specifies the engineering activities needed to produce safe and reliable software. Throughout development, ISO 14971 informs design decisions by ensuring hazards are identified, software risks are assessed, and appropriate risk control measures are implemented. At the same time, IEC 81001-5-1 integrates cybersecurity activities such as threat modelling, secure development practices, vulnerability management, and security verification into those engineering processes.

An integrated approach also produces a coherent set of lifecycle documentation. Typical deliverables include a software development plan, software requirements specification, software architecture documentation, verification and test records, a requirements traceability matrix, a SOUP list, and a threat model, alongside the wider quality and risk management records maintained within the ISO 13485 QMS.

This integrated model also supports modern software development practices. Guidance such as AAMI TIR45 demonstrates how agile development methodologies can be applied within regulated medical device software development while remaining consistent with the expectations of ISO 13485, IEC 62304, and ISO 14971. Rather than choosing between agility and compliance, manufacturers can build development processes that achieve both.

UK, EU and FDA QMSR Context

Medical device software manufacturers increasingly need a quality management system capable of supporting submissions across the UK, European Union and United States.

In Great Britain, software medical devices are regulated through the UK Medical Devices Regulations 2002, with the UKCA route requiring classification, technical documentation, clinical evidence and, where applicable, assessment by a UK Approved Body. The MHRA’s Software and Artificial Intelligence as a Medical Device guidance and its SaMD and AI Change Programme describe the regulator’s evolving approach to software qualification, classification, AI, cybersecurity and lifecycle change. CE-marked devices are currently still accepted in Great Britain under transitional arrangements while wider regulatory reform continues.

Strengthened UK post-market surveillance requirements took effect on 16 June 2025. Serious public health threats must be reported within two days; deaths or unanticipated serious deterioration in health within ten days; and other serious incidents within 15 days. Manufacturers of Class I devices must prepare a post-market surveillance report and update it at least every three years.

In the EU, software is regulated through the Medical Device Regulation or In Vitro Diagnostic Medical Device Regulation, depending on its intended purpose. Classification determines the conformity route. While eligible lower-risk devices may be self-declared, most software falling into higher MDR or IVDR classes requires notified body assessment. Notified bodies typically examine the QMS alongside software lifecycle, risk management, cybersecurity, clinical or performance evidence and post-market arrangements.

In the United States, the FDA’s Quality Management System Regulation became effective on 2 February 2026. It amended 21 CFR Part 820 by incorporating ISO 13485:2016 by reference, while retaining FDA-specific statutory and regulatory requirements.

For global manufacturers, this creates greater QMS alignment but not a single universal submission. A well-designed ISO 13485 system can provide the common foundation, with market-specific classification, documentation, reporting and regulatory controls layered on top.

Frequently Asked Questions

What is ISO 13485?

ISO 13485:2016 is the internationally recognised quality management system (QMS) standard for medical device manufacturers. It defines the processes needed to consistently design, develop, manufacture, distribute, and support safe and effective medical devices. For software manufacturers, it provides the governance framework for design controls, document management, supplier oversight, CAPA, risk management integration, and post-market activities.

Do I need both ISO 13485 and IEC 62304?

For most manufacturers developing Software as a Medical Device (SaMD) or software within a medical device, yes. ISO 13485 establishes the quality management system, while IEC 62304 defines the software development lifecycle. They perform different roles and are typically implemented together to support regulatory compliance and demonstrate good software engineering practice.

What is the difference between ISO 13485 and IEC 62304?

ISO 13485 describes how the organisation manages quality, whereas IEC 62304 describes how medical device software should be developed and maintained. ISO 13485 governs processes such as design controls, document control and CAPA, while IEC 62304 focuses on software planning, development, verification, maintenance, configuration management and software problem resolution.

What is the latest version of IEC 62304?

The current published edition is IEC 62304:2006 with Amendment 1:2015. A second edition is under development to reflect advances in software engineering, cybersecurity and modern development methodologies. Until a new edition is formally published and adopted, manufacturers should continue to comply with IEC 62304:2006+A1:2015.

How are software safety Classes A, B and C decided?

IEC 62304 software safety classes are determined by the potential consequences of a software failure after considering risk control measures. Class A represents no possible injury, Class B covers potential non-serious injury, and Class C applies where software failure could contribute to death or serious injury. These classifications are separate from medical device classification under the MDR or UK MDR.

Does ISO 13485 cover cybersecurity?

Not in detail. ISO 13485 requires manufacturers to manage quality throughout the product lifecycle, but it does not define specific cybersecurity engineering activities. For software medical devices, cybersecurity is typically addressed through complementary standards such as IEC 81001-5-1, supported by risk management under ISO 14971 and secure software development under IEC 62304.

How does the FDA QMSR change things for software companies already certified to ISO 13485?

The FDA Quality Management System Regulation (QMSR), effective from 2 February 2026, aligns 21 CFR Part 820 with ISO 13485:2016. This reduces differences between US and international quality management expectations. However, FDA-specific regulatory requirements remain in force, so ISO 13485 certification alone does not guarantee FDA compliance.

What are the most common ISO 13485 audit findings for medical device software teams?

Common findings include incomplete design documentation, weak requirements traceability, inadequate software verification evidence, poor change control, insufficient supplier oversight for third-party software, incomplete risk management integration, outdated SOUP inventories, inadequate cybersecurity documentation, and weaknesses in post-market surveillance or CAPA processes. Many of these issues arise from poor integration between ISO 13485, IEC 62304, ISO 14971 and cybersecurity activities.

Build a Defensible Software QMS

Building a compliant software quality management system is about far more than achieving ISO 13485 certification. A defensible QMS integrates ISO 13485 as the quality management framework, IEC 62304 for software lifecycle processes, ISO 14971 for risk management, and IEC 81001-5-1 for secure software development. Where artificial intelligence is involved, additional governance is needed to manage data quality, model validation, change control, performance monitoring, and emerging regulatory expectations. For organisations supplying the NHS, UK clinical safety standards such as DCB0129 should also be incorporated to demonstrate that clinical risks have been identified and managed appropriately.

When these standards are implemented as a single, integrated system, manufacturers are better placed to satisfy UK, EU and US regulatory expectations while producing software that is safe, secure, maintainable, and ready to evolve throughout its lifecycle.

The AbedGraham Group helps health technology companies build practical, proportionate software quality management systems that align regulatory compliance with engineering best practice. Our expertise spans regulatory strategy, ISO 13485 implementation, IEC 62304 software lifecycle processes, cybersecurity, clinical risk management, UK clinical safety, and market readiness for software and AI medical devices.

Whether you are developing your first medical device software product or strengthening an existing quality management system, we can help you build a compliant and scalable foundation.

Book a discovery call to discuss your software QMS and regulatory requirements.

BOOK A DISCOVERY CALL