A system is validated on the day it goes live. Whether it is still validated a year later depends almost entirely on change control. It is the least glamorous part of validation and the one that decides whether everything else lasts.
What counts as a change
More than people think. Software upgrades and patches, obviously. But also configuration changes, new users and roles, interface changes on the other side, infrastructure moves, new reports, and changes in how the system is used even when the software stays the same.
The last one is the most often missed. If a system validated for research use starts supporting GMP decisions, nothing technical changed, but the validation no longer covers what it is used for.
Impact assessment is the whole job
The point of change control is not the form. It is the question: what could this change affect, and how do we know it did not? A good impact assessment names the functions touched, the data that could be affected, the interfaces involved, and the tests that will show nothing broke.
Weak assessments say no impact without saying why. That is the line inspectors read most carefully, because it is where shortcuts hide.
Proportionate testing
Not every change needs a full regression suite. A label change on a screen needs a check. A change to a calculation that feeds release needs real testing of that calculation and anything downstream of it. The rule is to test what the change could affect, and write down why the rest is safe. Our piece on requalification triggers makes the same argument for equipment.
Emergency changes
Sometimes a fix has to go in before the paperwork. That is acceptable if your procedure allows for it, and if the change is documented, assessed and tested retrospectively within a set time. What is not acceptable is an emergency route that becomes the normal route because it is faster.
Vendor changes count too
Changes made by someone else still need control. A software vendor releases a patch, the infrastructure team upgrades the database, a cloud provider moves your environment to new hardware. None of these start with your change request, but each can affect a validated system.
Agree with IT and with vendors how these changes will be notified, and assess each one the same way you assess your own. For cloud systems in particular, the release routine becomes a regular part of change control rather than an exception. Our piece on keeping SaaS systems validated covers that routine.
Signs it is not working
- Changes found during periodic review that never went through change control.
- Impact assessments that are identical across very different changes.
- Change records closed before testing finished.
- The validation documents no longer describe the system that is actually running.
We keep changes, impact and testing tied together with change controls in GxP Copilot, and periodic review is the safety net that catches what change control missed.
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.