CSV Does Not End at Qualification: Periodic Review and Change Control as Common Findings

In an audit, a system is not considered validated simply because a signed validation report was on hand at go-live. It is considered validated as long as the documented state matches the actual state. This distinction is at the heart of most Annex 11 findings: initial qualification is clean, but two years of operation lie between go-live and the next inspection, during which no one maintained the validation status.

The misconception: validated is a date, not a state

In many organisations, Computer System Validation (CSV) is run as a project. There is a validation plan, a risk assessment, the qualification runs IQ, OQ and PQ, and finally a report with release. With that, the implementation is complete, the project team disbands, and the system moves into operation.

The EU GMP Guide Annex 11 (Computerised Systems), however, treats the validated state as a lifecycle, not as a cut-off date. Two sections make this explicit:

• Section 11 (Periodic evaluation) requires computerised systems to be evaluated periodically to confirm that they remain in a validated state and continue to comply with Annex 11.
• Section 10 (Change and Configuration Management) requires every change to a validated system to be controlled through a defined procedure that includes an assessment of the impact.

Anyone who treats CSV as a one-off project milestone satisfies both requirements on the day of release and then loses them step by step. It is precisely this erosion that becomes visible in the audit.

Periodic review: the most common gap after initial qualification

The periodic evaluation is the routine that demonstrates the validated state over the lifetime of a system. It reconciles what has changed since the last evaluation: changes, deviations, open CAPAs, audit trail reviews, incidents, and user and access rights changes. The frequency is not prescribed at a fixed interval but is to be set on a risk basis, often annually or on a two-year cycle, graded by GxP criticality.

In practice, this review is frequently skipped after initial qualification. Typical patterns:

• There is no procedure with a trigger and assigned responsibility, so no one schedules the review.
• The review is performed, but as a mere formal confirmation without an actual gap analysis of the documented versus the actual system history.
• The evaluation covers only some of the GxP-relevant systems because the system inventory is incomplete.

The result is a system that is nominally validated but whose validation status can no longer be demonstrated. During the inspection, the auditor discovers the discrepancy between documentation and reality at the same moment the company does, the only difference being that the auditor records it as a finding.

Change control: the gap-ridden history as a major finding

Even more immediately critical is the change control history. Section 10 requires changes to validated systems to be carried out in a controlled manner, including an assessment of the extent of requalification required. The most common error is not the deliberate circumvention of this process, but the classification of routine technical work as not regulation-relevant.

A software patch, an operating system upgrade, a configuration change, or a vendor update is treated as an administrative IT activity and deployed outside change control. The impact assessment is missing, the one that answers the question: does this change affect GxP-relevant functions, and which part of the system must be requalified? Over months, this produces a history in which the documented and the actual system state drift apart.

In the inspection context, this gap is hard to remedy because it cannot be created after the fact: a change control history that was not maintained during operation cannot be substantiated retrospectively. For this reason, it regularly ranks among the major findings for validated systems. Where, in addition, the audit trail under Section 9 is not enabled or never reviewed, the change control finding combines with a data integrity finding.

Risk-based instead of one-size-fits-all: GAMP 5

More validation effort does not automatically mean more compliance. GAMP 5 (ISPE, A Risk-Based Approach to Compliant GxP Computerized Systems, 2nd edition 2022) grades the effort by system category: from standard software through configured products such as LIMS or ERP to bespoke development. An incorrect categorisation is costly in both directions.

• Over-validation ties up resources on non-critical standard systems, resources that are then missing where they are critical.
• Under-validation lets a GxP-critical system go into operation with too little test coverage, a regulatory risk.

This logic applies not only at implementation but also determines how intensively periodic review and requalification are carried out per system. A robust risk classification is therefore the prerequisite for keeping ongoing CSV operations proportionate.

Annex 22: AI systems need an expanded framework

For AI and ML-driven systems in GxP processes, for example in quality control, in laboratory systems, or in production control, the classic CSV framework will foreseeably not be sufficient. The EU GMP Annex 22 (draft, consultation 2025) addresses an additional layer on top of Annex 11, including the ongoing monitoring of models and AI-specific change control for model updates.

An important point for context: the Annex is not yet final. Nonetheless, anyone using AI in GxP processes should align the existing CSV framework with these requirements early on, rather than retrofitting them after entry into force. An AI system changes its behaviour differently from deterministic software: a model that was valid at implementation can drift from its qualified state through changed input data. This makes the ongoing evaluation that Annex 11 requires in any case the actual core task for AI systems, rather than a mandatory exercise on a cut-off date.

The validated state is maintained in operation or not at all. In concrete terms, this means three routines that must take effect after initial qualification:

• A periodic review procedure with a defined trigger, assigned responsibility, and criteria that force a gap analysis of the documented versus the actual system history, not merely a confirmation.
• Change control with impact assessment logic that captures every change, including patches and updates, and derives the scope of requalification with a documented rationale.
• Audit trail review as a fixed routine, so that the evaluation does not first take place at the inspection.

Entourage supports these steps together with QA: from the gap analysis of the system inventory and the GAMP 5 categorisation, through the qualification documentation for critical systems, to ongoing CSV operations with periodic review and change control. For AI in GxP processes, we extend the existing Annex 11 framework with the requirements that the draft Annex 22 sets out, designed to align with the final Annex.