Everything you need to know about ISO 13485 software development

ISO 13485 is one of the most critical standards for medical devices, playing a key role in accessing the EU market. In this article, we explore the requirements and benefits of ISO 13485 software development.

TL;DR – ISO 13485 summary

If you’re developing medical devices (hardware, software, a combination), an ISO 13485 gives you a structured framework to ensure that your product is safe and effective through following a quality management system (QMS).

One of the important concepts in this standard is traceability which ensures that every feature and change can be traced back, tested, and associated with the risk management activities.

Ultimately, ISO 13485 software development supports improving quality, supporting compliance with medical device regulations, and enabling efficient collaboration across your team.

What is ISO 13485?

ISO 13485:2016 Medical devices – Quality managements systems – Requirements for regulatory purposes is an internationally recognised standard for quality management systems for companies involved in the design and manufacture of medical devices. This standard offers guidelines on ensuring that medical devices are safe and efficient (source: ISO).

In this article, all references are based on the current (as of January of 2026) edition of EN ISO 13485:2016, including A11:2021, which aligns the standard with the EU Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR). This harmonised version of the standard allows organisations to demonstrate how their quality management system supports EU regulatory requirements.

What type of organisations ISO 13485 covers?

ISO 13485 applies to all organisations responsible for the design, development, and manufacture of medical devices. The scope of the standard includes medical devices that belong to many categories – from syringe needles to medical mobile apps.

In this article, we primarily focus on medical devices that are:

• hardware-based,

• software-based, including Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD),

• or a combination of both.

In regulatory terms, any company responsible for developing a product that meets the definition of a medical device is subject to ISO 13485.

What are ISO 13485 elements?

ISO 13485 is structured into 8 main sections (and a couple of annexes) that provide detailed information on establishing and maintaining a Quality Management System (QMS) for medical device manufacturers.

The standard includes:

1. Scope – defines the applicability of the standard.

2. Normative references – provide information on related standards.

3. Terms and definitions – lists key definitions used throughout the standard.

4. Quality management system – outlines requirements for the QMS and the required documentation.

5. Management responsibility – describes the role of management in establishing, maintaining, and improving the QMS.

6. Resource management – addresses information on resources related to the organisation (human resources, infrastructure, work environment).

7. Product realisation – covers the requirements for planning and developing processes needed for product realisation.

8. Measurement, analysis, and improvement – focuses on planning and implementing measurement methods to improve the QMS continually.

9. Annex A – compares the content of ISO 13485:2003 and ISO 13485:2016.

10. Annex B – shows the relationship between ISO 13485:2016 and ISO 9001:2015.

11. Annex ZA – maps the requirements of ISO 13485 to the MDR (only available in EN ISO 13485 version).

12. Annex ZB – maps the requirements of ISO 13485 to the IVDR (only available in EN ISO 13485 version).

It’s worth noting that Clauses 1-3 are largely introductory, providing scope, normative references, and key definitions. The real “substance” of the standard is found in Clauses 4-8.

Therefore, in the following sections, we will focus on these clauses, explaining them in more detail and providing practical examples.

What is the Quality Management System in ISO 13485?

A quality management system (QMS) is a structured framework of policies, procedures, tools, roles, and responsibilities designed to help an organisation achieve its quality goals.

Those goals might include:

• improving operational efficiency,

• strengthening market position,

• delivering high-quality products and services,

• and others.

Because organisations differ in size, structure, and responsibilities, quality management systems are rarely identical. In fact, they are tailored to each organisation's specific needs. Today, we will primarily focus on ISO 13485 software development.

What are the requirements for the QMS for medical software developers?

Clause 4 of ISO 13485 covers the overall requirements of the QMS in the company responsible for any development process of the medical devices. Let’s get into this Clause.

First, you will encounter the general requirements (Clause 4.1).

The primary objective is to document a QMS and maintain it in accordance with ISO 13485 requirements. Other than that, an organisation must:

• determine the processes needed for the QMS throughout the organisation,

• apply a risk-based approach to the control of the processes,

• determine the sequence and interaction of these processes (Clause 4.1.2).

An organisation should list all the processes in the development of the medical device which affect its quality. In the case of medical software, this includes technical processes (e.g., requirements management, software design, coding, testing) and organisational processes (change control, management oversight, etc.). Together, these processes form the foundation of the QMS.

