Making CAPA Systems Actually Work: 8 Field-Tested Answers From a Medical Device Quality Specialist

CAPA – Corrective and Preventive Action – is the systematic process required under ISO 13485 (sections 8.5.2 and 8.5.3), FDA QMSR, and EU MDR 2017/745 for identifying, investigating, and eliminating the causes of nonconformities. 

Corrective action investigates what went wrong and eliminates the cause. Preventive action identifies what could go wrong and addresses it before it does.

What follows goes beyond the textbook definition – into what actually makes these systems work in practice.

It came back.

The same problem. Six months later.

You trained everyone, updated the SOP, signed off the CAPA – and somehow, against all logic, the issue is sitting right there on the table again. Sounds familiar?

Here's what nobody tells you during CAPA implementation: the problem is almost never the procedure. It's what happens – or doesn't happen – in between.

Georg Digel has been in medical device quality since 2014. He's trained around a thousand people on NC/CAPA. He's led remediation initiatives, worked with companies like J&J and Olympus, and now helps organizations build NC/CAPA systems that hold up – through his work at Elevate CAPA. His specialty: corrective and preventive action in medical devices – specifically, why it fails so consistently, and how to rebuild it so it actually holds.

In December 2025, he ran a live Q&A with quality professionals from across the industry. What came out of it was some of the most practical, field-tested CAPA guidance we've come across. Georg shares what he has seen actually work – and fail – across hundreds of companies.

By the time you've read this, you'll know why your CAPA training isn't sticking, how to investigate complaints when the information isn't there, and what the single most impactful thing is you can do to make your whole CAPA system function better. That last one might surprise you.

Here are eight field-tested answers to the most common CAPA questions.

You've done it right. You brought in the trainer, ran the sessions, got everyone through the material. People nodded. They seemed to get it.

And then – three, maybe six months later – the same patterns are back. Superficial root cause analyses. Corrective actions that don't address the real problem. Documentation that looks like it was copy-pasted from the last CAPA. 

What went wrong?

Here's the uncomfortable truth: training was never designed to create lasting change on its own.

Georg put it directly: "If you don't have a mentoring structure and constant oversight in your company, things will get worse over time again."

Knowledge fades. Under pressure, people revert to what's familiar. That's not a character flaw – that's just how human memory and behavior work.

What actually sustains improvement is three things working together. First: initial training, to create a shared baseline. Second: a mentoring structure, where experienced people guide newer team members through real cases as they arise – not hypothetical ones in a classroom. Third: ongoing oversight, with regular reviews that catch the early signs of slippage before they turn into audit findings.

Think of it this way: training teaches what to do. Mentoring teaches how to apply it in your specific situation. Oversight ensures it keeps happening. Take away any one of the three, and the system will degrade. Every time.

One more thing worth naming: different roles need different support. A CAPA owner doesn't need the same mentoring as a quality engineer. A production operator on the floor needs different guidance than a complaints handler. One training session for everyone cannot bridge that gap – and thinking a refresher course will fix degrading performance is the most common mistake Georg sees. It won't fix it. The issue isn't that people forgot. It's that there's no ongoing practice and accountability keeping the knowledge alive.

What does this mean in practice? That CAPA is less a training problem and more a management problem. Which brings us directly to the next question – and a challenge that's even harder to investigate.

Every quality team knows this one. The complaint arrives and it says: "The product didn't work." Or: "There was an issue with the device." You try to follow up. The customer doesn't respond. The clinical context is gone. The device was already disposed of.

What do you do with that?

Georg's answer is direct: investigate with what you have, and document your limitations clearly.

That means stating upfront in your documentation what information is missing. It means doing the most thorough investigation possible with available data – and being explicit about where your conclusions are limited as a result. Every attempt to get more information from the customer should be on record: what you asked for, when you asked, and what came back – including silence.

Then use what you do have. Similar complaints. Manufacturing records. Internal test data. Design specifications. Even when an individual complaint is thin on detail, cross-referencing against similar cases over time often surfaces the real signal.

Here's what surprises a lot of teams: regulators understand this situation. Auditors don't expect the impossible. What they want to see is that you made reasonable efforts and worked systematically with what you had. Georg has been through enough audits to know this firsthand. The risk level of the complaint determines how hard you push: a potential safety issue demands aggressive follow-up, a minor usability complaint less so.

What definitely doesn't work: filling gaps with speculation, or waiting indefinitely for information that isn't coming. Both create compliance risk. Document, investigate, and move – with your limitations clearly on the record.

But what happens when the investigation doesn't point to a system problem at all? What if it points directly to a person?

An operator didn't follow the procedure. Someone made a mistake. The investigation is pointing straight at an individual. So the CAPA is retraining, right?

Stop right there.

This is one of Georg's strongest convictions – and it's backed by years in the field: human error is almost never the root cause. It's a symptom. The root cause is the system that made the error possible in the first place.

