Checklist: Complaint File Inspection Readiness Review

This is a ready-to-use readiness check for complaint records, run before an inspection rather than during one. It has two parts: a per-file review that samples individual complaint records, and a system-level review of the things an inspector will ask about the programme as a whole. Replace every <<FILL: ...>> placeholder, set your own document numbers and dates, and route it through your normal document control before use. A worked filled specimen follows.

This document is educational and is written to be adapted. Confirm every cited regulation against the current published source, and confirm your own reporting obligations with your regulatory affairs and pharmacovigilance functions. Passing this checklist does not by itself demonstrate compliance; it surfaces the gaps you still have time to close.

The premise: an inspector will pull a small number of complaint files, usually chosen to be awkward, and read them end to end. What they are testing is whether the record shows a decision being made by a qualified person on stated facts, at each of the points where a decision was required. Files fail not because the work was not done but because the record does not show it was done. Run this check on your own files first, while you can still fix what it finds.

Use it with the complaint handling SOP, the reportability decision matrix, the investigation report form, and the trending log. For the broader inspection posture, see inspection readiness and the system-level inspection readiness checklist.

Document control header

How to use this checklist

1. Sample deliberately, not conveniently. Pull the files an inspector would pull. The sampling rule is in section 1.1.
2. Score each line Pass, Fail, or NA. NA requires a reason. A line that cannot be scored because the record is ambiguous is a Fail, not an NA: if a reviewer with full access and unlimited time cannot tell, an inspector reading it cold will not be able to either.
3. Score from the record only. Do not credit a line because you know the work was done or because the person who did it is standing next to you. If it is not in the file, it did not happen for the purposes of this check.
4. Record the evidence location for every Pass, not just for every Fail. Being able to point at the page is half of what inspection readiness is.
5. A single Fail on a critical line fails the file. Critical lines are marked with an asterisk. They are the ones that carry a patient-safety or legal-deadline consequence.
6. Findings go to CAPA, not to a list. A readiness review that generates observations with no owner and no due date will generate the same observations next quarter.

1.1 Sampling rule

Pull at least <<FILL: e.g. 20>> complaint files per review, selected to include all of the following:

Sampling only closed, tidy, confirmed complaints produces a readiness review that passes and an inspection that does not.

Section 1: Per-file review

Complete one column set per file. Reproduce the table per file, or use one row per file per line item in a spreadsheet, whichever suits your record system.

1.2 Intake and capture

1.3 Adverse event screening

1.4 Lot number and traceability

1.5 Severity classification

1.6 Reportability

1.7 Investigation

1.8 CAPA linkage

1.9 Timeliness

1.10 Reply to the complainant

1.11 Record completeness, retention, and retrievability

1.12 Per-file result

Section 2: System-level review

The per-file review tests execution. This section tests the programme. An inspector who finds tidy individual files will still ask these questions.

2.1 Procedure and governance

2.2 Trending

2.3 Thresholds

2.4 Backlog and timeliness

2.5 Classification consistency

2.6 Interfaces

2.7 System-level result

Section 3: Findings, actions, and signoff

Filled specimen

The following is a completed review, abbreviated to one representative file plus the system-level section. Company, product, people, and numbers are illustrative. It is deliberately a review that finds real problems, because a readiness review that passes everything has not been run properly.

Review header

Per-file review, file 7 of 20

Reviewer note on file 7. This file closed on time, with a good verbatim capture, a completed adverse event screen, and a well-reasoned severity. It still fails, and the reason matters: the complaint was closed as unconfirmed on the single fact that no sample was returned, with no reserve sample examined and no cluster check performed. Reserve samples were on site. A second complaint on the same lot arrived three weeks later and was closed the same way. A third arrived on 6 July with a returnable sample and confirmed a purity defect that led to a Class II recall. Both earlier files were individually honest and collectively a detection failure. This is the exact pattern the “could not confirm” line in section 1.7.13 exists to find, and it was found here about six weeks later than it should have been.

Sample-wide result

System-level review

Findings and actions

What the specimen is meant to show. The system-level controls passed almost everything: trending was performed for 24 consecutive months, thresholds were pre-defined and never manipulated, and every crossing traced to an action. The failure was entirely at the per-file level, where blank reportability branches and shortcut closures on unconfirmed complaints were routine, and in one stale document that had never caught up with two market launches. That combination is common. A programme can have an intact architecture and still fail an inspection on execution, and the only way to find out which one you have is to read your own files the way an inspector will.

Common inspection findings this checklist prevents

• Complaint files that look complete until read closely, where the reportability section is present but blank on most branches.
• “Could not confirm” closures with nothing behind them: no reserve sample, no batch record review, no cluster check, on files where all three were available.
• A decision not to investigate with no justification and no name attached.
• Severity assigned with no recorded facts, or changed after triage with no record of the original value or the approver.
• Complaints with no lot number and no evidence one was pursued.
• A reportability decision made only at closure, after the shortest regulatory clock had already run.
• A report submitted but its reference never recorded in the complaint file, so the two records cannot be connected.
• Adverse event screens left blank, so it cannot be shown the screening step was performed at all.
• Complaints closed late with extensions approved after the due date, or with no extension record at all.
• Trending performed but by raw count, or with lot-level complaints divided by total product distribution.
• A threshold crossed with no traceable consequence, or a threshold quietly raised in the review that it triggered.
• A reportability matrix that has not kept up with new markets or new products.
• No reconciliation between the complaint system and the safety database, so a case dropped between them would never be found.
• Cross-references between complaint, deviation, CAPA, safety, and recall records that do not resolve, or that point one way only.
• A self-inspection programme that samples only tidy closed files and therefore always passes.

How to adapt this checklist

1. Set the document number, owner, frequency, and reviewer-independence rule in the header. The independence rule matters: a coordinator reviewing their own files will not find these failure modes.
2. Set the sample size and the selection minimums in section 1.1 to your complaint volume. The proportions matter more than the total. If you receive 40 complaints a year, review all of them and drop the sampling table.
3. Align every line to your own SOP. Where your procedure requires something this checklist does not test, add a line. Where a line tests something your procedure does not require, either add the requirement or remove the line, but do not leave a checklist testing against a standard you have not adopted.
4. Set your own numeric limits in section 2.4 and 2.5 (backlog age, on-time closure, agreement rate, “other” share). The values in the specimen are illustrative.
5. Decide which lines are critical for your products and mark them, rather than inheriting the asterisks here. For a sterile parenteral, the sterility and field action lines carry more weight than they would for a solid oral dose.
6. Run it against real files before an inspection is announced, not after. The findings here take weeks to close, and closing them under inspection pressure is how retrospective documentation gets created.
7. Route findings that appear in more than one file to CAPA as systemic, not to the individual handler. A failure mode across multiple handlers is a procedure or form design problem.
8. Feed the results into management review with a trend across reviews, so the programme can show whether it is improving.
9. Confirm every regulation referenced in the governing documents against the current published version before issue.