# Root-cause analysis for a CAPA

How to find the cause that stops a nonconformity coming back, with ISO 13485 and ISO 27001 worked examples and an auditor's checklist.

Source: https://sted.digital/docs/guides/capa-root-cause-analysis · Last reviewed 17 October 2026 · Strand Guides

A good root-cause analysis finds the cause that, once removed, stops the problem coming back, and proves it with evidence. Describe the problem precisely, contain it, test candidate causes with five whys or a fishbone diagram, verify the one you choose, then pick a corrective action and check that it worked.

## When you need this

Every ISO management system standard asks the same thing when something goes wrong: deal with it, find out why, and stop it happening again. ISO 13485:2016 8.5.2 requires a documented corrective action procedure for medical devices, and 8.5.3 adds preventive action for problems that have not happened yet. ISO 9001:2015 10.2 and ISO 27001:2022 10.2 set out the same sequence for quality and information security; they have no separate preventive action clause, because risk planning in clause 6.1 now does that job.

The trigger is any [nonconformity](/docs/glossary/nonconformity): an audit finding, a complaint, a failed test, a security event. Root-cause analysis is the middle of the [CAPA](/docs/glossary/capa) process, and where most CAPAs go wrong.

This is guidance to help you understand the requirement, not legal advice.

## Before you start

You need the nonconformity record, the requirement it breaches, and access to the evidence: logs, batch or change records, tickets, the people involved. Bring one person who knows the process well and one who does not; the outsider asks the questions the insider has stopped noticing.

Budget an hour for a simple, single-cause problem. A complaint trend or a repeat audit finding can take several days with interviews.

## Steps

1. Write the problem statement. Say what happened, where, when, how often, how it was detected and which requirement it breaches. Done when someone outside the team could reproduce the facts from it.
2. Contain and correct. Stop the harm first: quarantine product, disable an account, notify a customer. Record this correction separately from the corrective action; it fixes the instance, not the cause.
3. Gather facts before theories. Build a timeline from records, not memory. Note where the problem did not happen as carefully as where it did.
4. List candidate causes. Use a fishbone diagram when several causes are plausible and five whys when one chain is clear.
5. Test every candidate against the facts. Keep only causes that explain every fact, including the places the problem did not occur.
6. Verify the root cause. Show from evidence that the cause was present every time the problem occurred and that removing it would have prevented it.
7. Look for the same cause elsewhere. ISO 9001:2015 10.2 and ISO 27001:2022 10.2 ask whether similar nonconformities exist or could occur, and it is good practice under ISO 13485 as well.
8. Choose the corrective action. Remove the cause where you can; add detection only where you cannot. ISO 13485:2016 8.5.2 asks for action proportionate to the effects of the nonconformity.
9. Define the effectiveness check before you act: the measure, the period and who checks.
10. Implement, check, and close only when the check passes. Update the risk assessment if the problem revealed an unrecorded risk.

## Five whys

Ask why the problem happened, then why that happened, until you reach a cause you control. Five is a habit, not a rule. Each answer needs evidence; without it, it is a guess.

### When to stop asking

Stop when three things hold: the cause is inside your organisation's control, removing it would have prevented the problem, and every link in the chain is supported by a record. Past that point the answers drift to "budget" or "people are busy", which are true and useless.

The common failures are stopping at "human error", following one chain when there are two causes, and different people reaching different answers from the same facts. The last one is a sign you need more evidence, not a vote.

## Fishbone diagrams

A fishbone (Ishikawa) diagram puts the problem at the head and groups candidate causes along the bones. Manufacturing teams use people, method, machine, material, measurement and environment. For information security, people, process, technology, suppliers and governance work better. Pick categories that fit the problem; they are prompts, not a form to fill.

### Picking the bones out

A finished diagram is a list of possibilities, not an analysis. Teams fail when they stop at the diagram, vote for the likeliest bone, or treat every bone as a cause needing action. Test each candidate against the facts from step 3, cross out the ones the evidence rules out, and run five whys on what remains.

## What an auditor expects to see

An auditor reads the CAPA record end to end and checks that each part follows from the one before. They look for:

- a problem statement with facts, not conclusions;
- the correction, recorded apart from the corrective action;
- the analysis itself, with the evidence for the cause you chose and why you ruled others out;
- the check for similar problems elsewhere;
- a corrective action that addresses the stated cause, not a different one;
- for medical devices, a record that the action does not harm regulatory compliance or the device's safety and performance (ISO 13485:2016 8.5.2);
- an effectiveness check with a result, dated after the action.

The most common finding is a CAPA closed on implementation, before anyone checked it worked.

## Worked examples

### ISO 13485, a sterile pouch seal failure

In-process testing finds 7 of 120 sampled pouches from three consecutive lots of a wound dressing below the seal-strength specification. Lots either side pass. The team quarantines the three lots and assesses whether any affected product has shipped, which brings in ISO 13485:2016 8.3.3 for product detected after delivery.

