the user through the complete lifecycle. It should include sections for source of CAPA, event description, risk and impact assessment, investigation summary, root cause analysis, corrective action, preventive action, responsible person, target completion date, implementation evidence, effectiveness check and closure approval.

Basic CAPA Form Structure

A practical CAPA form may include the following sections:

• CAPA number and initiation date
• Source of CAPA
• Related deviation, complaint, OOS, audit or inspection reference
• Product, batch, equipment, system or department involved
• Problem statement
• Immediate correction or containment action
• Impact assessment
• Root cause analysis
• Corrective action plan
• Preventive action plan
• Action owner and target date
• Implementation evidence
• Effectiveness check plan
• Effectiveness verification result
• CAPA closure justification
• QA approval

This structure is simple but powerful. It makes sure that CAPA does not stop at correction. It pushes the team to think about root cause, recurrence prevention and measurable verification.

Problem Statement Example

A weak problem statement is vague and incomplete. For example:

“Operator made mistake during compression.”

This does not explain the actual failure, product impact or process context.

A better problem statement would be:

“During compression of Batch X, tablet weight variation exceeded the predefined alert limit for 18 minutes before the issue was detected. The event affected in-process control reliability and required assessment of batch impact, compression machine settings, operator monitoring, and escalation practices.”

This version is clearer because it describes what happened, where it happened, how it was detected and why it matters.

Root Cause Analysis Template

The root cause section should not simply mention one sentence. It should show the reasoning used to reach the conclusion.

A practical root cause section may include:

• Investigation method used
• Evidence reviewed
• Possible causes evaluated
• Causes ruled out with justification
• Most probable root cause
• Contributing factors
• System weakness identified

This approach helps avoid unsupported conclusions. It also shows that the company did not jump directly to human error without evaluating the system.

5 Why Analysis Example

Example event: A cleaning record was incomplete during QA review.

• Why 1: The operator did not enter the cleaning completion time.
• Why 2: The operator completed the cleaning activity but missed the final documentation field.
• Why 3: The cleaning checklist had multiple scattered entry points and no final verification prompt.
• Why 4: The checklist format was not reviewed for usability during the last SOP revision.
• Why 5: Document revision focused on procedural content but did not include user-error risk review.

Possible root cause:

“The cleaning checklist design did not provide a clear final documentation verification point, and document revision controls did not evaluate usability-related documentation risk.”

This is stronger than simply writing “operator forgot to enter time.”

Corrective Action Example

A weak corrective action would be:

“Operator retrained.”

A stronger corrective action would be:

“The cleaning checklist will be revised to include a dedicated final verification section for completion time, operator signature and supervisor verification. The revised checklist will be implemented for all relevant equipment cleaning records. Operators and supervisors using the checklist will be trained before implementation.”

This action is stronger because it corrects the document weakness, not only the person involved.

Preventive Action Example

A preventive action should look beyond the immediate record.

Example preventive action:

“A review will be performed for all active cleaning checklists used in the manufacturing area to identify similar missing verification points. Any checklist with similar documentation risk will be revised. Future document revisions for operational checklists will include a usability and error-risk review step before approval.”

This prevents similar errors across related documents and strengthens the document control process.

Effectiveness Check Template

The effectiveness check should verify whether the CAPA worked. It should not merely confirm that training was completed or that a document was revised.

An effectiveness check template may include:

• Effectiveness check objective
• Verification method
• Sample size or review period
• Acceptance criteria
• Responsible reviewer
• Target date
• Result of verification
• Conclusion

Example:

“QA will review the next ten completed cleaning records generated after implementation of the revised checklist. Effectiveness will be considered satisfactory if all required completion time, operator signature and supervisor verification fields are completed without missing entries.”

This is measurable and directly connected to the original failure.

CAPA Closure Justification

CAPA closure should not be automatic after completion of action items. The closure justification should explain why the quality unit believes the CAPA is adequate and effective.

A good closure justification includes confirmation that actions were completed, implementation evidence was reviewed, effectiveness criteria were met, no recurrence was observed during the defined review period, and no additional risk remains unresolved.

Example closure statement:

“The revised cleaning checklist was implemented on the manufacturing floor after QA approval. Training was completed for all relevant operators and supervisors. QA reviewed ten consecutive cleaning records after implementation and found no missing completion time, operator signature or supervisor verification entries. Based on implementation evidence and successful effectiveness verification, the CAPA is considered effective and suitable for closure.”

Common Mistakes in CAPA Templates

Common mistakes include using vague problem statements, writing unsupported root causes, selecting retraining as the only action, failing to assess similar systems, assigning unclear ownership, extending target dates repeatedly, and closing CAPA without objective effectiveness evidence.

Another mistake is using the same CAPA wording repeatedly across different events. This suggests that the company is filling a form rather than investigating the actual problem.

Inspection-Ready CAPA Documentation Checklist

• Is the problem statement clear and factual?
• Is the source of CAPA properly linked to the original event?
• Is the impact assessment documented?
• Is the root cause supported by evidence?
• Are contributing factors evaluated?
• Are corrective actions specific and assigned?
• Are preventive actions broader than the immediate event?
• Are target dates realistic and justified?
• Is implementation evidence attached or referenced?
• Is the effectiveness check measurable?
• Is closure justified by QA?

Practical Use of CAPA Examples

Examples are useful because they help teams understand the difference between weak and strong CAPA wording. However, examples should not be copied blindly. Every CAPA must reflect the actual event, actual evidence, actual root cause and actual risk.

The best use of examples is as a training tool. QA teams can compare weak wording with better wording and learn how to improve investigation quality, action planning and closure justification.

Conclusion

CAPA templates and examples help standardize investigation and action planning, but the real strength comes from critical thinking. An inspection-ready CAPA record should show that the company understood the failure, corrected the system, prevented recurrence and verified the result with evidence.