ISO 13485 vs IEC 62304: Compliance Differences

How the Two Standards Differ in Scope

ISO 13485 and IEC 62304 address different layers of product development. ISO 13485 is a quality management standard for the entire medical device lifecycle. It covers supplier management, design controls, production, and post-market surveillance. IEC 62304 is a software lifecycle standard. It defines how software is specified, developed, tested, and maintained within a device.

A common confusion arises because both standards require documented processes. However, the subject matter differs. ISO 13485 asks how your organization controls the quality of the physical product and its processes. IEC 62304 asks how your organization controls the software that makes the device function.

For a simple mechanical device, such as a surgical forceps, ISO 13485 is the primary regulatory framework. For a device with embedded software, such as an infusion pump or a patient monitor, both standards apply. The software must meet IEC 62304, while the hardware, integration, and manufacturing processes must meet ISO 13485.

Comparison of Compliance Requirements

Option	Best for	Limitations
ISO 13485	Overall product quality, manufacturing controls, and supplier management	Does not define specific software development methodology or testing depth
IEC 62304	Software development, validation, and post-market software updates	Does not address hardware manufacturing, material testing, or physical device risks
Combined Approach	Devices with both hardware and software components	Requires coordinated documentation and cross-functional review
Hardware Only	Mechanical or physical devices without embedded software	Incomplete if the device later gains software capabilities or updates
Software Only	Standalone software components or cloud-based services	Insufficient for integrated devices where software interacts with hardware

The table above highlights that neither standard is a substitute for the other. An organization can be certified to ISO 13485 without having a specific IEC 62304 process in place. Conversely, a software team can follow IEC 62304 rigorously while the manufacturing side fails to meet ISO 13485 requirements for production control.

How to Evaluate Suppliers for Both Systems

When evaluating a supplier, you must look at two distinct sets of evidence. For the hardware side, request the ISO 13485 certificate and the scope of certification. Check if the certified scope includes the specific product line you are sourcing. If the supplier manufactures a broad range of devices, the certificate may cover only a portion of their portfolio.

For the software side, ask for the software development lifecycle documentation. Look for evidence of software risk management, which is often embedded in ISO 13485 but executed through IEC 62304 controls. Ask how they handle software changes. Do they have a documented change control process? How do they verify that a software update does not introduce new risks?

A practical audit question is: “Show me how a software defect is tracked from discovery to resolution.” The answer should reference IEC 62304 activities, such as software verification and validation. Another question is: “How do you ensure the production software matches the released software?” This tests the link between IEC 62304 and ISO 13485 production controls.

Common Gaps in Integrated Device Compliance

Many devices fail not because of missing certificates, but because of disconnected processes. The software team and the hardware team may operate in silos. The software is developed according to IEC 62304, but the integration testing with the hardware is not documented as part of the ISO 13485 design verification plan.

Another frequent gap is in post-market surveillance. ISO 13485 requires a system to collect and evaluate field feedback. IEC 62304 requires a process for software updates. If a field issue is identified, the supplier must determine if it is a hardware defect, a software defect, or an interaction between the two. Without a clear process, the supplier may miss the root cause or delay the corrective action.

Consider a scenario where a patient monitor displays incorrect readings. The ISO 13485 process triggers a complaint investigation. The team checks the hardware, such as sensors and cables. If the hardware is fine, the investigation must pivot to software. If the software team does not have a defined IEC 62304 process for incident analysis, the investigation stalls. The supplier may provide a generic software patch without proper risk assessment or verification.

Documentation and Traceability Challenges

Documentation is the backbone of both standards. ISO 13485 requires records that prove the product was made according to design inputs. IEC 62304 requires records that prove the software was developed and tested according to its risk class.

A critical failure point is traceability. If a software requirement changes, how do you trace that change to the test cases that were modified? If a hardware revision changes an electrical interface, how do you trace that change to the software requirements? In a well-managed system, these links are explicit. In a poorly managed system, they are assumed.

Buyers should ask for a sample traceability matrix. It should show how a specific software requirement maps to a specific test case and a specific test result. It should also show how that requirement relates to a specific user need or risk control. If the supplier cannot provide this, it suggests that the software lifecycle is not tightly controlled.

When to Prioritize One Standard Over the Other

In most cases, both standards are mandatory for software-enabled devices. However, the emphasis can shift based on the product type. For a device where the software is a minor feature, such as a basic timer or a simple user interface, the IEC 62304 burden may be lighter. The risk classification of the software may be lower. ISO 13485 becomes the dominant framework because the physical safety and performance depend more on hardware.

For a device where the software is the core function, such as an automated surgical instrument or a diagnostic algorithm, IEC 62304 becomes the primary driver. The risk classification of the software is high. The depth of testing, verification, and validation is extensive. ISO 13485 still applies to the manufacturing and supply chain, but the technical safety case relies heavily on the software evidence.

Buyers should assess the risk profile of their specific product. If the software failure could lead to patient harm, demand detailed IEC 62304 documentation. If the failure would only affect convenience or data logging, the requirements may be less stringent, but still present.

Practical Steps for Supplier Evaluation

1. Request the ISO 13485 certificate and verify the scope of certification.
2. Ask for the software risk classification statement based on IEC 62304.
3. Request a sample software requirements specification and the corresponding test report.
4. Review the change control procedure for both hardware and software.
5. Ask for the post-market surveillance plan, including how software updates are managed.
6. Conduct a joint review with the supplier’s quality and software engineering leads.
7. Verify that the supplier has a defined process for handling field complaints related to software.

These steps help you move beyond certificate checking. You are evaluating the depth of the quality system. You are checking if the supplier has the capability to manage the complexity of integrated devices.

Conclusion of Evaluation

The distinction between ISO 13485 and IEC 62304 is fundamental to modern medical device sourcing. ISO 13485 ensures the physical product and the organization are controlled. IEC 62304 ensures the software is controlled. A supplier that cannot articulate the difference between these two frameworks is likely to have gaps in its quality system.

When you evaluate a supplier, look for evidence that both systems are integrated. Look for cross-functional reviews. Look for a unified risk management approach that considers both hardware and software. This is how you ensure that the quality systems in place will support the safety and effectiveness of the device you are purchasing.