Before anyone writes "retraining" into a CAPA, push through these questions:

• Was the work instruction actually clear? 

• Could it realistically be followed as written? 

• Was the person properly trained and confirmed competent before being assigned the task? 

• What were the conditions – time pressure, distractions, competing priorities? 

• Could the task be simplified or mistake-proofed?

• Were there any verification steps that should have caught the error before it became a problem?

Retraining might be part of the response. But only as a secondary measure, after system-level changes have been made. If someone made an error once, they can make it again – even after retraining – if nothing about the conditions has changed.

There's a culture dimension here too, and it matters more than most teams realize. Georg has watched it happen repeatedly: "If people errors always lead to actions focused on the individual, people stop reporting problems." Blame culture doesn't improve quality. It drives problems underground – where they grow until they're much harder to fix.

The only case for individual-focused action is genuine evidence of willful non-compliance, or a demonstrated inability to learn the task. And even then – that's an HR matter, separate from the CAPA entirely.

So now you understand the depth a good investigation requires. But here's the tension every quality team faces: thorough investigations take time. And time is exactly what everyone is asking you to cut.

Customers want answers now. Production wants to restart. Management wants the backlog cleared. And you're sitting there knowing that a rushed investigation is going to miss the root cause – and create even more work six months from now.

How do you hold the line without drowning?

The answer: stop treating every CAPA the same way.

Not all issues carry the same risk. Not all investigations need the same depth.

A risk-based tiering system is what makes both speed and quality achievable at the same time. Safety concerns and major defects get full investigation – all the root cause tools, extensive documentation, thorough review. Quality concerns and performance issues get a standard investigation proportionate to their complexity. Minor issues – cosmetic defects, documentation errors – may only need a correction, not a formal CAPA at all.

Within that framework, set timelines based on actual complexity – not arbitrary rules. If your procedure says 30 days but complex investigations consistently take 90, the procedure needs updating. Not the investigation. Use templates to streamline documentation, not to replace thinking. Run containment actions in parallel with the investigation, not after it.

And here's the distinction that changes how the pressure feels: speed of response – acknowledging the issue, containing the risk, communicating with stakeholders – is entirely separate from speed of investigation. You can be fast with the first and still be rigorous with the second. They are not in conflict.

Warning signs you're compromising quality: investigations always conclude with "retraining" regardless of the issue. Root cause sections contain vague filler text. Corrective actions don't visibly connect to identified causes. If any of that sounds familiar – it's worth addressing before the next audit surfaces it for you.

Now, there's a question that comes up constantly when teams start to get their CAPA process under control: should CAPA and Change Control be the same process or different ones?

This one causes a surprising amount of confusion.

CAPA findings often trigger changes. Changes can create new problems requiring CAPAs. The two processes are clearly connected. So why not run them together?

Because they answer completely different questions.

CAPA asks: what went wrong, why did it happen, how do we prevent it from occurring or recurring, and did our actions actually work? 

Change Control asks: is this change safe, has it been properly evaluated, and is implementation being managed correctly? 

When a CAPA determines that a process change is needed, that change flows into change control. The CAPA documents the why. Change control handles the how. They reference each other but they remain separate records with separate purposes. CAPA is usually triggered once you react to existing quality issues or identify potential new ones. Change control is expected as part of your routine business. Combining them creates confusion, and Georg has seen that confusion cost teams dearly during audits.

There's a timing trap worth calling out specifically: CAPA effectiveness can't be assessed until a change implemented through change control is fully complete and verified. If your SOP doesn't account for that timing, you risk closing CAPAs before effectiveness can genuinely be confirmed. That's exactly the kind of gap that produces findings.

A simple red flag to watch for: if your team routinely struggles to decide whether to open a CAPA or a change control, your procedures aren't clearly defining the distinct purpose of each. That ambiguity needs to be fixed at the procedural level – not managed case by case.

But even well-defined processes can create a new problem: over time, CAPA starts to feel like busywork – which brings us to the next question. 

Here's a picture too many quality professionals will recognize.

The CAPA system is full. Forms are completed. Fields are filled. Investigations are written up. And the same problems are recurring – because nobody is actually solving anything. They're documenting it.

How did CAPA become theater?

Usually gradually. A field gets added. Then another. A specific tool gets mandated. Approvals multiply. And at some point, the investigation stops being about finding the root cause and starts being about navigating the system. Teams start writing whatever gets it closed, not whatever is true.

The fix is almost always subtraction, not addition.

Strip out requirements that don't add investigation value. Stop mandating specific root cause tools when the complexity of the issue doesn't call for them. 

Bring it back to four core questions: 

1. ​​What was the problem?

2. What caused it directly?

3. What underlying causal chains allowed it to happen?

4. Which of the causes if eliminated will most likely prevent it from happening?

Then change how CAPAs are reviewed at the leadership level. If management consistently asks "how many CAPAs are open?" rather than "what are we learning from our investigations?", the team hears a clear signal: closure is what matters, not quality. Georg worked with senior leaders who genuinely wanted to improve the quality culture. But it's not enough to just talk about it - you need to live it.

