5 Critical CAPA Lessons From 2025
We saw a ton of CAPA systems this year. Here are a few best practices our consultants wished they saw more teams put into action.
Despite over two decades of repeated FDA emphasis, CAPA remains one of the most frequently cited causes of device warning letter observations and a top concern for Quality leaders in our own audit, remediation, and other project work.
We’ve written extensively about CAPA over the years, but when our subject matter experts have been brought in to help remediate over the past 12 months or so, we keep seeing the same gaps.
Below are five “quiet” best practices that set mature CAPA programs apart from those that look good on paper but keep generating repeat issues.
Talk to us if you need help assessing your own program, working through an end-of-year backlog (which is super common), or operationalizing these practices in your team.
1. Use CAPA selectively and ruthlessly risk-based
We’re still seeing many firms fall into one of two extremes: they either open CAPAs for almost everything, or push almost everything into other systems and rarely open a CAPA at all.
Both patterns hide risk.
One of our subject matter experts—a former FDA investigator turned consultant and with The FDA Group—stresses that your procedure must explicitly define when a CAPA is and is not appropriate, with risk at the center of that decision. We still see this seemingly simple component missing in many programs and quietly creating chaos in its absence.
“One of the most common dysfunctions I see is teams either opening CAPAs for everything or avoiding them entirely because they’re afraid of the paperwork. Both extremes create blind spots. A well-run CAPA system isn’t about volume, it’s about clarity. You should be able to explain exactly why each issue did or did not require a CAPA, and that rationale should hold up in front of an investigator.”
— Senior Consultant, Former FDA Investigator
Here’s what we see CAPA-mature teams do:
Define clear, written criteria that reserve CAPA for systemic or potentially systemic issues, serious complaints, significant field actions or high-risk single events.
Require a brief, documented risk assessment for every candidate issue, including a rationale for “no CAPA” decisions.
Route lower-risk, one-off issues to other controls (deviation, NCMR, change control) while keeping the CAPA log focused on what truly threatens patients or the business.
A question to ask this week: If an FDA investigator asked you to justify why you didn’t open CAPA for a recent high-impact issue, could you show a documented risk-based decision? We run through this in all of our relevant audits and mock inspections and very often get an awkward response from teams who haven’t matured their programs.
2. Protect root cause analysis from politics and time pressure
We always emphasize that tools like 5 Whys or fishbone diagrams will not rescue a process that is rushed or politically constrained.
Two success factors consistently determine whether teams find real root causes:
Having the right cross-functional people in the room.
Creating conditions where they can speak freely without fear or bias.
Throughout this year (and forever, actually) we’ve seen far (far) too many CAPAs where the “root cause” simply restates the problem or stops at a convenient layer (“operator error,” “training issue”) because going deeper would be uncomfortable or expensive.
A few best practices here:
Make root cause analysis a distinct, scheduled activity with protected time, not something done between other tasks.
Limit approvals to people who understand the process and have no incentive to bury bad news. This is huge.
Require explicit reference to the method used (FTA, fishbone, 5 Whys) in the CAPA record and ensure those methods are named in the procedure, so you’re not improvising under scrutiny.
A question to ask this week—specifically for the managers, directors, and VPs among us: Where in your CAPA workflow can politics or budget concerns block uncomfortable root causes from being documented?
3. Stop calling systemic problems “human error”
Genuine slip-ups happen, of course, but they are cited far more frequently than they should be. Most recurring “human errors” are symptoms of deeper issues in documentation, resourcing or culture. But we continue to see teams use it as a way to sweep bigger system fixes under the rug and blame people for system problems.
Regulators know this, and look for it. A CAPA that blames operators and prescribes retraining alone is a red flag when similar deviations keep emerging.
One client we worked with on a QMS project reported a string of “operator error” deviations on a packaging line (six similar issues in three months, all closed with retraining). When our consultant shadowed the process, the real root cause emerged within hours: the line operators were referencing an outdated, three-page paperwork instruction taped inside the cabinet, while the controlled version (now eight pages with a new in-process check) lived only in the QMS. Supply chain had stopped printing new copies because “the line already knew the steps.”
What looked like careless mistakes were actually documentation access failures. Once the instructions were updated, printed, and mounted at the point of use—with a visual step map added—deviations on that line dropped to zero for the rest of the quarter.
If this is resonating at all, please:
Treat “human error” as a starting point, not an end point. The next CAPA step is to ask why the person was set up to fail: too many tasks at once, unclear instructions, poor tooling, outdated documents.
Examine documentation processes: Are SOPs accessible at the point of use, kept current and written at the level of detail people actually need on the floor.
Watch metrics that drive behavior. Fast closure rates on deviations look efficient on dashboards but often correlate with shallow investigations and “training fixes.”
A question to ask this week: How many CAPAs closed in the last year list “human error” or “retraining” as the primary action? And how many of those problems have come back?
4. Design your CAPA forms for the people who actually use them
Compliance with relevant regulations is necessary but very often not sufficient operationally speaking. The procedure and forms also need to be usable by people who are not CAPA experts.