Once they do this, an organisation should take each process and define criteria and methods to ensure effectiveness.(e.g., review rules, acceptance criteria), provide necessary resources and information, monitor the performance, assign responsibilities and authorities, required resources, and maintain records that the process is performed as planned demonstrating compliance with ISO 13485.

What is Clause 4.2 in ISO 13485?

Clause 4.2 of ISO 13485 is titled “Documentation requirements”. In other words, how your QMS should be recorded and maintained so that everyone knows how processes are done and compliance can be demonstrated. Why is it crucial? Because good documentation makes software development repeatable, auditable, and consistent. That being said, this documentation should include:

• statements of a quality policy and quality objectives – high-level objectives concerning product quality and safety that apply throughout the organisation,

• a quality manual – a document defining the scope of QMS,

• procedures and records – instructions and evidence of process execution, including software development and supporting processes, such as change management,

• documents ensuring the effective planning, operation, and control of its processes – those documents show that activities are carried out in a process-oriented and controlled manner. For medical software, these include project plans, schedules, change procedures,

• other documentation specified by regulatory requirements – anything that proves compliance with regulations and product safety, regardless of whether it concerns the code itself, testing, or other supporting processes.

What is the quality manual?

A quality manual defines the scope of the QMS and shows how it works across the organisation, including:

• which requirements of the ISO 13485 are applied in our organisation and which aren’t,

• procedures,

• description of how the different processes (like software development, risk management, quality assurance, and management processes) interact with each other to ensure product quality

For example, it might show how design and development activities connect with risk management and testing, ensuring that every step contributes to the overall quality of the medical device, and that nothing is done separately.

Should I have a medical device file?

The ISO 13485 software development process requires that, for each medical device type or family, you must create and maintain files that demonstrate compliance with ISO 13485 and applicable regulations.

These files should include a general description of the device, its intended use and labelling, product specifications, methods for measuring and monitoring, and other relevant information you will find described in Clause 4.2.3.

What control actions are demanded by ISO 13485?

ISO 13485 requires that all the documents and records must be adequately controlled. Clauses 4.2.4 and 4.2.5 specify that organisations must establish procedures to review and approve documents, preventing deterioration, loss, or unintended use of outdated documents.

For medical software companies, this means controlling traditional documents and properly documenting code and software versions. This involves applying version control to design specifications and source code, requiring approval for updated test procedures, maintaining logs, test results, release notes, and linking everything to requirements and design decisions.

Additionally, records must be retained for a defined period, often extending beyond expected lifetime of the medical software or according to applicable regulatory requirements, depending on the device classification. This guarantees long-term traceability and supports regulatory compliance throughout the product lifecycle.

What ISO 13485 demands from the company’s management?

The next step is to take a look at the top management. ISO 13485 requires that top management is actively involved in the development, implementation, and maintenance of the QMS. This involvement is not just formal – management is directly accountable for ensuring that the QMS works effectively, that resources are available, and that employees understand and follow the system.

Among the tasks that ISO 13485 sets for top management are ensuring that:

• customer needs, and requirements are met (Clause 5.2),

• quality policy applies to the purpose of the organisation, is communicated and understood by the employees, is reviewed, and others (Clause 5.3),

• the planning of the QMS is carried out to meet the standard’s requirements and quality objectives (Clause 5.4),

• responsibility and authorities are defined, documented, and communicated within the organisation (Clause 5.5),

• the management review is conducted at planned intervals, and the output of the review is recorded (Clause 5.6).

As you can see, ISO 13485 clearly shows that top management isn’t just a formal authority. They actively support that the QMS runs as intended within the organisation. Another important aspect is setting an example for employees and ensuring that everyone understands the importance of following procedures and maintaining quality. In short, top management is directly responsible for both the functioning and continuous improvement of the QMS.

What is resource management according to ISO 13485?

Once top management is actively overseeing the QMS, the next essential step is to make sure the organisation has the right resources in place. Resource management is Clause 6 of ISO 13485, which outlines the necessity of determining and providing the resources needed to:

• implement and maintain the QMS,

• meet regulatory and customer requirements.

What are resource management groups in ISO 13485?

Resources mentioned in ISO 13485 are divided into three main groups.

