CAPA Procedure Working Template

STATUS: DRAFT EXAMPLE — NOT APPROVED — NOT EVIDENCE OF CONFORMITY Adapt this structure to approved processes, applicable requirements, product risk, and authorized roles. A completed template or passing script cannot establish compliance, close a CAPA, or replace RA/QA, management, legal, regulatory, auditor, or certification-body judgment.

Controlled-document metadata

1. Purpose and scope

• Controlled purpose: <organization-specific statement>
• Products, sites, processes, and records covered: <scope>
• Interfaces: complaints, audit, suppliers, nonconformity, risk, vigilance, design/production change, validation, training, and management review.
• Exclusions or interfaces outside this procedure: <approved rationale/evidence>

2. Roles and authority

3. CAPA intake and decision

Define controlled inputs and the approved criteria for opening, escalating, linking, combining, or declining a CAPA. Do not use an arbitrary priority label as a substitute for product/process risk and reportability review.

Each decision record must include:

• unique CAPA ID and source-event links;
• factual problem statement and known scope;
• correction/containment and evidence;
• product, patient/user, process, and regulatory/reportability impact review;
• decision owner, status, rationale, evidence, and approval.

4. Investigation and systemic extent

The record must define the method before drawing a conclusion and preserve the evidence reviewed.

Do not force a preferred root-cause method. Select and approve a method appropriate to the evidence, complexity, and risk.

5. Action planning and change control

Actions must address the supported cause or risk, include objective acceptance criteria, and route affected documents, software, validation, suppliers, products, training, risk files, and postmarket controls through approved change control.

6. Effectiveness plan and review

Define the effectiveness plan before closure.

Fail-closed gate: pending, insufficient data, or ineffective cannot support closure. Re-open the investigation/action cycle or document authorized escalation.

7. Closure, cancellation, and extension

Closure requires:

• all actions implemented with evidence;
• approved effectiveness result of effective;
• linked risk, design, production, supplier, postmarket, document, validation, and training changes completed or explicitly dispositioned;
• complete source/version references;
• closure summary, date, owner, status, evidence, and authorized approval.

Cancellation or due-date changes require a documented rationale, risk/reportability impact review, owner, status, evidence, and approval. Neither changes the need for immediate safety or regulatory action when applicable.

8. Records, metrics, and management visibility

Release checklist

• [ ] Placeholders are resolved.
• [ ] Interfaces to risk, complaints/vigilance, suppliers, design, production, validation, software, training, and change control are explicit.
• [ ] No fixed timeline is used without an approved risk/process basis.
• [ ] Effectiveness criteria are objective and approved before closure.
• [ ] Records carry owner, status, evidence, source/version, and approval fields.
• [ ] Authorized human approvers released the procedure.
• [ ] The procedure makes no compliance or certification claim.