Don't know where to start? Watch our free starter videos and save lots of time and consultant fees

Software Validation Procedure for ISO 13485 compliance?

Dr. Oliver Eidel


We’re currently using GitHub for our code repositories. Now we’ve heard that this sort of software needs to be “validated”. What does that mean? Do we have to write tests for it? Do we need to self-host everything, i.e., move to GitLab? What about self-developed software like an internal project management tool - we’ve heard that we have to create a ton of documentation around that so it may not be feasible. Help!

Short Answer

Don’t panic :)

Yes, you have to validate software and it feels like overhead, but it’s manageable and not a huge effort. Write down your intended use for each tool with your requirements, risks and some tests and you’re done.

Long Answer

Validation of computer software is specified in section 4.1.6 of ISO 13485:2016. The main messages there are:

So which software does this include? Software used in the quality management system is kind of a vague definition. More appropriately, you should understand this as “software which is used in developing your product”.

This includes software like GitHub, your IDE, your QMS software if you have any and maybe communication tools like Slack, if you mention those in any of your SOPs.

Why Software Validation?

Now the obvious question is: Why would anyone do this? Can’t we just use our software and get back to work?

I agree with you. As an auditor put it: “Software validation is where the 13485 went over board and became unreasonable.”. Well, thanks for that. Let’s see what we can do about it.

The goal of software validation is to ensure that crappy, broken or unnecessary software doesn’t get used in your company. Now you may think: If your employees select crappy software, haven’t you hired the wrong people in the first place? I wholeheartedly agree with you. No software validation procedure on this planet will save you when you’ve hired the wrong people.

Now I will stop ranting and tell you what you need to do to comply with ISO 13485:2016.

Software Validation Procedure

You need three documents:

Let’s see what those include.

Computer Software List

Your computer software list will look somewhat like this, I added a new entry for GitHub:

ID Name Manufacturer Bug tracker URL Needs validation? Last validation Decommissioning
1 GitHub GitHub, Inc.   yes 2020-05-17  

GitHub doesn’t have a public bug tracker of known issues list, so we just leave that out. And as it’s still in use, we don’t enter a date in the “Decommissioning” column.

We’ve just assumed that it needs validation and that we’ve validated it already on “last validation” date. Of course that’s not true, yet. I’m just skipping ahead, it’ll make sense when you’ll see what we need to enter in the validation plan:

Computer Software Validation Plan

Your plan should cover the following information:

Computer Software Validation Report

If you’ve decided to test the software, you just copy-paste the requirements here, add test procedures and acceptance criteria and go through the tests. For each test, document whether it was a Pass or Fail. Add screenshots if appropriate.

Done! That was easy. I’ll try to add a template with GitHub as an example in the future.

On a slighty different note: You want to get your medical software certified under MDR but don't know where to start? No worries! That's why we built the Wizard. It's a self-guided video course which helps you create your documentation yourself. No prior knowledge required. You should check it out.

Or, if you're looking for the most awesome (in our opinion) eQMS software to manage your documentation, look no further. We've built Formwork, and it even has a free version!

If you're looking for human help, did you know that we also provide some limited consulting? It's limited because we are not many people. We guide startups from start to finish in their medical device compliance.

Congratulations! You read this far.

Get notified when we post something new.

Sign up for our free newsletter.

Dr. Oliver Eidel

I'm a medical doctor, software engineer and regulatory dude. I'm also the founder of OpenRegulatory.

Through OpenRegulatory, I've helped 100+ companies with their medical device compliance. While it's also my job that we stay profitable, I try to dedicate a lot of my time towards writing free content like our articles and templates. Maybe that will make consulting unnecessary some day? :)

If you're still lost and have further questions, reach out any time!


If you have any questions or would like to share your opinion publicly, feel free to comment below. If you'd like to reach out privately, send us a message.

No QMS on this planet will save you from creating crappy software.