1. Human resources
   

   Software quality depends on people, not just code. Organisations must ensure that everyone who impacts the quality of the medical software: developers, testers, QA, and regulatory specialists are competent through education, training, skills, and experience (Clause 6.2).
   

   This includes defining competence requirements, providing necessary training, and ensuring employees understand how their work contributes to quality goals.
   

2. Infrastructure
   
   Infrastructure covers all tools and environments needed to support software development and maintain quality (Clause 6.3). Among the infrastructure, you can find workspace and offices, process equipment (e.g., development and test servers, version control systems, CI/CD pipelines, and backup solutions), and supporting services (e.g., IT, networking, and document management systems).
   

3. Work environment and contamination control
   
   To meet product quality requirements, an organisation should document requirements for the work environment, even for software teams. This clause originally refers to physical condition (personnel health, cleanliness, and clothing). In the software context, it may be interpreted as secure, controlled development and test environments, data protection, access control, and handling of corrupted builds or test data (Clause 6.4).
   

   What’s more, this part requires planning and documenting procedures for controlling contaminated products.

What does ISO 13485 require for product realisation?

Now we move on to the heart of the QMS-compliant medical software development process. Clause 7 of ISO 13485 is the section that covers product realisation, which can be divided into six parts: product realisation planning; customer-related processes; design and development; purchasing; production and service provision; and control, monitoring, and measuring equipment.

Planning of product realisation

The first stage focuses on planning the processes required to manufacture a medical device software. Based on the Clause 7.1, at this point, organisation:

• defines quality objectives and medical device software requirements,

• identifies the necessary resources – including personnel, infrastructure, tools, and supporting service,

  establishes acceptance criteria and measures – determining how to know if each process step meets its goal,

• determines which records are needed to provide evidence that the processes meet set requirements – such as project plans, development and testing schedules, risk assessments, and traceable design decisions.

  Planning ensures that software development is structured, repeatable, traceable, controlled and provides a framework for further work, making software development ISO 13485-compliant.

Customer-related process

During this step, ask yourself: what is needed to provide your customer with safe, accurate, and reliable medical device software?

To answer this question, you should determine:

• customer requirements – they may include integration with existing hospital systems, specific reporting formats, or availability requirements for clinical use.

• intended use requirements – define how the software behaves in practice, e.g., whether it supports clinical decisions or monitors patient data in real time,

• regulatory requirements – typically result in obligations such as documented software lifecycle processes, validation evidence, and cybersecurity measures,

• user training requirements – where applicable, may involve onboarding for healthcare professionals, clear user instructions, or in-app warnings to prevent misuse,

• any additional requirements – often arise from risk management and may include update procedures, audit logs, data backup, or secure handling of patient data (Clause 7.2.1).

The next part (Clause 7.2.2) covers the review of requirements related to your medical device. It includes verifying if the requirements are clearly defined, documented, and understood. This review also confirms that the organisation has the resources to meet these requirements and provide clients with safe and reliable medical device software. Remember – this process should be conducted before delivering the product to the clients.

Last but not least, ISO 13485 demands from organisations to plan and document ways of communicating with customers in terms of product information, user feedback, bug reports, and other relevant topics (Clause 7.2.3).

Design and development

Design and development are among the most essential steps in proper ISO 13485 software development. Similarly to other stages, you should plan the processes, review them, and document. But what consists of design and development?

Clause 7.3.2 – Design and development planning

The organisation must document the:

• design and development stages,

• reviews needed at each stage,

• verification, validation, and design transfer activities,

• responsibilities and authorities for design and development,

• methods to ensure traceability,

• resources needed.

When working on medical software, this typically covers activities such as requirements definition, software architecture and design, implementation, testing, release preparation, and maintenance.

This process is critical because it reduces the risk of errors, improves coordination between teams, ensures regulatory and quality requirements are met, and provides evidence for audits.

Clause 7.3.3 – Design and development inputs

Design and development inputs are the requirements that describe what the product must do and under which conditions it must operate. In the case of medical software, these inputs define both the software’s indented behaviour and its clinical, technical, and regulatory constraints.

They include:

• functional, performance, usability and safety requirements (e.g., response time, user interface functionality),

• applicable regulatory requirements,

• risk management outputs,

• lessons learned from previous similar designs.

