How Should a Temporary Workaround in a Validated GxP Process Be Authorised, Controlled and Closed?

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

Treat a temporary workaround as a controlled change to how the regulated process operates, not as an informal accommodation while the real fix is built. Before it starts, an authorised person should record what the workaround is, which system-enforced control it displaces, what replaces that control while it is live, who may perform it, what evidence the workaround itself produces, and an expiry date with named closure criteria. While it is live, the people performing it need instructions they have actually received, and the records it generates need the same integrity controls as the records it replaced. It closes only when the displaced control is demonstrably working again and the interim records have been reconciled into the regulated record set, and a workaround that reaches its expiry date without either outcome needs a fresh authorisation decision rather than a silent extension.

Navata's flagship Insight The Architecture of a Workaround makes the broader argument about what a workaround does to a regulated system. This reference is the operational counterpart, and it answers a narrower question: given that a workaround is about to start, what must be decided, recorded, controlled and eventually closed.

The reason this needs its own answer is that a workaround occupies an awkward gap in most quality systems. It is not a system change, so the change procedure does not obviously apply. It is not a one-off departure, so a single deviation record does not really cover it. It is a temporary way of operating, and temporary ways of operating are the ones that quietly stop being temporary.

Establish what is displaced before you authorise anything

The first question is not what the workaround does. It is what the workaround stops happening.

A validated process usually enforces things the operator does not have to think about: a lifecycle state that cannot be skipped, a field that must be populated before a record advances, a routing rule that puts a record in front of a particular role, a check that prevents an out-of-date document being used, an audit trail entry that records who did what. A workaround routes around at least one of them, and almost always around more than the team initially names.

Make the displaced-control list explicit before authorising. For each displaced control, state what it was preventing or assuring, and what will replace it. The replacement will usually be procedural: a second person checking, a log, a reconciliation at the end of each day, a restriction on who may perform the step. It may be weaker than the system control, and that is acceptable where the difference is assessed and accepted at the right level. What is not acceptable is a list that stops at the obvious control and misses the two behind it.

Two displaced controls are missed particularly often. The first is traceability: a step performed outside the system leaves no audit trail entry, so the record of who did it and when exists only if the workaround creates one deliberately. The second is downstream dependency: reports, notifications, metrics and interfaces that assumed the normal path will behave differently while the workaround runs, and the people consuming those outputs usually do not know the workaround exists.

Authorise it as a decision, with an expiry

The authorisation record needs six elements, and none of them requires a lengthy document.

Scope. What specifically is done differently, by whom, for which records or population, and in which system or environment. A workaround that applies to "urgent cases" without defining urgency will be applied to whatever anyone judges urgent.

Displaced controls and their replacements. As above.

Risk assessment. ICH Q9(R1) supports a level of formality proportionate to risk, complexity and criticality, so a short assessment is legitimate. It should reach a stated conclusion about impact on patient safety, product quality and data integrity, and it should say what is not known.

Authorised performers. Named roles or individuals, with any required briefing or training stated as a precondition rather than an intention.

Evidence the workaround produces. What record proves each instance was performed correctly, where it lives, and how it will be found later.

Expiry date and closure criteria. The expiry date is the control. It should be short enough that reaching it is a real event, and the closure criteria should describe an observable state, not an aspiration. "Until the fix is deployed" is not a closure criterion unless deployment is also verified to have restored the displaced control.

Where the workaround exists because a system behaviour is broken, the underlying incident and its validated-state consequences belong in their own record, as set out in How to Assess the Validated-State Impact of a Production Incident. The workaround authorisation says how the organisation will operate meanwhile; it does not settle whether records created during the failure are reliable.

Control the records the workaround creates

A workaround frequently moves a step out of the validated system and into a spreadsheet, an email, a form or somebody's judgement. That creates records which are part of the regulated record set whether or not anyone intended them to be.

The MHRA's GxP data integrity guidance is directly relevant here, because its expectations attach to the data and the record rather than to the system that happens to hold them. Records generated by a workaround need to be attributable, legible, contemporaneous, original and accurate, and where a paper or spreadsheet step now sits inside an otherwise electronic process, the combination is a hybrid arrangement that needs to be recognised as one and controlled accordingly, including how the two halves are reconciled.

