Hiring or looking for a job in Digital Health? Check out our Digital Health Jobs board

Articles Quality Management

Updated May 24, 2023

CAPA (Corrective and Preventive Action): What Is It and How To Be Compliant?

Dr. Oliver Eidel

So, when you start out on your exciting (yes) regulatory journey, pretty early on you’re going to come across the word “CAPA”. Seasoned regulatory professionals and consultants will casually throw it around, like “just open a CAPA for that” and they’ll feel pretty smart, while you’ll feel pretty dumb.

But worry not and look no further, today we’ll explain it, and just like all regulatory concepts, this one is so easy to understand that even your dog could become a regulatory consultant! The difficulty, as always, lies in the fact that information is scarcely available and fiercely guarded by consultants who charge exorbitant rates for explaining stuff to you.

Let’s get started!

What Is a CAPA (Corrective and Preventive Action)?

CAPA stands for Corrective and Preventive Action and, as you might have guessed, describes actions your company takes which are corrective or preventive in nature.

The requirements for CAPAs are defined in the ISO 13485 which is the standard for quality management for medical devices. While I could cite the relevant sections there and bore you to death, I’ll skip that part and show you a CAPA example which will help you understand it much better.

CAPA Example

CAPAs are a bit like todos in a project management system, or issues in GitHub, or tickets in Jira. The content however focuses on things which went wrong in your company, why they went wrong, and how you will improve them.

Let’s look at the example first before we explain some of the content further below.

CAPA Example: The Actual Example

Description: One of the software developers decided to ship an update of the medical device software to production (let’s assume it’s a web application) without going through the usual process, i.e. without the proper documentation, approvals, testing, etc. - whatever you defined in your software development SOP (you have one, right?).

Related Document / Process: SOP Software Development.

Root Cause Analysis: The software developer didn’t know about the right process, and it was technically possible to publish a software update without the proper approvals.

Actions: The proper documentation will be created for the update retrospectively and it will be tested etc. If it is deemed unsafe during this process, it will be rolled back. Additionally, better safeguards for pushing software to production and better employee training will be implemented.

Potentially Adverse Implications: None.

Deadline: Creation of proper documentation and potential rollback of the update immediately, better safeguards and employee training before the next product update.

Verification: Documentation created, employee training performed, technical safeguards implemented.

Validation: Next update was shipped according to process.

CAPA Example: Explanation

Okay, so there’s a lot going on here, but in the end it’s just a (rather boring) description and analysis of something which went wrong. In this case, your medical device consists of software and a software developer just pushed a new update to production.

While agile coaches worldwide would celebrate this as great success (“we ship every day!”), regulatory authorities of medical devices generally see this as a problem, because for each change it is expected that you create a ton of documentation. Besides whether this is good or bad (and that’s a whole separate rant-worthy discussion), the problem here is that it’s not compliant with your company’s processes and the regulatory requirements.

Aha! So from that we can already learn something: Typical triggers for creating CAPAs are when something happens which is not compliant with your own processes (your SOP documents) or with the regulatory requirements, or both.

Okay, the next step, as we can see in the example above, seems to be to do some sort of root cause analysis. There are different methods for this - personally, I like the Five Whys method because it’s quite simple (and was invented at Toyota by the way - you’re welcome, I’m happy to provide this random fact to you for some distraction). To apply it, you just ask why? five times and note down the answer. And of course you don’t provide the same answer each time, duh, but the next why? always refers to the last answer. Here’s what I mean:

Five Whys: Why was the plane forced to perform an emergency landing?

  1. Why? Because it no longer could fly at its desired altitude.
  2. Why? Because the engines stopped running.
  3. Why? Because they ran out of fuel.
  4. Why? Because the pilots ordered an insufficient amount of fuel at the last airport.
  5. Why? Because there was an error in the fuel calculation when converting between metric and imperial units.

The above example actually describes the Gimli Glider, an incident which happened for real and is definitely worth a read if you’re as interested in aviation as I am, and as disinterested in CAPAs as I am. It’s quite a feat that the pilots managed to land that airplane with both engines shut down.

Okay, back to CAPAs.. sigh. Next, you define some actions you need to take. Not much to explain here. Obviously, those actions should mitigate and possibly even prevent whatever went wrong. You also need to note down any potentially adverse implications of your actions. You wouldn’t want to make things worse, right?

Moving forward, you need to set a deadline until when these actions shall be implemented. If you start thinking that this is all terribly overengineered, I’m with you. Regarding the deadline, it can either be a fixed date in the future, or some abstract event, like the release of your next medical device version.

And finally, there’s the verification. Quality people (those people who are often detached from reality because they only care about “quality”, but have no clue how to develop real products, not unlike the hygiene people in hospitals) love to lecture you on verification and its difference to validation, but let’s not go there today and cut it short: Verification is showing that you actually did it, while validation should show that it actually achieved its goal.