These inputs must be clearly defined and reviewed to provide a reliable foundation for the design and development process. This way, you can ensure that your medical software can be developed in compliance with ISO 13485.

Clause 7.3.4 – Design and development outputs

Design outputs are the results of a design and development process that show how the requirements have been implemented. When it comes to medical software, they usually include architecture documents, code modules, configuration files, test scripts, and user interface specifications.

Clause 7.3.5 – Design and development review

This stage involves conducting the review check, during which the organisation evaluates whether the design and development results meet the defined requirements. And if they don’t, what improvement or corrective actions are needed?

For medical software, these reviews typically cover code, architecture, test results, user interfaces, and deployment procedures.

Clause 7.3.6 – Design and development verification

The verification process is an evidence-based activity that demonstrates that the design and development outputs have met the design and development input requirements.

Think about it this way – the team verifies that each functional requirement of the medical software has been correctly implemented by executing tests. What’s more, those tests should be documented, including the methods used, the results obtained, and the pass/fail status.

Clause 7.3.7 – Design and development validation

Design and development validation ensures that the final product actually meets its intended use and performs as required. In case of medical software, this may include functional testing, performance testing, user interface validation, and clinical evaluations.

The goal is to confirm that the software works safely and effectively in the intended environment and complies with regulatory and quality requirements.

Clause 7.3.8 – Design and development transfer

Procedures for transferring design and development outputs to manufacturing ensure that designs are checked before becoming final specifications. For medical software development, this involves confirming that code, configurations, test scripts, and deployment instructions are complete, validated, and ready for release.

Clause 7.3.9 – Control of design and development changes

Another thing an organisation should take into account is establishing procedures to manage changes to design and development. Each change should be evaluated for its impact on the medical device’s function, performance, safety, and regulatory compliance.

Every single change must be identified, reviewed, verified, validated if needed, approved and fully documented

An example might be a new feature that fixes a bug but, at the same time, affects other parts of the medical software. To maintain compliance with ISO 13485, a company should verify that it functions safely in the final system and document all necessary information.

Clause 7.3.10 – Design and development files

Lastly, organisations should maintain a design and development file for each medical device type which includes reference records demonstrating conformity to the requirements for design and development.

For medical software, this file typically includes architecture and design documents, source code or configuration snapshots, and evidence of traceability to requirements and risk management activities.

Purchasing

Clause 7.4 offers guidance on ensuring that all bought products and services meet quality requirements. As you can probably guess, the organisation is also obliged to document procedures for selecting and evaluating suppliers based on their ability to meet requirements, past performance, and the impact of their products on the final medical device.

In the context of medical software, this extends beyond physical components to include software libraries, frameworks, CI/CD tools, cloud services, and other digital solutions that can affect safety, performance, or compliance of the software.

What’s more, organisations must monitor and regularly re-evaluate these software-related suppliers, addressing any issues that may arise.

Production and service provision

Clause 7.5 ensures that medical devices are manufactured consistently and repeatably and meet defined quality requirements. Organisations must plan, carry out, monitor, and document production and service activities (i.e. process monitoring, labelling, packaging).

In practice, this means:

• Process control – planning, supervising, and monitoring software development.

• Infrastructure and environments – managing servers, CI/CD pipelines, code repositories, and test environments, including their qualification and maintenance.

• Cybersecurity and patient data protection – ensuring the software is secure and maintains data integrity, which is a practical interpretation of Clause 7.5.11.

• Process validation – verifying that each process (e.g., build, test, deploy) works as intended and produces a safe, compliant product.

• Installation, updates, and user support – controlled and documented deployment, maintenance, and support activities.

• Traceability – tracking versions, changes, tests, approvals, and linking them to design requirements.

• Customer feedback – managing client data or material and documenting feedback, complaints, or corrective actions.

Proper documentation (and traceability) helps maintain product quality, reduce errors, and support improvement, ensuring that the medical software is delivered safe and reliable.

Control of monitoring and measuring equipment

Clause 7.6 requires organisation to determine the monitoring that provides evidence of the product's conformity to the stated requirements. In the context of medical software, this means identifying all tools and systems used to verify that the software meets its requirements – such as automated test frameworks, CI/CD pipelines, test environments, and security testing tools.

These tools must be validated before use to ensure they produce reliable and accurate results. Don’t forget that you are also obliged to document the measurements and test results.

