CAPA Process Steps: Roles & Approvals

A CAPA report can have every section an auditor wants to see and still fall apart in practice — because the six sections describe what the record has to contain, not who does the work, who has to sign off before the next step starts, or what happens when a step doesn’t pass. This guide covers the CAPA process itself: the sequence of six stages from identification to closure, who owns each one, and the approval gate that has to clear before work moves to the next stage.

If you’re building the actual report template — problem statement, extent-of-condition, root cause, action plan, effectiveness criteria, closure approval — see CAPA Report and Plan Structure. That page covers what each section of the written record has to demonstrate. This one covers the workflow that produces it.

The six stages, and why the handoffs matter more than the labels

Every functioning CAPA system runs the same six stages — identify, investigate, plan, implement, verify effectiveness, close — regardless of what a given organization’s SOP calls them. What separates a CAPA system that survives an inspection from one that doesn’t is rarely the stage names; it’s whether each stage has a distinct owner, whether that owner hands off to someone else (not themselves) at the next gate, and whether the record shows the gate was actually cleared rather than assumed. A CAPA (Corrective and Preventive Action) that skips a handoff — the same person investigates, approves their own plan, and verifies their own fix — is a common root cause auditors cite when a corrective action turns out not to have worked.

1. Identify: opening a CAPA and the triage decision

A CAPA doesn’t start from a blank page; it starts from a trigger — a nonconforming test result, a customer or patient complaint, an internal or supplier audit finding, a trend flagged in periodic quality review, a regulatory inspection observation, or a deviation that couldn’t be dispositioned as a one-off. Any employee can typically raise the trigger, but opening a formal CAPA (as opposed to handling it as a simple correction) is a distinct decision, usually made by Quality Assurance, based on a quick risk/impact triage: does this affect product quality, patient safety, or regulatory compliance in a way that needs a documented, root-cause-driven response, or is it a one-time, low-risk fix that a correction closes out on its own?

Handoff: originator raises the issue → QA makes the open/don’t-open call, assigns a CAPA number and a distinct investigation owner (not the originator by default, and not the person whose work is under review, to avoid the same person investigating their own error). Skipping this triage — opening every deviation as a full CAPA, or conversely never opening one — is itself a finding auditors look for, since both directions distort whether the CAPA system is actually risk-based.

2. Investigate: who does the root-cause work, and who checks it before sign-off

The assigned investigator runs the root-cause analysis — 5-Whys, fishbone/Ishikawa, fault-tree, or a formal template, per what the record needs to show — but the investigator is rarely the sole approver of their own conclusion. Most functioning systems route the completed root-cause analysis through a QA or subject-matter-expert review before the CAPA can move to planning: does the stated cause have evidence behind it, does the extent-of-condition scope look complete, is this a symptom (e.g., “operator error”) being mistaken for a cause? That review is a real gate, not a formality — a root cause that clears this gate without genuine scrutiny is the single most common reason a CAPA gets reopened after a later, similar deviation exposes that the stated cause was never substantiated.

Handoff: investigator completes root-cause analysis → QA/SME reviews and either approves it for planning or sends it back for more investigation. Some organizations also loop in the process/department owner at this stage, since they typically have the operational context to know whether a proposed cause actually fits how the work is done.

3. Plan: who drafts the action plan, and who has to approve it before implementation starts

The action plan is usually drafted by the process or department owner — the person who actually controls the SOP, equipment, or system the corrective action will change — working from the approved root cause, not independently of it. A complete plan separates correction (fixing the specific instance), corrective action (the systemic fix in the process where the problem occurred), and preventive action (extending that fix to other processes, sites, or products where the same cause could recur), with a named owner and a due date on each line.

Before any of it is implemented, the plan itself needs sign-off — typically QA, and for anything with cost, resourcing, or cross-department impact, the relevant department manager or a management-review forum as well. This is the gate most often collapsed in practice: an action owner starts implementing before the plan is formally approved, which means if the approver later wants changes, work already done has to be redone or justified after the fact rather than reviewed before it started.

Handoff: process owner drafts the plan → QA (and management, where scope warrants) approves it → only then does implementation begin.

4. Implement: executing the plan and tracking it against the timeline

The named owner on each action line executes it by its due date; this is the stage most CAPA systems track loosely, because a report can look complete the moment items are marked “done” even though a marked-complete action and a verified, effective action are not the same claim. Sound practice tracks implementation status against the approved dates on a defined cadence (weekly or monthly, depending on CAPA volume), with QA (or whoever owns the CAPA log) escalating action items that slip past their due date rather than letting the CAPA sit open indefinitely with no visible status. If an action needs to change from what was originally approved — a different fix than the one signed off in the plan — that change routes back through the same approval the original plan needed, not through the action owner alone.

