What a Deviation Actually Is
In GMP validation, a deviation is any departure from an expected result defined in an approved test protocol. When a test step in your FAT, IQ, OQ, or PQ produces an outcome that does not match the pre-approved acceptance criterion — that is a deviation, and it must be documented immediately.
The word "immediately" is not a suggestion. The moment you observe an unexpected result, the test is paused, the deviation is recorded in the Master Deviation Ledger, and no further testing on that function proceeds until QA has been notified and a classification has been made. Continuing to test through a deviation without documenting it is a data integrity violation — the kind that turns a manageable technical problem into a regulatory finding.
Deviations are not failures of the project. They are a normal and expected part of pharmaceutical validation. A competently managed deviation — documented, investigated, corrected, and closed — actually strengthens your validation package by demonstrating that the testing regime was rigorous enough to catch real problems.
When a deviation is observed: stop testing on the affected function immediately. Document the deviation in the MDL before proceeding to any other test case. Do not attempt a quick fix and re-run without recording the deviation first. An undocumented deviation discovered during a regulatory inspection is significantly worse than a documented, closed one.
Two Categories: A and B
The Master Deviation Ledger (MDL-SYS-001) classifies every deviation as either Category A or Category B. The classification is made jointly by the Validation Lead and the QA Representative — it cannot be made unilaterally by the engineer who observed the deviation.
A test case failure that directly risks patient safety, product quality, or regulatory compliance. The FDS requirement is not met. Testing is halted on the affected function.
Phase gate impact: A phase gate cannot be signed with any open Category A deviation. No exceptions without written QA Manager approval.
- GMP data not recording to historian
- Audit trail entries missing for parameter changes
- Safety interlock not functioning as designed
- Data modification possible without audit trail entry
- Access control bypass — unauthorised role access confirmed
A non-critical finding that does not risk patient safety or product quality. May be a cosmetic issue, documentation gap, or non-GMP functional deviation.
Phase gate impact: Non-blocking — documented and carried to the next phase with QA acceptance. Must be resolved before the Validation Summary Report is approved.
- Typographical error in a protocol or document
- Unit label incorrect on a non-critical display
- Non-GMP report formatting error
- Cosmetic alarm colour inconsistency
- Non-critical HMI navigation issue
The engineer cannot classify their own deviation as Category B to avoid halting the test plan. Classification requires the Validation Lead and QA Representative together. If there is disagreement, the higher classification applies until investigation confirms otherwise. Downgrading a deviation from A to B after the fact requires documented root cause justification and QA sign-off.
The 7-Step Handling Process
The deviation handling process is defined in the Project Quality Plan (PQP-SYS-001) Section 8.2. Every deviation follows the same sequence regardless of category — the difference is the speed and escalation requirements for Category A.
Any team member observing a deviation must stop testing on the affected function immediately and notify the Validation Lead. Do not attempt to repeat the test informally before documenting. Do not continue to the next test step. The deviation must enter the MDL before any further action on that function.
Open a new row in MDL-SYS-001. Record: phase, protocol reference, test case ID, deviation description (what was observed vs what was expected per the protocol), the date and who observed it. The description must be factual and objective — what happened, not what you think caused it. Leave root cause blank until Step 4.
The Validation Lead and QA Representative jointly assess the deviation against the Category A/B definitions and assign the classification. For Category A: QA Manager and relevant stakeholders are notified immediately. Testing on the affected function is formally halted. For Category B: QA accepts carry-forward and testing continues on unaffected functions.
Before investigating root cause, assess three things: (a) Can testing on other functions continue, or is the deviation systemic? (b) Does this deviation affect test cases already executed — i.e., do previously passed tests need to be re-examined? (c) Is there a GMP data integrity impact — has any GMP record been affected by the failure? This last question is the most important and must be answered before the investigation proceeds.
For Category A deviations, a formal root cause analysis is required — 5-Why, Fishbone/Ishikawa, or equivalent. The root cause must be confirmed, not assumed. "Probably a software bug" is not an acceptable root cause. Once the root cause is confirmed and the correction is implemented, all affected test cases are re-executed from the beginning. You cannot patch a partial test — the complete test case must be repeated with a clean execution record.
For Category A deviations, a formal Corrective and Preventive Action (CAPA) must be raised and tracked. The corrective action addresses the specific failure. The preventive action addresses the root cause to prevent recurrence. The CAPA is maintained in the site QMS and cross-referenced in the MDL. No validation phase may be closed while a CAPA that falls within its scope remains open.
QA signs off the deviation closure in the MDL once they are satisfied that: the root cause is confirmed, the correction has been implemented and verified, re-testing is complete and passed, and (for Category A) the CAPA is raised with a scheduled effectiveness check date. The deviation status in the MDL changes to Closed. Only a QA representative can close a deviation — the engineer cannot close their own.
What Blocks Your Phase Gate
The phase gate relationship is simple: no open Category A deviations means no phase gate sign-off. This is an absolute rule. If you have a Category A deviation open at the time you want to close your OQ, you cannot close it — regardless of schedule pressure, regardless of commercial urgency.
| Phase Gate | Deviation Requirement |
|---|---|
| FAT → SAT / IQ | All Category A FAT deviations closed or formally risk-accepted in writing by QA Manager. Software version frozen with documented hash/checksum. |
| IQ → OQ | No open Category A IQ deviations. All IQ verification items complete. |
| OQ → PQ | No open Category A OQ deviations. All CAPA actions within OQ scope closed. |
| PQ → GMP Release (VSR) | All MDL deviations (both Category A and B) closed. All CAPA closed or formally risk-accepted. TM 100% complete with PASSED status on all rows. |
In rare cases, a Category A deviation may be formally risk-accepted rather than resolved — typically where the root cause is a known platform limitation with no viable engineering fix, and the residual risk has been formally assessed and accepted by QA management in writing. This is the exception, not a shortcut. The risk acceptance must be documented in the MDL, referenced in the CAPA, and approved at the appropriate level. Regulatory inspectors are familiar with this mechanism and will scrutinise its use carefully.
The Master Deviation Ledger in Practice
The Master Deviation Ledger (MDL-SYS-001) opens at the start of FAT and remains active through all testing phases until the VSR is approved. It is the single source of truth for deviation status across the project.
Every deviation gets a unique MDL reference number (MDL-001, MDL-002, etc.) that appears in the protocol execution record, the CAPA, and the VSR summary table. When an inspector reviews your validation package, the VSR references the MDL, the MDL references the protocol, and the protocol shows the executed test case — the full chain of evidence is auditable in both directions.
- One MDL per system per validation project — not one per phase. All FAT, IQ, OQ, and PQ deviations live in the same ledger.
- Never delete or overwrite a row — if a deviation was raised and later classified incorrectly, add a correction entry. The original record must be preserved.
- Status must be current — the MDL is a living document. An inspector can ask to see it at any point during testing. A stale MDL with deviations showing as "Open" that were actually resolved weeks ago is a finding in itself.
- The VSR deviation summary is generated from the MDL — if the MDL is incomplete, the VSR will be too. Maintain the MDL throughout the project, not as a clean-up exercise at the end.
MDL-SYS-001 is a pre-structured Excel workbook with the full deviation log, category definitions, and a dashboard showing open/closed counts by phase and category. PQP-SYS-001 Section 8 contains the full deviation handling procedure with the 7-step process and phase gate requirements shown in this article. Both documents are ready to use — no blank-sheet-of-paper problem.