How Should an Emergency Change to a Validated GxP System Be Controlled?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 24 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

Direct answer

Control an emergency change by separating the two things that are actually happening: a decision that must be made now, and a record that will be completed afterwards. At the moment of the change, an authorised person must decide and record that the change is necessary, what will be changed, what the assessed risk to the validated state and to patient safety, product quality and data integrity is, what verification will be performed immediately, and who authorised it. Everything else, including the full impact assessment, the test evidence, the procedural and training consequences and the formal approval, follows through the normal change procedure. The retrospective work completes the record; it does not authorise the change after the event, and an emergency route that produces its first written trace days later has recorded a story rather than a control.

EU GMP Annex 11 in its operative 2011 revision states that changes to a computerised system, including system configurations, should be made only in a controlled manner in accordance with a defined procedure. It does not carve out an exception for urgency, and neither does 21 CFR Part 11, whose controls for closed systems include revision and change-control procedures for systems documentation and a secure audit trail of operator entries and actions. What a defined procedure may legitimately do is include an emergency path with a different sequence. The distinction this page turns on is that a different sequence is not the absence of a control.

Decide what counts as an emergency before you need one

The emergency route exists for a change that must be made before the normal approval path can complete because waiting causes harm: the regulated process cannot run, data is being lost or corrupted, a security exposure is live, or a control that people are relying on is not working. Commercial urgency, a missed project date and a stakeholder's preference are not on that list, and a procedure that does not say so will find the route used for all of them.

Write the entry criteria into the procedure rather than leaving them to judgement in the moment, and name who is entitled to invoke them. Two named roles are usually enough, typically the system owner and a Quality representative, and the authorisation should require both where the change touches a GxP-relied-upon behaviour. Requiring a signature from someone who cannot realistically be reached at three in the morning guarantees the control will be bypassed, so design the authority for when it will actually be used, including a defined deputy.

It is also worth naming what the emergency route may not do. Changes that alter the intended use of the system, that remove or weaken a control relied on for data integrity, or that change a behaviour a validated process depends on without any means of verifying it, should be out of scope. If such a change is genuinely unavoidable, the honest position is that the system is operating outside its validated state until evidence is re-established, which is the assessment path in How to Assess the Validated-State Impact of a Production Incident.

Capture the decision at the time, not the paperwork

The most common failure here is not an absent record. It is a record created afterwards that presents a reconstruction as a contemporaneous decision.

Six things need to exist before or at the moment the change is applied, and all six can be captured in a few minutes.

What is being changed, precisely. The object, the environment, the before and after state. "Reset the workflow" is not a record; "returned document lifecycle state from In Review to Draft for the twelve documents listed, in production" is.

Why it cannot wait. Which of the entry criteria applies, stated as a fact about the situation rather than as a conclusion.

The risk assessment actually performed. ICH Q9(R1) makes the point that the formality of quality risk management should be proportionate to the risk, the complexity and the criticality of the decision, and explicitly recognises less formal approaches. An emergency change is a legitimate place for a short, informal assessment. What is not legitimate is having no assessment and writing an elaborate one later. Record what was considered, what the assessed impact on patient safety, product quality and data integrity is, and what was not known at the time.

What verification will be done immediately. Before the system returns to normal use, what will be checked to confirm the change did what it was intended to do and did not do something else. This is deliberately narrower than the regression scope decision in How to Define GxP Regression Testing Scope After a System Change, which is the follow-up activity.

Who authorised it, and who executed it. Named individuals, with the time. Where the execution used an elevated or emergency account, record which account and why, because a change that appears in the audit trail under a shared administrative identity is substantially harder to defend later.

What records were touched. If the change altered, created or removed regulated data, that is a separate consequence from the configuration change itself and needs to be visible as one.

Capture these in whatever medium is actually available at the time, including an email or a ticket, and reference that original capture from the formal change record rather than replacing it. The original artefact with its own timestamp is the evidence that the decision preceded the action.

Complete the record without re-writing the decision

Afterwards, the change goes through the normal procedure. Full impact assessment, testing proportionate to the assessed risk, updates to configuration specifications and procedures, training where behaviour changed, and formal approval.

Two disciplines keep this honest.

Record the emergency assessment and the considered assessment as separate statements, not as one merged conclusion. Where the later assessment finds something the rapid one missed, that difference is useful information about the emergency route, and overwriting it destroys the only signal that would have told you the entry criteria or the immediate verification step needs work.

Do not describe the later approval as authorising the change. It approves the change record and accepts the evidence. The authorisation happened earlier, by the named person, under the emergency provision. Describing it otherwise creates a document that says a change was approved before it was made when the audit trail says otherwise, and that contradiction is more damaging than the emergency itself.

Keep the incident and the change in their own records

An emergency change usually arrives attached to an incident or a deviation, and the records blur.

The incident or deviation record owns the question of what happened, what the impact on product, data and decisions already taken was, and what the root cause is. The change record owns the question of what was altered in the system, on what authority, and what evidence shows the system is now behaving as specified. They reference each other; neither absorbs the other.

The practical test is whether closing one would leave a question unanswered. If closing the incident would close the only record of a configuration change made to production, the change was never controlled. If closing the change record would close the only assessment of whether data created during the failure is reliable, the incident was never investigated.

Review whether the route is being used as a shortcut

PIC/S PI 011-3, the guidance used as a reference for inspecting computerised systems, treats change control and the supporting operational controls as part of what is examined. An emergency change procedure that is used frequently invites exactly that examination.

Track the rate and look at it periodically rather than case by case. Useful signals are the proportion of changes taking the emergency route, repeat emergencies on the same object or interface, emergency changes raised by the same team or outside business hours as a pattern rather than as an occasional necessity, and the gap between execution and completion of the record. A rising rate usually means something upstream is broken: the normal change path is too slow for the operational reality, the environment strategy forces production fixes, or a fragile integration is generating the same failure repeatedly. The control response is to fix that, not to tighten the emergency procedure until people stop declaring emergencies and simply make changes.

Sources

European Commission, EU GMP Annex 11: Computerised Systems (current 2011 revision): the operative expectation that changes to a computerised system, including configuration, are made only in a controlled manner in accordance with a defined procedure, together with its incident management expectations.
US Food and Drug Administration, 21 CFR Part 11: Electronic Records; Electronic Signatures: controls for closed systems including revision and change-control procedures for systems documentation and secure, computer-generated, time-stamped audit trails of operator entries and actions.
PIC/S, Good Practices for Computerised Systems in Regulated GXP Environments (PI 011-3): inspectorate guidance treating change control, security and operational controls for computerised systems as part of what is inspected.
ICH, Q9(R1) Quality Risk Management: the principle that the formality of quality risk management should be proportionate to risk, complexity and criticality, supporting a proportionate rapid assessment at the point of an emergency change.

Navata practitioner view

What I look for is the timestamp gap. Take three emergency changes and compare the time the audit trail says the configuration changed with the time the earliest written trace of a decision exists. If the decision record was created two days later, the organisation does not have an emergency change control; it has a procedure for writing up changes it already made, and every other control in the file inherits that doubt. I would also check which identity executed the change, because emergency work is where shared administrative accounts reappear, and check whether the immediate verification step was actually performed rather than promised. The reassuring answer is not a low emergency rate. It is three records where a short, rough, honest assessment exists with a timestamp before the change, and a fuller assessment afterwards that is visibly a different document and occasionally disagrees with the first one. That pattern tells me people were making real decisions under pressure and recording them, which is the only version of this control that survives being looked at closely.