Handoff: action owner implements and reports completion → CAPA owner/QA confirms each action is actually done (not just marked done) before the CAPA can move to effectiveness verification.

5. Verify effectiveness: why this step needs a different reviewer than implementation

Effectiveness verification checks whether the corrective and preventive actions actually held, against criteria and an interval defined back at the planning stage — not decided after the fact to match whatever happened to be observed. The person best positioned to do this check objectively is usually not the action owner who implemented the fix; segregating implementation from verification (even if both sit within the same department) is what keeps the check from becoming a formality that just confirms the fix worked because the person checking wants it to have worked. A failed effectiveness check is not a footnote — it reopens the investigation stage rather than proceeding to closure, and the record needs to show that loop explicitly (which original action failed, and what happened next), not just a second attempt with no reference back to the first.

Handoff: implementation owner reports actions complete → an independent reviewer (often QA, sometimes an SME uninvolved in implementation) runs the effectiveness check at the defined interval → pass moves to closure, fail routes back to investigate or plan.

6. Close: the final approval, and who actually signs it

Closure is a distinct, dated approval — typically by a quality manager or designated CAPA approver who was not the investigator and did not implement the actions — attesting that the root cause was substantiated, the plan was fully executed, effectiveness criteria were met and documented, and the extent-of-condition scope was addressed in full. This is the same set of attestations covered in detail, section by section, in the report-structure guide; the process question here is narrower: who has the authority to make this call, and is it someone with enough distance from the earlier stages to catch a gap the people closer to the work might miss. A CAPA closed by the same person who investigated and implemented it has cleared a paperwork step, not an independent check.

Who owns each stage

Stage	Typical owner	Approval gate before moving on
Identify	Any employee raises it; QA decides whether to open	QA risk/impact triage
Investigate	Assigned investigator (not the originator or the person under review)	QA/SME review of root cause and scope
Plan	Process/department owner	QA (+ management for cost/cross-department scope) sign-off
Implement	Named action owner(s) per line item	CAPA owner confirms completion, not just “marked done”
Verify effectiveness	Independent reviewer, not the implementer	Pass/fail decision against pre-defined criteria and interval
Close	Quality manager / designated CAPA approver	Final attestation; distinct from investigator and implementer

What happens when a gate doesn’t clear

A workflow that only has a forward path isn’t a real workflow — the two most common backward loops are worth planning for explicitly rather than treating as exceptions: a root-cause review at Stage 2 that sends the investigation back for more evidence, and an effectiveness check at Stage 5 that fails and reopens the CAPA rather than closing it. Both should be visible in the CAPA log as a status, not handled informally outside the record — a CAPA that bounces between stages with no logged history of why looks, to an auditor, identical to a CAPA that was never actually managed as a process at all.

Frequently Asked Questions

How many people need to be involved in a single CAPA?

At minimum, three distinct roles across the six stages: whoever investigates and plans should not be the same person who gives final closure approval, and whoever implements the corrective action should not be the same person who verifies it worked. In a small organization the same two or three people may rotate through these roles across different CAPAs, but no one role should self-check within a single CAPA.

Can the person who caused the original problem be the CAPA investigator?

Generally no, or at minimum not the sole investigator — not as a punitive measure, but because someone too close to the original event is prone to a defensive framing of the root cause. Their input as a witness is valuable and often necessary; ownership of the investigation and its conclusion should sit with someone with enough distance to follow the evidence rather than defend a prior action.

What’s a reasonable CAPA cycle time, from identification to closure?

There’s no single regulatory number, and it depends heavily on the effectiveness-check interval chosen at the planning stage (commonly 60–90 days, sometimes longer for actions that need a full production or audit cycle to observe). What auditors look for isn’t a specific total duration but whether CAPAs are moving through the stages at a pace consistent with their own defined timelines — a CAPA log full of items open well past their planned effectiveness-check date, with no escalation, is a stronger finding than a long cycle time on its own.

Does a CAPA ever skip stages, or go straight to closure?

No — even a low-risk CAPA runs all six stages, just with less documentation depth at each one (a narrower root-cause method, a shorter effectiveness-check interval). What can legitimately be skipped is opening a full CAPA at all: a low-risk, one-off issue may be handled as a correction rather than a CAPA, which is exactly the triage decision made at Stage 1.

CAPA Process Steps: The Six-Stage Workflow, Roles, and Approval Gates

Ask about CAPA Process Steps: The Six-Stage Workflow, Roles, and Approval Gates