In pharmaceutical CSV, a discrepancy is a test step result that does not match the documented expected result during protocol execution. A defect is a specific fault identified in the system software or configuration that caused a discrepancy. A protocol deviation is a departure from the approved test procedure itself — for example, executing steps out of sequence or using a wrong test environment. All three require separate documentation, though a single testing event can produce all three simultaneously.
A Protocol Variance Form documents a planned or unavoidable departure from the approved test script — for example, when a test environment constraint prevents following the exact documented procedure. A Discrepancy Form documents an unplanned failure where the system did not behave as expected. The key distinction is intent: a variance describes a process deviation before or during execution, while a discrepancy captures an actual test result failure. Both require QA review but serve different purposes in the validation evidence package.
Classification should be risk-based, not administrative. A Critical discrepancy is one where the system failure could directly impact patient safety, product quality, or data integrity — for example, an audit trail not recording a data change. A Major discrepancy represents a significant gap in the system meeting a GxP requirement but with indirect risk. A Minor discrepancy has no realistic GxP impact — such as a cosmetic UI error or a non-required field behaving unexpectedly. Classification must be documented with a rationale, not assumed from the defect's appearance.
Document immediately and contemporaneously — never reconstruct a discrepancy from memory after the session ends. Record the exact actual result observed, not an interpretation of it. Include the test step ID, date, time, tester name, system version, and environment details. Describe the expected result explicitly before explaining how the actual result differed. Raise the discrepancy before attempting any corrective action, so the sequence of events is clearly captured. Assign a unique reference number that links the discrepancy to the affected test case in the RTM.
Never erase, overwrite, or correct a contemporaneous note — use a single line strikethrough with initials and date for corrections. Do not re-execute a failed test step before raising a discrepancy, as this obscures the original failure from the audit trail. Do not write subjective language such as "the system seemed to work incorrectly" — describe exactly what happened. Do not leave classification blank pending QA review. Do not pre-populate the resolution field during initial documentation — resolution is a separate activity after investigation.
No. Any test step that does not produce the expected result must be documented as a discrepancy before any corrective action or re-execution occurs. Re-running a failed test without documentation is the equivalent of destroying the evidence of a failure — which is a data integrity violation under ALCOA principles. Inspectors specifically look for test sessions where all steps passed without exception, since clean execution across an entire complex protocol is statistically implausible and suggests failures were informally resolved rather than documented.
Critical and Major discrepancies always require documented root cause analysis before closure — a statement of what failed is not sufficient; the underlying reason why must be identified and addressed. Minor discrepancies require at minimum a brief, documented explanation linking the failure to a specific cause. The investigation depth should be proportionate to the classification, but every discrepancy needs some level of causal explanation to prevent the same failure recurring in a different test case or in post-release operation.
Documentation should be contemporaneous — meaning at the time of observation, during the same test session where the discrepancy occurred. ALCOA's "C" for Contemporaneous means the record should reflect the state of the system and the tester's observation at the moment of the event, not a reconstruction from notes made hours or days later. Many organisations define a maximum window of the same business day in their SOPs, but contemporaneous documentation at the moment of the observation is the regulatory expectation.
A GMP-compliant Discrepancy Form must include: a unique discrepancy reference number, the protocol ID and test step reference, the date and time of observation, the tester's identity, the expected result as written in the protocol, the actual result observed, the system version and test environment, an initial severity classification, a description of any immediate containment action taken, space for root cause investigation, proposed resolution and corrective action, QA review and approval fields, and retest result if applicable — all with signatures and dates at each stage.
Yes, but only in specific, documented circumstances: where the root cause is confirmed to be a test script error rather than a system defect (the test was wrong, not the system), where the discrepancy is classified as Minor with a documented risk assessment confirming no GxP impact, or where the original test condition cannot be reproduced and risk acceptance is formally documented by QA. Closure without retest must never be used as a shortcut for critical or major discrepancies involving genuine system failures.
Quality Assurance must review and approve the closure of every discrepancy — this is non-negotiable regardless of severity classification. The system owner or validation lead can document the investigation and propose resolution, but QA's sign-off is the control that prevents unilateral decisions about what is acceptable. For Critical discrepancies, a senior QA representative or validation manager approval is typical. A discrepancy closed without QA sign-off has not been formally resolved and remains open from a compliance standpoint.
A discrepancy identified after protocol approval must still be formally raised and documented — it cannot be ignored because the document is already signed. The process typically involves raising a discrepancy or deviation against the archived protocol, performing a retrospective impact assessment, and determining whether the affected test case was fundamental to the validation conclusion. If it was, additional testing may be required. If not, a documented risk acceptance signed by QA is the resolution path. Retroactive discovery without documentation is a data integrity violation.
When a discrepancy is confirmed to have been caused by an incorrect expected result or a procedural error in the test script rather than the system itself, this must be explicitly stated in the root cause field: "Discrepancy caused by test script error — expected result incorrectly stated. System behaved correctly per design." The protocol must then be formally amended through change control, the corrected test step re-executed under the updated script, and the discrepancy closed referencing the protocol amendment. The original incorrect execution remains in the record.
Under FDA's Computer Software Assurance guidance, lower-risk functions may be tested using exploratory or unscripted approaches rather than pre-defined expected results. In this context, a "discrepancy" becomes any observation that the tester judges to indicate the function does not work as intended. Documentation still requires describing what was observed, what was expected based on requirements, and the tester's judgement about the impact — but the formal test-step-versus-expected-result structure may be replaced by a narrative test record summarising observations and conclusions.
The actual result must describe exactly what the system displayed or did, in objective and specific terms — not a judgement or summary. Instead of "the system failed to save correctly," write "Clicking Save produced an error message: 'Record could not be saved — connection timeout.' No record was created in the database. Error occurred at 14:37 on System X version 2.1.4." Precise, objective actual results allow root cause investigators to reproduce the failure and give inspectors evidence that the discrepancy was observed and recorded, not reconstructed.
A protocol amendment is a pre-approved, controlled change to the test script before the affected steps are executed — the SOP requires formal change control and QA approval before proceeding. A protocol deviation is an unplanned departure from the approved test script that has already occurred during execution. Amendments are proactive; deviations are reactive. Informally changing a test step without raising an amendment is equivalent to executing an unapproved procedure, which is itself a compliance finding regardless of whether the test ultimately passed.
Inspectors examine whether every discrepancy was raised promptly, classified consistently, investigated to an appropriate depth, and closed with QA approval before the VSR was signed. They specifically cross-check the discrepancy log count against the number of deviations reported in the VSR to detect undocumented failures. They also look for patterns: multiple discrepancies in the same function area may indicate a systemic issue that was not escalated, and a log with zero discrepancies across a complex system validation is a credibility concern.
The Discrepancy Form is a GxP record and must satisfy ALCOA+ principles like any other GMP document. Alterations without audit trail, backdated entries, pre-filled resolution fields, missing tester signatures, or rubber-stamp QA approvals with no evidence of review are all data integrity failures independent of the underlying technical discrepancy. Inspectors treat a poorly completed discrepancy form as evidence of a weak quality culture, since it shows the organisation's documentation practices under adversity — when something goes wrong — rather than under routine conditions.
Discrepancy data should be reviewed in aggregate at the end of each validation phase, not treated as isolated events. Recurring discrepancy types across multiple test cases — for example, repeated timeout errors or consistent audit trail gaps in certain modules — may indicate a systemic root cause requiring a CAPA rather than individual test-by-test fixes. The VSR deviation summary should explicitly state whether any discrepancy patterns were identified and whether they were escalated to the CAPA system or resolved within the validation scope with documented justification.
Discrepancy Forms are controlled GxP documents and must be stored as part of the formal validation file — either as physical controlled documents in a secure location or as electronic records under an electronic document management system with appropriate access controls, audit trails, and backup procedures satisfying 21 CFR Part 11 or EU Annex 11 requirements. Storing discrepancy forms in shared folders, email attachments, or personal drives is a data integrity exposure. Each discrepancy should be cross-referenced from the executed test protocol and from the VSR deviation summary.