How to maintain traceability demanded by ISO 13485?

Another thing Clause 7 covers is the traceability. ISO 13485 requires organisations to document procedures and maintain records that allow products to be traced through their lifecycle (not only elements stated in Clause 7!). That includes records of components, materials, work environment conditions, and more.

Think about it this way – a medical software team keeps track of every code change by linking it to its design specification, risk assessment, and test results. Thanks to this, if a bug is found, the team can quickly see which part of the code is affected, ensuring problems can be traced and fixed.

Traceability is one of the most important elements in software development. We cover this topic in a separate article.

How does Clause 7 relate to the Software Development Lifecycle?

Clause 7 of ISO 13485 is closely related to the software development lifecycle (SDLC), as it defines how software is planned, designed, developed, verified, validated, and maintained within a controlled quality management system.

In practice, this means it sets general quality expectations such as planning, documentation, verification, validation, and change control, but it doesn’t provide detailed instructions on the actual software development process.

For organisations developing medical software, IEC 62304, complements Clause 7 by specifying the processes, activities, and documentation needed to safely manage the software lifecycle.

In fact, Annex C of IEC 62304 maps its requirements to ISO 13485 (2003 version), helping teams link the general quality framework of Clause 7 to concrete SDLC activities required for compliance medical software development.

What’s the goal of Clause 8 of ISO 13485?

Clause 8 aims to ensure that the organisation manufactures safe, compliant medical devices, systematically monitors its processes and products, and implements corrective actions. This makes the QMS a tool in a process of continuous improvement and adaptation to the company's changing needs.

What is “monitoring and measurement” in Clause 8.2 of ISO 13485?

As a manufacturer of medical devices software, you are obliged by ISO 13485 to track the performance of your QMS and your medical devices to ensure they constantly meet requirements.

A key element to achieving this is feedback. Helpful information can be gathered through many sources. Some of them are:

• complaints – you should prepare detailed procedures for receiving, investigating, and resolving issues, including software bugs or feature failures. This way of communication with clients allows you to improve your processes and products later on,

• internal audits – help verify that the QMS is compliant and effective. Those audits should be repeated in set intervals and documented in terms of their results,

• your processes and products monitoring – by observing and verifying them, you ensure that everything aligns with quality objectives.

What to do in case of nonconforming product?

In Clause 8.3, you will find guidance on ensuring that products that don’t meet quality requirements are correctly identified and handled to prevent them from being used by the customers. In terms of medical software, nonconformities should be understood in relation to release-ready software as well as software already in use.

The clause requires organisations to establish procedures for identifying, documenting, and responding to nonconformities related both to the software itself and to the processes used throughout its lifecycle.

How data analysis helps improve your QMS?

By analysing data from feedback, suppliers, audits, and other relevant sources, companies can assess the effectiveness of their QMS (Clause 8.4). For medical software manufacturers, this includes tracking user reports, bug reports, audit results, and supplier data.

The purpose is to identify processes that may not fully meet quality requirements. Once such issues are detected, the evidence gathered provides a clear, structured basis for implementing changes, improving processes, and maintaining compliance with both internal and regulatory requirements.

What Clause 8.5 means by improvement?

Clause 8.5 focuses on continuous improvement to ensure that QMS and medical device software remain effective, safe, and compliant. To achieve this, we can identify two types of actions: corrective and preventive.

Corrective actions (CA) aim to identify the cause of nonconformities (e.g., production defect, customer complaint, code bug), fix the issue, and implement measures to prevent recurrence.

On the other hand, preventive actions (PA) focus on anticipating potential problems before they occur. By analysing data from audits, post-market surveillance, and other documents, organisations can take steps to prevent possible issues from arising. Both types of CAPA actions apply to processes, as well as products, including medical software, and must be integrated into the QMS.

What’s important to remember is that improvement isn’t a one-time task but a systematic, documented process.

What are the benefits of ISO 13485 software development?

You might think about implementing ISO 13485 as a regulatory necessity, but it’s so much more. This standard created a framework for your software development, which makes your job easier and your product safer.

Improving quality and reducing risks

As part of establishing a QMS, ISO 13485 influences how a medical device is designed, developed, tested, and maintained throughout its lifecycle. This standard is built on risk-based thinking, which calls for early identification of potential hazards, software bugs, and cybersecurity risks. Such an approach reduces the likelihood of product failures and improves patient safety.

