9.1 CAPA Process Elements & Root Cause

9.1 CAPA Process Elements & Root Cause (CQA BoK II.D.1 — Evaluate)

/practice/cqaPractice questions with detailed explanations

Audit value often peaks after the report leaves the building. Findings without effective CAPA become expensive theater: nonconformities recur, customers escalate, and management loses trust in the audit program. BoK II.D.1 sits at Evaluate level—you must judge whether CAPA elements are complete and logical relative to the finding’s significance and risk.

CAPA in the Audit Lifecycle

CAPA is not only a regulated-industry buzzword. ISO-based QMS expectations, customer contracts, and internal procedures commonly require corrective action for nonconformities. On the exam, the stem may say “corrective action,” “CA,” “CAPA,” or “action plan”—apply the same evaluation logic.

Core Process Elements You Must Evaluate

1. Responsibility and accountability

Every CAPA needs a named owner with authority and competence to drive change, plus due dates and, for complex actions, a cross-functional team. Ownership that sits only with “Quality” when the root lives in production or design often stalls.

Evaluate:

• Is the owner accountable for the process that failed (or empowered to change it)?
• Are supporting roles defined (investigation lead, data owner, training owner)?
• Is management sponsorship visible for high-risk or cross-site issues?
• Are handoffs clear when the auditee is a supplier and the customer must approve actions?

Weak pattern: “All of Quality” as owner with no single point of accountability. Strong pattern: Process owner named, QA facilitates method/evidence quality, plant manager sponsors systemic fixes.

2. Problem identification (what exactly is wrong?)

A usable problem statement is specific, evidence-based, and bounded. It restates the nonconformity in operational language so investigators solve the right problem.

Containment (immediate protection of customer/product) is often required while the problem is fully defined. Containment is not the same as corrective action. Sorting stock, quarantine, customer notification, and temporary 100% checks protect risk; they do not by themselves eliminate root cause.

Correction fixes the immediate instance (complete the missing form, rework the lot). Corrective action eliminates the root cause of a detected nonconformity so it does not recur. Preventive action eliminates the cause of a potential nonconformity. Exam stems mix these terms deliberately.

3. Root cause analysis (why did it happen?)

Root cause is the underlying reason the nonconformity occurred—often a system gap (procedure, design of work, training effectiveness, measurement, resources, culture of workarounds), not only the last person who touched the product.

Common methods (know purpose, not ritual steps):

Evaluate root cause statements against evidence:

1. Does the cause explain the observed nonconformity (and extent)?
2. If the cause were removed, would recurrence be unlikely?
3. Is the cause actionable at the process/system level?
4. Were competing hypotheses tested (data, interviews, process walk)?
5. For human error claims: were error-proofing, clarity of instructions, workload, and training effectiveness considered?

Classic shallow “causes” to challenge:

• “Operator error” / “forgot” without system analysis
• “Training” when the procedure itself is ambiguous or unworkable
• “Not enough time” without capacity, priority, or process design analysis
• “IT glitch” without configuration, validation, or access control analysis

Scenario — Root cause depth

Finding NC-2026-0412-03: Three customer complaints for wrong firmware revision on Model X shipped in Q1. Containment: stop-ship, screen WIP, notify customers with suspect serial ranges.

• Shallow CAPA: “Retrain packers; remind them to check revision.”
• Deeper analysis: Revision is not barcoded; ERP allows ship without revision match; work instruction shows obsolete screenshot; no poka-yoke at final scan.
• Root-oriented actions: Force revision scan match in ERP; update WI with current screens; add system gate that blocks ship on mismatch; verify first 30 days of shipments and complaint codes.

An auditor evaluating this package accepts the deeper package and challenges the shallow one—even if both “have a CAPA form filled out.”

4. Actions to prevent recurrence (and occurrence)

Actions should match the root cause and the risk of the finding.

Hierarchy of effectiveness (evaluate preference for higher levels when risk is high):

1. Eliminate the hazard/failure mode (design out).
2. Substitute / automate to reduce reliance on memory.
3. Engineer physical or system interlocks.
4. Administrate procedures, training, supervision.
5. Remind / warn (signs, emails)—weakest as sole control.

Temporary inspection boosts and “all-hands reminders” are often necessary interim controls but are not full CAPA if the root is process design.

5. Verification plan is part of good CAPA design

Even before II.D.3, a solid CAPA package defines how effectiveness will be checked: metrics, sample size or period, process observation, and who verifies. Missing effectiveness criteria is a red flag at plan review.

Correction vs Corrective vs Preventive — Exam Table

Note: Many organizations use “CAPA” as a combined workflow. The exam cares that you can evaluate whether actions address root cause and recurrence risk—not whether the form is labeled “CA” or “PA.”

What “Evaluate” Means for the Auditor

You are not the CAPA author of record for the auditee’s system (unless your role is defined that way). You assess:

• Completeness of elements (owner, problem, cause, actions, dates, effectiveness plan)
• Logical link: finding → cause → action
• Proportionality to risk and significance
• Independence of investigation when needed (especially when management pressure is high)
• Alignment with the auditee’s documented CAPA procedure and applicable external requirements

If the CAPA procedure itself is weak (no root-cause requirement for majors, no effectiveness checks), that may be a system finding beyond a single NC response.

Common Evaluation Failures (Memorize Patterns)

Mini Case — Evaluate the Package

Internal audit finding: Calibration overdue on three torque tools used for final acceptance (criteria: annual calibration before use). Risk: product acceptance integrity.

CAPA A: Replace stickers; calibrate the three tools; done. CAPA B: Calibrate tools (correction); quarantine product torqued since last valid date and evaluate (containment/disposition); map all acceptance tools to a recall system with auto-alerts 30 days prior; assign metrology owner; revise procedure to ban use when status ≠ current; effectiveness = zero overdue tools for 90 days and no related customer torque failures.

Evaluate: CAPA A is incomplete (correction without systemic recurrence control). CAPA B addresses problem, cause (no proactive recall/alert, weak use-control), and recurrence prevention with measurable effectiveness intent.

Link Forward

Once elements exist on paper, BoK II.D.2 asks whether the plan and schedule are acceptable and how to negotiate changes. BoK II.D.3 tests whether actions were implemented and effective. Strong evaluation at II.D.1 prevents rubber-stamping weak plans later.

Exam Anchors

• Evaluate, do not automatically rewrite the auditee’s CAPA.
• Demand root cause, not symptom restatement.
• Distinguish containment / correction / corrective / preventive.
• Prefer systemic, higher-effectiveness controls proportional to risk.
• Incomplete responsibility or vague problem statements predict ineffective CAPA—even if due dates look aggressive.