Annex 11 paragraph 10 is short: 'Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.' Paragraph 4.2 requires that the validated state be maintained through the lifecycle, and paragraph 4.8 requires that the system be subject to change control if it is used for GMP purposes. The phrase 'including system configurations' exists because sites argued that a configuration change was not a change. It is. So is a patch, a hot fix, a database script, a new user role, a report modification and a vendor cloud release.
One change system, not two
The structural failure inspectors find most often is that IT operates a service management process, usually built on ITIL, with its own change advisory board, its own risk categories and its own records, and the GMP change control system never sees any of it. The two can coexist, but a change to a validated system must be visible to and approved by QA under the GMP procedure, with an impact assessment that considers the validated state and the data. The cleanest arrangement is that the IT process is the implementation mechanism and the GMP change control is the authority: no change to a GMP system is scheduled in the IT tool without a change control number, and the IT ticket is the evidence of execution.
Classifying system changes
GAMP 5 second edition (2022) keeps the software category model and the principle that effort scales with risk, novelty and complexity, and adds explicit support for agile methods, cloud services and critical thinking over documentation for its own sake. For change classification, the useful distinction is between changes that alter what the system does and changes that do not.
- Infrastructure and platform: operating system patches, database maintenance, hardware replacement, virtualisation changes. Usually low impact on functionality but capable of breaking it. Regression testing of the GMP functions on the affected platform, proportionate to the change.
- Configuration: changes to settings the system was designed to expose, such as workflows, limits, user roles, master data structures, report definitions. Category 4 in GAMP terms. Impact assessment against the configuration specification; testing of the changed function and anything it feeds.
- Customisation and code: changes to custom code or bespoke interfaces. Category 5. Full lifecycle for the changed element: specification, design review, code review, unit and integration testing, regression.
- Vendor releases: upgrades and patches from the supplier, including SaaS releases the site does not control. Assessment of the release notes against the site's use, supplier assessment evidence, targeted regression testing, and a decision on whether to accept, defer or, for SaaS, how to verify before the vendor's mandatory date.
- Data and master data: changes to specifications, recipes, limits, calculation parameters held as data. Often the highest GMP impact and the least controlled, because they look like routine administration.
Regression testing
Any change to a validated system risks breaking something that was not changed. Regression testing is the answer, and its scope should follow the risk assessment: which functions could the change affect, which of those are GMP-critical, and what is the minimum set of tests that would show they still work. A standing regression test suite, maintained as the system evolves, makes this routine. Sites without one tend to test the changed function only and discover the side effects in production. For cloud systems with frequent vendor releases, a lean automated or scripted regression pack is the only sustainable approach, and GAMP 5 second edition explicitly supports proportionate, risk-based testing over full re-validation for each release.
Emergency and break-fix changes
Systems fail at inconvenient times and the procedure must allow a fix to be applied before the full assessment is complete. What it must also do is require that the emergency change is recorded at the time, that the assessment and testing are completed within a short defined period afterwards, and that the emergency route is monitored so that it does not become the normal route. An emergency change log with twenty entries and no completed assessments is a system without change control.
User access and roles
Changing who can do what in a validated system is a change to the system's controls. Annex 11 paragraph 12 requires that access be restricted to authorised persons and that creation, change and cancellation of access authorisations are recorded. Granting an administrator role, adding a user to an approval group or changing password policy all alter the control environment. They belong in the change system, even if the site chooses a lightweight route for routine joiners and leavers under an approved procedure.
Documentation that keeps up
A validated system has a specification set: user requirements, functional or configuration specification, design where applicable, and the traceability between them and the tests. Each change updates the affected documents, or the system slowly diverges from its own specification until the next periodic review discovers that nobody can say what the system is supposed to do. Annex 11 paragraph 4.4 requires an up-to-date system description. The change record should list the documents revised, and the periodic review under paragraph 11 should confirm the change records and the current documentation agree. Module 6 of the course walks through a vendor patch, a configuration change and a SaaS release, with the assessment, the regression scope and the evidence pack for each.