Corrective action with a root-cause step
What this is: A method for closing findings that fixes the system that produced them, and the log that runs it: the instance fix, the three whys, the system fix, and the later check that the fix held.
It assumes: You receive findings. Most regulated organizations do.
Change before use: Your escalation path and who signs off on closure.
This document is the method. The log it describes is the accompanying spreadsheet — one row per finding, from any source, with the instance fix, the three whys as three columns, the system fix, and the later effectiveness check with its own date.
The figure that matters at the foot of that sheet is findings closed but never effectiveness-checked. It is the most common gap in this whole process.
Why findings recur
A finding closed by fixing the instance — the missing signature obtained, the late report filed — recurs, because the system that produced it is untouched. Reviewers notice recurrence before anything else: a repeat finding tells them the organization responds to inspection rather than operating controls. The protocol below closes the instance and the cause, and produces the record that proves both.
The protocol
Step 1 — Log it
Every finding — from a licensing visit, a monitor, an auditor, an accreditor, or your own QA sampling — enters one log within five business days, with: source, date, the finding verbatim, the affected requirement (link it to the requirement-to-evidence map row), and an owner by name.
Step 2 — Correct the instance
Fix the specific case first and record the fix. This is necessary and not sufficient.
Step 3 — Find the cause
The owner answers, in writing, the shortest useful root-cause chain — usually three whys:
- Why did this happen? (the immediate cause)
- Why was that possible? (the missing or failed control)
- Why was the control missing or failing? (the system cause — usually: no owner, no checklist, no gate, no calendar, or a workload that makes the control skippable)
If the third answer is a person’s name, keep asking — a name is almost never a system cause. The question is what allowed any person in that seat to produce the same result.
Step 4 — Fix the system
Change the thing that allowed it: add the gate, put the item on the calendar with an owner, amend the checklist, restructure the duty. Record what changed, in one sentence, in the log.
Step 5 — Verify the fix held
Sixty to ninety days later, someone other than the owner samples the process and records whether the new control is operating. Only then is the finding closed. Closure without the later check is the most common way "closed" findings recur.
The log
| # | Source & date | Finding | Instance fixed | Root cause (system) | System change made | Verified holding — date & by whom | Closed |
|---|---|---|---|---|---|---|---|
Reporting
The log’s summary — new findings, findings awaiting verification, findings closed, and any finding open past ninety days with the reason — goes to the quality committee each cycle and to the board in the committee’s report. A reviewer who sees this log operating writes fewer findings, because recurrence is what they are trained to look for.
Free to adapt and use. No registration, no fee, no attribution required. This is a working template, not legal, tax, or accounting advice — the requirements that apply to your organization are confirmed by your own counsel, auditor, and licensing authority.