Getting closer to MDR and IVDR

Both the Medical Device Regulation (MDR) and the In Vitro Diagnostic Regulation (IVDR) require manufacturers to implement a quality management system. While neither regulation explicitly requires compliance with ISO 13485, the standard is harmonised with both the MDR and the IVDR.

Thus, establishing a robust QMS is a fundamental step toward certifying a product as a medical device within the EU. In this context, adopting the ISO 13485 standard might be the most practical approach.

Brand trust and market credibility

One of the key benefits of ISO 13485 compliance is building a strong brand image as a trustworthy organisation committed to maintaining the highest quality standards. Obtaining ISO 13485 certification sends a clear message to patients, healthcare professionals, and business partners that your products and services meet safety and quality requirements.

As a result of ISO 13845 needing an annual audit by a notified body, stakeholders can be confident that certification wasn’t a one-time achievement but an ongoing commitment to continuously monitor, improve and maintain quality, safety, and regulatory compliance.

Efficient collaboration in the team

ISO 13485 requires clearly defined roles, responsibilities, and procedures for everyone involved in the project, including external suppliers. Maintaining a structure improves internal communication by providing a clear framework for developers, testes, and quality managers. While effectiveness and communication depend on proper implementation and team training, a well-implemented system guides the team in what to document and how to act, reducing uncertainty and making collaboration smoother.

ISO 13485 software development – what to remember?

Key takeaways of ISO 13485 are:

• clearly define roles and responsibilities,

• document and control the medical device development process (traceability is your friend!),

• take a risk-driven approach,

• bear in mind ISO 13485 demands continuous oversight and improvement.

Both you and your partners, critical suppliers (such as software development companies) must be ISO 13485 certified to make sure that you can safely introduce your medical device to the EU market.

At Revolve Healthcare, an ISO 13485-certified software development company, we support companies developing medical devices by providing support from our in-house Regulatory Affairs Team. This way, we ensure your software is safe to use and meets all MDR requirements.

How does ISO 13485 relate to other relevant standards?

When reading about ISO 13485, you might come across many other relevant standards and regulations. Some of them are complementary to each other, while some might relate to something slightly different.

MDR vs ISO 13485

Medical Device Regulation requires medical device manufacturers to establish, implement, and maintain a Quality Management System. Although it isn’t stated that you need compliance with ISO 13485, the standard is harmonised with the regulation. As a result, implementing ISO 13485 is recognised as an effective and practical way to meet many of MDR’s QMS-related requirements.

Read more about medical software certification according to MDR here.

IEC 62304 vs ISO 13485

IEC 62304 is an international standard that defines lifecycle requirements for medical device software. It builds on and extends Clause 7 of ISO 13485, providing guidance on how the general quality framework should be applied to software development maintenance.

While ISO 13485 establishes quality management requirements at the organisational level, IEC 62304 shows how these requirements of product realisation are implemented in the processes, documentation, and controls necessary to produce safe and compliant medical software.

Learn more about IEC 62304 in our article.

ISO 9001 vs ISO 13485

ISO 9001 is a generic standard on establishing a quality management system applicable for all the organisations, no matter the industry. But ISO 13485 is specific for companies related to medical device development. Also, ISO 1384 comes from ISO 9001, so they have the same basis. In Annex B of ISO 13485 you will find more information on ISO 9001 vs ISO 13485.

How to become ISO 13485 certified?

First, check which version of ISO 13845 is currently in force. For manufacturers on the European market, as of Feburary 2026, the European edition EN ISO 13845:2016 with an amendment A11:2021 and corrigendum AC:2018. We recommend using the consolidated European version, which includes all amendments and corrigendum.

Once you buy ISO 13485, you begin the process of developing a QMS based on the requirements stated in the document. It takes many resources – time, people, engagement of the top management. That’s why we recommend that you get support from regulatory specialists who know the ins and outs of ISO 13485 and can guide you through this process without a hitch.

When you have your QMS established, you will need to undergo an audit by the notified body (including a documentation review and an on-site audit). Certification is issued for three years. But remember that you have to undergo a surveillance audit by the notified body every year. And in year three? A full recertification audit.