Equipment does not stay qualified because it was qualified. It stays qualified because nothing has happened to it that invalidates the evidence — and the judgement about what counts is the one most quality systems leave undefined until they are under pressure to make it.
An undefined trigger means every change becomes a debate. Debates held under schedule pressure, with production waiting, resolve towards doing nothing. That is how estates drift out of a qualified state without any single decision to blame.
Decide the triggers before you need them
This is the whole recommendation, and it costs an afternoon per equipment class. Write down what requires requalification, what requires a documented assessment with a possible outcome of no action, and what requires neither.
The value is not in getting the list perfect. It is in having made the decision at a moment when nobody was waiting, by people thinking about risk rather than about the schedule. A trigger list that turns out to be slightly conservative is easy to revise. A missing trigger list means the judgement gets made by whoever is in the room.
It also changes the conversation with production. “This change meets our defined requalification trigger” is a different discussion from “I think we should requalify.”
The triggers that belong on everyone's list
- Modification to the equipment itself. Any change to a component that affects a qualified function or a critical aspect. Replacing a seal with the same part is maintenance; replacing it with a different material is a change.
- Change in intended use. New product, new load configuration, a cycle outside the range qualified, or a parameter beyond the envelope established at OQ. This is the trigger most often missed, because the equipment has not changed at all — what changed is the claim being made about it.
- Relocation. Even within a site. Utilities differ, levelling differs, and anything dismantled for the move needs reconfirming.
- Changes to supporting utilities. A new steam source, a modified water system, a different compressed air supply. The equipment is unchanged and its qualified performance depended on the utility.
- Repair following a significant failure. Particularly where the failure mode was not anticipated, because the qualification assumed behaviour the failure has disproved.
- Control system changes. A software change to the control application is a change to the system, and it is validated as software. Whether it also triggers equipment requalification depends on whether it touches a qualified function. SCADA / DCS validation
Periodic review is not the same thing
Two distinct obligations that get conflated, and conflating them means one of them is not happening.
Periodic review asks whether the equipment is still in its qualified state: has anything changed, are the records current, does the documentation still describe what is installed, what has the maintenance and calibration history been, have there been deviations. It is an assessment, and its usual outcome is a conclusion that no action is needed.
Requalification is testing. It is one possible outcome of a periodic review, not a synonym for it.
A system where periodic review always concludes requalification is wasteful. A system where it never concludes anything is not a review. The honest version has outcomes that vary, and an undefined review interval is a finding in its own right — while a defined interval that is routinely missed is worse than a longer one that is actually kept. periodic review
How much to requalify
Rarely all of it, and this is where a risk-based approach earns real money.
Requalification should address what the change could have affected, not repeat the original programme. A replaced temperature probe on an autoclave warrants requalifying the temperature-dependent performance. It does not warrant re-running the installation qualification on the vessel.
The deliverable is the reasoning: what changed, what qualified functions could that affect, what are we therefore retesting, and why is the remainder unaffected. With that, a narrow requalification is defensible. Without it, a narrow requalification reads as a shortcut — and as everywhere else in this discipline, the difference is in the writing rather than the engineering.
Where the records usually fail
Not in the requalification itself, which tends to be done properly once it has been decided on. In the traceability afterwards.
After two or three requalifications, the question “what is the current qualified state of this equipment?” requires assembling an original package, several change records and several partial requalification reports, and working out which supersedes what. If that takes more than a few minutes, the qualified state is not actually documented anywhere — it is reconstructable, which is a different and weaker thing.
What works is maintaining a current statement of qualified state per asset, revised at each change, with the history behind it. That is the same argument as a traceability matrix that is derived rather than maintained by hand: a reconstructed answer is only as good as the person reconstructing it. The live traceability matrix
The questions to ask about your own estate
Pick a system nobody has prepared. Is there a defined requalification trigger list for it? When was its last periodic review, and is the next one scheduled? Can you produce a current statement of its qualified state, rather than the original package plus a pile of changes?
If the trigger list does not exist, that is the cheapest thing on this page to fix and the one that prevents the most future argument. equipment qualification software is the practice, audit readiness covers the inspection side, and book a demo if you want trigger lists built for an existing estate.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
