Validation Deviation / Discrepancy Record

This is a ready-to-use validation deviation record. A deviation here means any departure from a validation protocol: a test step that failed, an actual result that did not match the expected result, a step that could not be executed as written, a protocol error found during execution, or any unplanned event affecting the validation. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your objective evidence, and route the record through your normal review and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

1. Purpose of this record

This record captures a single deviation or discrepancy found during validation, classifies its severity, assesses its impact on the validation conclusion, documents the investigation and root cause, records the resolution, and links to any retest. One record covers one deviation. Do not bundle unrelated deviations into one record, and do not edit the original protocol page to make a failure disappear. The original observation stays as recorded, and this record carries the explanation.

2. Deviation description

Describe exactly what happened, in fact-only terms, before any interpretation. State what was expected, what was actually observed, and where in the protocol it occurred. Attach the objective evidence (screenshot, printout, raw data, photo) and give it an attachment number.

3. Immediate actions

State what was done at the point of discovery to contain the situation and preserve evidence. Stopping a test, marking a step “see deviation VD-xxx”, and quarantining the affected configuration or data are common immediate actions. Immediate actions are containment only; they are not the root-cause fix.

4. Classification

Classify the deviation by its effect on the validated state, on data integrity, and on product or patient. Use the table below as the default rule set and record the basis for the level you chose. Classification drives the depth of the investigation and the approvals required, so it is set by QA, not by the tester alone.

5. Impact on the validation

State whether the deviation affects only the failed step or extends to other test cases, requirements, the traceability matrix, or the overall validation conclusion. A deviation in one function can invalidate every test that depends on that function, so the scope is assessed deliberately, not assumed to be local.

6. Investigation and root cause

Investigate to a verified root cause, not a restated symptom. “The test failed” is a symptom; “the date-format setting was left at the default and the field rejected the regional format” is a root cause. Record the method used (for example the five-whys or a fishbone) and the evidence that confirms the cause.

7. Resolution and corrective action

Record what was changed to resolve the deviation and, where the root cause could recur, the corrective action to prevent recurrence. A protocol error is resolved by a controlled protocol correction or addendum, not by overwriting the page. A software or configuration defect is resolved through change control, with the change reference recorded here.

8. Retest

A Critical or Major deviation is not closed until the corrected condition is re-tested and passes against the original acceptance criterion. Reference the retest here. The retest is executed under the same protocol or a controlled addendum, with its own evidence.

9. Acceptance criteria for closing this record

This record may be closed only when all of the following are true:

• The deviation description, classification, and impact assessment are complete and consistent.
• The root cause is verified and evidenced, not a restated symptom.
• The resolution is implemented, with change control or protocol addendum referenced where applicable.
• For Critical and Major deviations, the retest is executed and passed against the original acceptance criterion.
• The effect on the overall validation conclusion is stated and accepted by QA.
• All objective evidence is attached and legible.

10. References

21 CFR 211.100 and 211.192 (production controls and investigation of discrepancies). 21 CFR Part 11 (electronic records and signatures). EU GMP Annex 11 (Computerised Systems) and Annex 15 (Qualification and Validation), 2015 revision. 21 CFR Part 820 (QMSR, effective 2 Feb 2026, incorporating ISO 13485:2016 by reference) for device software. ISO 13485:2016 (clause 8.5 on corrective and preventive action) for medical devices. IEC 62304 for medical device software lifecycle, where applicable. GAMP 5 (Second Edition) for the validation lifecycle and handling of test discrepancies. ICH Q9 (Quality Risk Management) for the risk basis of classification. FDA Computer Software Assurance guidance (current version issued 3 February 2026) for the risk-based testing context.

Confirm the current version and clause numbers of each reference before issue.

11. Approvals

Validation deviation log (register)

Maintain one running log per protocol or per validation project so an inspector can see, at a glance, every deviation raised, its class, and its disposition. The individual records above are the detail; this log is the index.

Filled specimen

The following shows the record completed for an example deviation found while testing a laboratory information management system. The company, system, and numbers are illustrative; replace them with your own.

Header and description

Classification, impact, investigation

Resolution and retest

In this example the tester recorded the failure as fact, preserved the original protocol page, classified it Major because the rule was wrong but nothing had been released, traced it to a default configuration that the spec never overrode, fixed it through change control, raised a CAPA so the gap could not recur on the next deployment, and re-tested against the original acceptance criterion before closing. That sequence, observation to classification to impact to verified root cause to controlled fix to retest, is exactly what a reviewer expects to see.

Common inspection findings this record prevents

• A failed test step crossed out or overwritten on the original protocol page so the failure is invisible, with no deviation record.
• Deviations described as “test failed, see retest” with no root cause, so the cause could recur undetected.
• A root cause that just restates the symptom (“the system rounded incorrectly”) instead of the verified cause (a default configuration the spec never set).
• Classification assigned by the tester alone, with QA never reviewing severity, and Critical issues handled as if Minor.
• Impact assessed only on the failed step, so dependent test cases were passed even though the function they relied on was broken.
• A Critical or Major deviation closed with no retest, or retested against a quietly changed acceptance criterion rather than the original one.
• A system change made to fix a deviation with no change control reference, so the validated state was altered uncontrolled.
• No deviation log, so an inspector cannot see how many failures arose during validation or how they were dispositioned.

How to adapt this record

1. Set your deviation numbering scheme, parent protocol reference, and validation phase in the header.
2. Tune the classification table in section 4 to your own severity definitions and QMS terminology, keeping the link between class and investigation depth.
3. Point the cross-references in sections 6 and 7 to your real change control, CAPA, and protocol addendum procedures.
4. Decide your retest rule for Minor deviations and state it, so testers know when a retest is and is not required.
5. Keep one running deviation log per protocol or project and reconcile it against the individual records before issuing the validation report.
6. Confirm every regulation in section 10 against the current published version before issue.