In practice this means deciding three things up front. Where the interim record physically lives and who controls access to it. How each interim record will be tied back to the system record it relates to, because an unlinked log is nearly useless six months later. And what happens to those records at closure: whether they are transcribed into the system, retained alongside it, or both, and who verifies the transcription if one happens.

Instruct the people who will perform it

A workaround that exists only in the authorisation record will be performed differently by each person who performs it.

Waiting for a full procedure revision is usually the wrong trade, because the revision cycle is longer than the workaround is supposed to live. The workable pattern is a controlled work instruction or temporary procedural notice, issued under the quality system, referenced from the authorisation record, with a record of who received it. Keep it short and specific: the trigger, the steps, the record to complete, who to escalate to, and what to do if the situation falls outside the described scope.

Where the workaround will run long enough that new people will join the process, treat it as a training item rather than a briefing, because a verbal handover between operators is exactly how the scope boundary gets lost.

Close it, and prove it stopped

Closure has two parts and organisations routinely do only the first.

The first part is restoring the displaced control and verifying that it works. Not that the fix was deployed, that the control is functioning: the field is mandatory again, the routing reaches the intended role, the audit trail entry appears. This is a small targeted verification, connected to but narrower than the regression question addressed in the change territory.

The second part is reconciling the interim records. Every instance performed under the workaround should be accounted for, and the interim record set should be closed with a statement of its completeness, its disposition and where it is retained. Where interim data is transcribed into the system, the transcription needs verification proportionate to what depends on it.

Then confirm the workaround actually stopped. This sounds trivial and is not. People who have been performing a step for three months keep performing it, particularly where the workaround was quicker than the normal path. A short check a few weeks after closure, looking at whether the interim log is still being written to or whether records are still arriving by the workaround route, is worth more than the closure signature.

When a workaround outlives its expiry

Reaching the expiry date is a decision point, and it should feel like one.

Either the displaced control has been restored, in which case close it, or it has not, in which case the workaround is re-authorised explicitly, with the risk reassessed in light of how it has actually been performing and with a new expiry. Repeated re-authorisation is a signal worth acting on rather than a formality: it usually means the permanent fix is not actually funded, or that the workaround has become the process and should be designed properly and validated rather than renewed indefinitely.

Long-running workarounds also need to appear in periodic review. PIC/S PI 011-3, the guidance used as a reference for inspecting computerised systems, treats the operational controls surrounding a system as part of what is examined, and a validated system being operated through a procedural detour that no review has looked at for a year is a gap that is visible from the outside. The periodic review inputs in What Should an Inspection-Ready Veeva Periodic Review Cover? should include the open workaround register as an input, not as an appendix.

Sources

European Commission, EU GMP Annex 11: Computerised Systems (current 2011 revision): the operative expectations for risk management across the system lifecycle, incident management, controlled change and periodic evaluation, used here as the framing for treating a workaround as a controlled way of operating rather than an informal one.
MHRA, GxP Data Integrity Guidance and Definitions (revision 1, March 2018): regulator guidance on data integrity expectations attaching to records regardless of medium, including hybrid arrangements, supporting the treatment of records created by a workaround as part of the regulated record set.
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 short but real assessment at the point of authorisation.
PIC/S, Good Practices for Computerised Systems in Regulated GXP Environments (PI 011-3): inspectorate guidance treating the operational and procedural controls surrounding a computerised system as part of what is inspected, supporting the inclusion of open workarounds in periodic review.

Navata practitioner view

The question I ask is what the workaround stopped, not what it does. Teams describe the new steps fluently and go quiet when asked which system-enforced control is no longer running and what replaced it, and that gap is where the exposure sits. Two other things I look at. Whether an expiry date exists and whether anybody has ever let one arrive and made a real decision, because an expiry that is always extended the day before is a formality that has already failed. And whether the interim records can be joined back to the system records they relate to, because a log of dates and initials that cannot be tied to a specific document or batch does not evidence the process was controlled; it evidences that somebody was writing things down. The workaround I would worry least about is one with an uncomfortable, honest risk assessment, a short expiry that has been consciously extended twice with reasons, and a register that somebody reads. The one I would worry about is the one everybody knows about and nobody has written down, because it will be described to an inspector by whoever is nearest, from memory.