Production incident evidence: from root cause to CAPA, not just a postmortem

Practice · Incident Evidence & CAPA

A postmortem in a wiki is not CAPA: ISO 13485:2016 §8.5.2, which replaced former 21 CFR 820.100 under the QMSR, requires corrective action without undue delay, so a CAPA record should carry your procedure's own deadline, such as root-cause investigation within 30 days, plus a verified corrective action, a preventive action scoped beyond the one incident, and an effectiveness check.

What does CAPA require after a production incident?

A postmortem in a wiki is not CAPA. ISO 13485:2016 §8.5.2 requires root-cause investigation, a verified corrective action, a preventive action scoped beyond the one incident, and an effectiveness check.

A postmortem document that lives in a wiki is not CAPA. Corrective and Preventive Action — the actual quality-system requirement behind incident response (ISO 13485:2016 §8.5.2, former 21 CFR §820.100) — requires a documented root cause, a corrective action that's verified to work, a preventive action scoped beyond the one incident, and an effectiveness check. Each of those is a checkable claim, not a narrative.

A postmortem and a CAPA record are not the same artifact

A postmortem narrates what happened. For MedTech quality systems under ISO 13485 §8.5.2, CAPA — Corrective and Preventive Action — is a specific quality-system obligation with four distinct, checkable parts: a documented root cause (not just a symptom), a corrective action with verification that it worked, a preventive action scoped beyond the single incident, and a later effectiveness check. A wiki page that only narrates the incident satisfies none of these on its own.

Root cause, not the first plausible explanation

"The alarm didn't fire because the process stalled" is a proximate cause, not a root cause. A 5-Whys pass (worked example below) usually surfaces that the real root cause is a process gap — a missing step that would have caught the issue — not a one-off coding mistake. Preventive action aimed at the coding mistake fixes one incident; preventive action aimed at the process gap prevents the next one too.

Append-only incident records, not editable postmortems

Consistent with sovereign, tamper-evident evidence elsewhere in a regulated SDLC: an incident record and its CAPA should be written once and appended to (a new entry when status changes), never edited in place — so "when was this incident actually closed, and what changed between draft and final" is itself provable, not a matter of trusting the last editor.

CAPA record template

Six sections, plus a worked 5-Whys example. Full template downloadable below.

1. Problem statement    -- observed symptom, not assumed cause
2. Root cause analysis  -- method + evidence, not the first guess
3. Corrective action    -- fix + verification it worked
4. Preventive action    -- scoped beyond this one incident
5. Effectiveness check  -- how and when verified
6. Sign-off             -- prepared by / quality reviewed by / closed date

Engineering reference only. Not formal regulatory counsel. Consult ISO 13485:2016 §8.5.2 (former 21 CFR §820.100, replaced under the QMSR) directly and your own quality system.

Artifact: capa-record-template.md

Generated client-side; no server round-trip, no account required.

# CAPA Record Template (Corrective and Preventive Action, v1.0.0)

Engineering reference template, structured per ISO 13485:2016 §8.5.2-§8.5.3 (former 21 CFR §820.100) CAPA expectations. Not formal regulatory counsel.

## 1. Problem statement
- Incident ID / reference:
- Date detected:
- Description (observed symptom, not assumed cause):

## 2. Root cause analysis
- Method used (e.g. 5 Whys, fishbone):
- Root cause identified:
- Evidence supporting this root cause (log excerpts, test results):

## 3. Corrective action
- Action taken to fix the immediate occurrence:
- Verification the corrective action worked:

## 4. Preventive action
- Action taken to prevent recurrence (process/design change, not just a
  one-time fix):
- Scope: does this preventive action apply to other components/products
  with the same root cause?

## 5. Effectiveness check
- How and when effectiveness will be (or was) verified:
- Result:

## 6. Sign-off
- Prepared by:
- Quality reviewed by:
- Closed date:

---

## Worked 5-Whys example
1. Why did the alarm fail to trigger? -- The alarm subsystem process had stalled.
2. Why did it stall? -- A watchdog was not configured for that subsystem.
3. Why was no watchdog configured? -- The subsystem was added after the
   original watchdog coverage review and never re-reviewed.
4. Why wasn't it caught at review? -- No process step re-triggers a watchdog
   coverage review when a new subsystem is added.
5. Why does no such step exist? -- Architecture change process doesn't
   include a safety-coverage checklist. <- root cause: process gap, not a
   one-off coding mistake.

Download capa-record-template.md

Provenance & review state

Last reviewed

September 11, 2026

Sources

• ISO 13485:2016 §8.5.2 (former 21 CFR §820.100, replaced under the QMSR) — International Organization for Standardization
• Former FDA 21 CFR §820.100 (in force until February 2, 2026) — U.S. Food and Drug Administration
• ISO 13485:2016 §8.5 — International Organization for Standardization

Ingested from