Five whys, with a record at each step: the seals were weak because the sealing jaw ran cold late in each shift; the jaw ran cold because its thermocouple had drifted; drift went unnoticed because the calibration interval had been extended from three months to twelve; the interval was extended in a cost review that nobody assessed against the validated sealing process (ISO 13485:2016 7.5.7). Root cause: the change-control procedure did not require an impact assessment for changes touching validated processes.

Corrective action: change control now routes any change to a validated process through a revalidation assessment, and the interval returns to three months. The similar-cause check finds two other validated processes whose calibration intervals changed in the same review. Effectiveness: no seal failures across the next 20 lots, and an audit of three months of change records.

### ISO 27001, accounts left open after people leave

An internal audit finds that 4 of 11 people who left between June and September still have active CRM accounts, 19 to 96 days after their last day. Correction: disable the accounts and check the logs for use after departure; none is found, so no incident is raised.

A fishbone diagram turns up candidates under process, technology and suppliers. The evidence rules out the leaver checklist being ignored: managers completed it every time. The checklist covers systems behind single sign-on, and the CRM is not behind single sign-on. It was bought on a team card and never entered in the asset inventory (ISO 27001:2022 Annex A 5.9). Root cause: nothing requires a new application to enter the inventory before use, and the leaver process depends on the inventory being complete.

Corrective action: new applications enter the inventory and single sign-on before go-live, or name an owner for manual removal; the leaver checklist is generated from the inventory. The similar-cause check finds three more applications outside single sign-on. The risk assessment (ISO 27001:2022 6.1.2) gains the risk, and the evidence for Annex A 5.18 (access rights) now comes from the inventory. Effectiveness: no orphaned accounts in the next two quarterly access reviews. ISO 9001:2015 10.2 follows the same shape.

## Checklist

- [ ] The problem statement contains facts, a date range, a count and the breached requirement.
- [ ] The correction is recorded separately, with its date.
- [ ] A timeline is built from records.
- [ ] Every candidate cause was tested against the facts.
- [ ] The chosen root cause is inside your control and supported by evidence at every link.
- [ ] "Human error" and "retraining" are not the answer on their own.
- [ ] Similar nonconformities elsewhere were checked, with the result recorded.
- [ ] The corrective action addresses the stated root cause.
- [ ] For medical devices, the action's effect on safety, performance and regulatory compliance is assessed.
- [ ] The effectiveness check was defined before implementation and has a dated result.
- [ ] The risk assessment was updated where the problem revealed a new risk.

## How Sted helps

Sted's knowledge base includes a Corrective and Preventive Actions record template, under its Corrective and Preventive Action Procedure.
Records are part of the Full Management System plan.
A record is opened, completed, submitted for closure and closed (or withdrawn); closure is reviewed by the document owner.
Tasks open and close themselves from the state of your documents, records and training; you rarely create them by hand.
Only evidence from the last 12 months counts towards readiness.
Audit readiness is visible to administrators only for now.
Sted does not carry out root-cause analysis; it holds the record of yours.

## Related standards

- [ISO 13485 improvement](/docs/standards/iso-13485/improvement): corrective and preventive action for medical devices.
- [ISO 27001 improvement](/docs/standards/iso-27001/improvement): clause 10 and how it links to internal audit and management review.
- [Internal audit](/docs/guides/internal-audit): where most nonconformities are found.
- [Management review](/docs/guides/management-review): where top management sees CAPA status and effectiveness.
- [Corrective action](/docs/glossary/corrective-action) and [correction](/docs/glossary/correction): the difference auditors check first.
- [Records and record templates](/docs/product/records): where a CAPA record lives in Sted.

## Frequently asked questions

Q: Is five whys enough for a CAPA?
A: Often, yes, for a problem with one chain of cause and evidence at every link. When the problem has several contributing causes, or the team cannot agree on the second or third why, use a fishbone diagram to lay out the candidates first and run five whys on the ones the evidence supports.

Q: Can human error be the root cause?
A: Rarely, and auditors will push back if it is. People make mistakes in every system; the question is why this system let the mistake through or made it likely. Keep asking until you reach something you can change, such as a confusing form, a missing check or an unrealistic workload.

Q: Do I need a CAPA for every nonconformity?
A: No. ISO 13485:2016 8.5.2, ISO 9001:2015 10.2 and ISO 27001:2022 10.2 all ask you to evaluate the need for action, so a one-off with a known cause and low impact may need only a correction. Record that decision and its reasoning, because the auditor will look for it.

Q: How long should an effectiveness check run?
A: Long enough for the problem to have recurred if the cause were still there. For a weekly process, a few cycles may do; for a quarterly access review, wait for the next two reviews. Set the period and the measure before you implement the action.