Culture follows behavior.

Share learnings across departments. Highlight the investigations that prevented major issues. Connect quality work to patient outcomes. When people see that CAPA actually makes things better – rather than just creating documentation – something shifts.

And remember – you can always improve things outside of CAPAs or before bad things happen. This is the real continual improvement that so many companies strive for – and if you document it as a preventive action, you can show it proudly in your next audit or investigation.

The fundamental move: from "CAPA is something quality makes us do" to "CAPA is how we solve problems." That sounds like a small reframe. The effects on team engagement are anything but small.

But how do you know if your CAPA system is actually where it needs to be? What does good even look like?

"Maturity" is one of those words that's easy to use and hard to define.

Companies often wonder whether they need better software, more metrics, or more detailed procedures to be considered "mature." Georg's answer reframes the whole question.

CAPA maturity isn't about tools or technology. It's about capability.

A mature CAPA system does six things reliably:

1. It has clear triggering mechanisms – people across the organization understand when to escalate an issue and when not to. 

2. It classifies issues correctly: corrections, corrective actions, and preventive actions are not the same thing, and a mature system treats them differently. 

3. It investigates effectively, finding actual root causes rather than stopping at symptoms. 

4. It resolves issues within realistic, consistently met timeframes – where delays are exceptions, not the norm. 

5. It verifies effectiveness, not just on paper, but by actually checking whether the problem recurred after the action was taken. 

6. It tracks metrics that reflect real performance: recurrence rates, time to effective solution, investigation quality – not just open CAPA counts.

What regulators – whether FDA inspectors under 21 CFR Part 820 or ISO 13485 auditors – actually look for isn't a "maturity" label. It's evidence that the system functions as intended and is appropriate for the organization's risk profile. That means a clear procedure, a demonstrated approach to triggering both corrective and preventive actions, CAPA performance metrics, discussion in management review, and evidence that actions actually prevent recurrence.

Georg's practical advice: don't try to build the perfect system overnight. Identify the area causing the most problems – whether that's the backlog, the quality of investigations, or the effectiveness verification step – and fix that first. Then move to the next.

Maturity is built incrementally. It is not installed.

All of that – the processes, the metrics, the structure – matters. But none of it is the most important factor. The answer to the last question is the one most quality leaders don't expect.

If you could only improve one thing about your entire CAPA system – what would it be?

Better software? Clearer procedures? A proper tiering system? More training?

Here's Georg's answer: hire people with the right quality mindset.

Not the most technically polished candidates. Not the ones who have memorized every root cause tool.

The ones who genuinely care about quality. Who notice problems and say something, rather than hoping someone else deals with it. Who want to understand why something happened, not just close the ticket. Who feel ownership over quality issues regardless of which department caused them.

"With the right people, CAPA becomes natural problem-solving that happens to be documented." 

Without them, you're constantly fighting to get people to follow a process they don't believe in. 

No SOP, no software, no training program overcomes a team that fundamentally doesn't care whether the problem is actually solved.

The practical implication: screen for quality mindset in every hire. Ask behavioral questions about how candidates have handled quality issues. Look for examples of proactive problem-identification, curiosity about root causes, and genuine ownership. Technical skills can be taught. Procedures can be learned.

Quality thinking – if it isn't there – is extremely hard to develop.

And for existing teams: management has to model it. If leadership doesn't demonstrate quality thinking in how they discuss problems, respond to findings, and review investigations, no amount of hiring will create a quality culture. The environment shapes behavior more powerfully than any onboarding program ever will.

1. Training alone never works. You need training plus mentoring plus ongoing oversight. Remove any one of the three and performance degrades. A refresher course will not fix a culture that has drifted.

2. Human error is a symptom, not a root cause. Always investigate the system conditions that made the error possible. Retraining is a last resort, not a first response.

3. Incomplete information is not an excuse to stop investigating. Document your limitations, use what you have, and make your attempts to gather more information visible on the record.

4. Risk-based tiering resolves the speed vs. quality tension. Match investigation depth to actual impact. Speed of response and speed of investigation are separate things – treat them that way.

5. Keep CAPA and change control separate but linked. They answer different questions. The connection point matters – especially for effectiveness timing.

6. Simplify before you add. A CAPA system that has become paperwork theater is almost always over-engineered. Strip it back to the four core questions: what, why, how, did it work?

7. Maturity is capability, not complexity. Software and metrics support a good process. They do not create one.

8. Hire for quality mindset first. Hard skills are teachable. The instinct to care about whether problems are actually solved – and to speak up when they're not – is far harder to develop after the fact.

Whether you're rebuilding your CAPA system, preparing for an audit, or trying to fix recurring nonconformities – we've helped medical device teams work through all of it. Book your free 15-minute call to explore how SIFo Medical can support you