Maintaining the Validated State
Keeping the validated state after everyone has moved on is periodic review, monitoring, deviations, changes, patches, calibration and maintenance — and whether the evidence still supports the claim. Validation is a statement about the present, sustained by work that is never as visible as the original project. Most loss of validated state is cumulative and undramatic: a patch here, a parameter there, discovered during an inspection rather than during operation.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 24 LINKSValidation is a claim about the present tense. Loss of the validated state is almost never one dramatic event — it is an accumulation of small changes, each defensible alone, that nobody assessed together.
06 · QUALITY MATURITY — MAINTAINING THE VALIDATED STATE, REACTIVE TO ADAPTIVE
The system was validated at implementation. Since then it has been patched, upgraded and reconfigured, and the package still describes the original.
Periodic review happens on schedule and concludes that the system remains validated, on the basis that no single change was significant.
Review examines the accumulation rather than the individual change, and infrastructure, patching and interfaces are inside the scope rather than beside it.
Drift is detected between reviews — configuration comparison, performance trending — so the review confirms what is already known rather than discovering it.
The validated state is continuously evidenced by how the system is operated and monitored, and a periodic review that found nothing is a result rather than a formality.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 4 regulatory bodies: FDA, EMA, ICH, ISPE.
RECORDS & OBJECTIVE EVIDENCE
- Periodic review records stating what was examined, not only the conclusion
- The cumulative change history since the last full assessment
- Infrastructure, operating system and patch records for the platform beneath the application
- Interface verification for connections added or altered since validation
- Backup, restore and business-continuity testing results
COMMON INSPECTION FINDINGS
- Periodic review concluding the validated state holds without stating what was examined
- Changes individually assessed as minor with no assessment of their accumulation
- Platform patching and upgrades treated as outside the validated scope
- Interfaces added after validation with no verification of the data crossing them
- Restore never tested, so the recovery path is assumed rather than demonstrated
Periodic review is the control, and it is usually a formality
EU GMP Annex 11 requires periodic evaluation of computerised systems to confirm they remain in a valid state and compliant, and Annex 15 carries the equivalent expectation for qualified equipment and processes. Done properly, a periodic review asks whether the system still does what it was validated to do given everything that has happened since — changes, deviations, incidents, patches, obsolescence, user-access drift.
Done as most sites do it, it is a form confirming that documents exist. The distinguishing question is whether the review produces findings. A periodic review programme that has generated no actions across a site in a year is not evidence of a stable estate; it is evidence that the review is not looking.
Cumulative change is the actual failure mode
Individually assessed changes are each defensible. Their aggregate is not assessed by anyone, because change control evaluates the change in front of it against the validated state as documented — which drifts a little with each approval. After thirty changes the system can be materially different from the one that was validated, with every individual change correctly approved.
This is what periodic review exists to catch, and it is why the review has to look at the change history as a set rather than confirm that each change had a record. The question is whether the accumulated configuration still matches the requirements the validation demonstrated, and it is answerable only by comparing the current state against the specification rather than against the last change.
The maintenance activities that are validation activities
Several routine activities carry validation consequences that their owners do not think of that way. A calibration found out of tolerance questions every measurement since the last good one. A patch is a change to a validated system. A restore from backup returns a system that must be verified back into its validated state. A maintenance intervention replacing a component may require requalification of the function it serves.
None of these arrive labelled as validation work, and all of them are performed by teams whose procedures may not require a validation assessment. The practical control is a defined trigger list — the events that require a validated-state assessment — embedded in the procedures of the teams that perform them rather than held only by the validation group.
SPEQ interpretation — an ageing system fails validation before it fails
Systems reach a point where the validated state cannot honestly be maintained: the platform is unsupported so it cannot be patched, the vendor no longer provides the evidence supplier assessment relied on, the people who understood the configuration have gone, and the documentation describes a system that no longer exists. Each of those is recorded somewhere as an accepted risk with a review date, and the reviews keep extending.
SPEQ’s view is that continued assurance should carry an explicit judgement, made annually and stated plainly: can the validated state of this system still be defended, and for how long? That converts a slow accumulation of accepted risks into a dated decision requiring a replacement plan or a documented acceptance at the right level — which is the conversation the extensions have been avoiding.
FREQUENTLY ASKED
What should a periodic review actually examine?
Whether the system still does what it was validated to do, given every change, deviation, incident, patch and access change since the last review — including the change history as a set rather than one by one. The diagnostic is whether the programme produces findings; a year of reviews across a site with no actions means the review is not looking.
How does a validated state degrade if every change was approved?
Cumulatively. Change control assesses each change against the validated state as currently documented, which drifts slightly with each approval. Thirty individually defensible changes can leave a system materially different from the one validated, and only a review comparing the current state against the original specification will show it.
Which routine activities carry validation consequences?
An out-of-tolerance calibration questions every measurement since the last good one; a patch is a change to a validated system; a restore returns a system needing verification back into its validated state; a maintenance component replacement may require requalification. None arrive labelled as validation work, so the trigger list belongs in the performing teams’ procedures.
What should happen when a system can no longer be maintained in a validated state?
An explicit, dated judgement rather than another extension. Unsupported platforms, withdrawn supplier evidence, lost configuration knowledge and documentation describing a system that no longer exists each get recorded as accepted risks with review dates that keep moving. Stating annually whether the validated state can still be defended, and for how long, forces a replacement plan or an acceptance at the right level.