In the above example, our verification is that we actually implemented our actions (duh), and the validation is that those actions actually had the desired effect, in this case that the next software update was shipped in a compliant way (and probably took forever to get done because the overhead became enormous, thank you very much, quality people).

Now you probably have a very obvious question: How the hell do you fill all of this out in one go? Commonly you wouldn’t have done your verification and validation when you’re just defining the CAPA, right? Yep, totally right! That’s why you generally don’t fill out CAPAs in one go.

You’d create one, enter the title and description, and come back later to do the root cause analysis. And then later you’d define some actions, and again later update it when you’ve verified those, etc.

And that’s it “already”. Now you know how medical device companies are able to employ large teams of regulatory people, yet get nothing done. This sort of procedures might make sense in large companies, and especially in hardware companies, but in software companies their usefulness sometimes seems as questionable as the turned-off metal detectors in the subways in the developing country I’m currently working from (not Berlin, by the way).

And that’s it about the CAPA content! Now let’s discuss how to manage CAPAs in an efficient way so that you don’t go crazy at your (presumably) small medical software startup.

Software Tools for CAPA Management

After consulting with 100+ companies, what are the typical software tools I’ve seen for managing CAPAs? Ranked by popularity, those would be:

  1. A terrible, document-based solution, e.g. in Word, Google Docs, or markdown documents in GitHub / GitLab
  2. Spreadsheets (Google Sheets or Excel)
  3. Jira or a similarly crappy ticket system
  4. Somethines fancy, either an eQMS or a self-made solution in Notion or so.

Let’s look at those in order.

CAPA Management: The Terrible, Document-Based Solution

If you’re a person who likes structure like I do, how would you organize your CAPAs? Looking at the example above, a reasonable person might think “hm, for each CAPA I have to fill out the same fields, so let’s create a spreadsheet”. Right? This would lead to a CAPA spreadsheet which is a reasonable solution.

But, for some reason which I yet have to understand, I see document-based solutions instead. Like, people would create a new document for each CAPA - literally a new Google Doc for each new CAPA, and in that, you’d have the headings “description”, “root cause analysis”, “actions”, etc.

Crazy, right? A surefire way to create a big mess. Because now you no longer have the ability to get an overview over your CAPAs - which one is lacking a root cause analysis? No clue! We need to literally open all of those damn CAPA documents to have a look!

So please don’t do this. If your consultant provides you with a CAPA template which assumes that each CAPA should be a new document, your best way forward should be to fire your consultant.

Next up, spreadsheets!

CAPA Management: Spreadsheets (Google Sheets, Excel)

Now you might think that I’d similarly dislike spreadsheets. That’s actually not true! Spreadsheets can be a surprisingly good and flexible solution for managing table-based data - like for your CAPAs. As a matter of fact, our own CAPA List Template (completely free, no strings attached!) is based on a table-like structure and we recommend you to import it into Google Sheets (or Excel, if you must).

So spreadsheets for CAPA management generally work - cool. They have some drawbacks, though. The biggest problems I usually see are:

But before talking about fancy solutions, let’s talk about Jira and similarly crappy solutions.

CAPA Management: Jira Or a Similarly Crappy Ticket System

I’ve also seen companies set up their CAPA management in Jira. This is truly the worst of both worlds: Jira is less flexible than a spreadsheet (it’s harder to change “columns”, or rather, fields), yet it doesn’t provide any useful automation - like, does it notiy you when the deadline approaches? Does it automatically calculate KPIs for you? Nope.

In addition to that, exporting your data from Jira is much harder. The typical options are badly-formatted Word or PDF documents. Ugh. Compare that to a spreadsheet: Even though a spreadsheet is not a perfect solution, you can export it in a way which looks good.

CAPA Management: eQMS Or Other Fancy Software

And finally, you could use eQMS software (that’s specialized regulatory software) to manage your CAPAs. The benefits of those are pretty much the inverse of the spreadsheet drawbacks:

Ah, and this whole eQMS discussion would not be complete without me mentioning our own eQMS software called Formwork, of course - it has all the benefits mentioned above, but above that, I think its main benefit is that it’s super intuitive to use. It guides even regulatory newbies through the process of creating (and understanding) CAPAs in a compliant manner. And in addition to that, there’s a free version and our pricing is not evil like all our enterprise competitors! Okay, end of self-promotion.

CAPA Hacks

Before we wrap up, a quick “CAPA Hack”! If you’re about to face an audit by a notified body or state authority and have some obvious deficiencies in your documentation, just open a CAPA for those - that way, they can’t give you serious findings in that area any more because you’re already handling it. I thought this was pretty cool. Like throwing pencils at bureaucrats.

Anyway, that’s it! Have fun managing your CAPAs, use our free CAPA template and, if you’re in the mood for some cool automation, check out Formwork!

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.