Digital Twins in Pharma
Automation —
Validation Implications

What a Digital Twin Actually Is in a Pharma Context

The term digital twin is applied loosely across industry, covering everything from a simple simulation model to a real-time connected replica that mirrors every state variable of a running physical system. In pharmaceutical manufacturing, the most common implementations fall somewhere in between: a high-fidelity dynamic process model, a virtual PLC environment running the actual production code, or a connected system that consumes real process data and provides optimisation recommendations.

For validation purposes, the distinction that matters most is not the technical sophistication of the twin but rather its relationship to GMP-regulated decisions. A digital twin that sits entirely outside the GMP production boundary — used only for engineering development and training — occupies a very different compliance position from one that feeds recommendations into a validated control system or is used as a basis for qualification testing that substitutes for physical testing on the real system.

GAMP 5 Classification — The Key Question

The GAMP 5 category for a digital twin is driven by its purpose and the GMP impact of its outputs. A Type A development twin — used purely for engineering and training with no formal GMP role — is not a GMP computerised system and does not need to be validated. It is subject to normal software quality practices, but the full validation lifecycle does not apply.

A Type B qualification support twin — where outputs are used as formal test evidence in the qualification package — is in GMP scope. The question is whether QA and the client's regulatory strategy accept virtual evidence as equivalent to physical testing evidence. Under Computer Software Assurance principles, there is regulatory appetite for leveraging vendor-supplied testing evidence and reducing redundant physical testing. A well-validated simulation environment could, in principle, generate some categories of test evidence more efficiently than physical execution. But the twin itself must be validated for this purpose — its accuracy and fidelity relative to the physical system must be demonstrated and documented.

A Type C live connected twin that influences real-time process decisions is unambiguously a GMP computerised system. It classifies as Category 5 custom software, requires a full validation lifecycle including URS, SDS, risk assessment, and IQ/OQ/PQ, and its change control must be integrated with the change control of the physical system it is connected to.

Virtual FAT and the Evidentiary Question

One of the most compelling use cases for digital twins in pharma automation is the virtual Factory Acceptance Test — running the formal FAT protocol against a high-fidelity simulation of the physical system before the hardware even arrives on site. The engineering benefits are significant: faster FAT cycle, ability to test edge cases and failure modes that are difficult or risky to induce on real hardware, and a record of pre-FAT execution that can reduce the physical FAT scope.

The validation question for virtual FAT is whether the evidence it generates is accepted as equivalent to physical FAT evidence by the client's QA team. Under traditional CSV thinking, physical execution against the actual hardware is the gold standard — a simulation, however accurate, is a simulation. Under CSA principles, there is more room to argue that if the simulation fidelity is demonstrated and documented, virtual FAT evidence is legitimate assurance of software behaviour.

In practice, the position in 2025 is that virtual FAT evidence can supplement but not fully replace physical execution for GMP-critical test cases. What it can do effectively is pre-qualify the control logic so that the physical FAT focuses on integration and hardware verification rather than software logic verification. This reduces physical FAT time and cost while maintaining the regulatory defensibility of the evidence package.

For this to work, the simulation environment used for virtual FAT must itself be qualified: its fidelity to the physical system must be demonstrated and documented, the simulation software must be under version control, and the test execution must be documented with the same rigour as physical execution. You cannot use an informal simulation run as formal FAT evidence. The simulation environment must be treated as a GMP tool.

The Synchronisation Problem — When the Twin Diverges from Reality

A digital twin that is connected to a live system and used to inform GMP decisions faces a validation challenge that does not exist for conventional validated software: it can become invalid without any change to the twin itself. If the physical system is modified — a hardware replacement, a PLC configuration change, a process parameter adjustment — and the twin is not updated to reflect that change, the twin's outputs will be based on a model of a system that no longer exists. Decisions made on the basis of those outputs may be compromised.

Managing this requires integrating twin synchronisation into the change control process for the physical system. Every CCR for the physical system must include an assessment of whether the digital twin is affected. If the change affects any modelled parameter, the twin must be updated, re-verified, and the update documented before the twin is used for GMP-relevant decisions post-change. This is an additional dimension of the change control process that organisations deploying Type C twins must plan for explicitly.

How the V-Model Applies to Digital Twin Validation

For a Type C live connected twin, the V-model applies in the same way it applies to any Category 5 custom software system. The URS must define the intended use of the twin, the GMP decisions it informs, the fidelity requirements (how closely must the twin's outputs match physical system behaviour within defined tolerances), and the synchronisation requirements (what triggers a twin update when the physical system changes).

The SDS must describe the model architecture, the physical system parameters it models, the data connections to the physical system, and the algorithms used to generate recommendations or predictions. The IQ must establish the software baseline for both the twin application and the underlying simulation engine, and verify the data connections to the physical system are configured as specified. The OQ must verify the twin's functional outputs against defined fidelity test cases — comparing twin predictions against physical system measurements under controlled conditions.

This is not a trivial validation exercise. The OQ fidelity testing requires running the physical system through defined scenarios and comparing the twin's predicted outputs against actual measured values, with quantitative acceptance criteria defined in the URS. If the twin's predictions fall outside the defined tolerance, this is a deviation that must be investigated — either the model needs refinement or the acceptance criteria need to be reconsidered with QA approval.

Where the Industry Actually Is on Digital Twins

Digital twins in pharmaceutical manufacturing are at an early but accelerating adoption stage. The most mature implementations are in process development and scale-up — using process models to predict batch behaviour before committing to manufacturing scale. In the GMP manufacturing environment itself, Type A and Type B implementations are more common than Type C, partly because the validation requirements for live connected twins are not yet standardised and partly because QA teams are conservative about introducing a new layer of software complexity between the operator and the process.

The regulatory frameworks for digital twins in GMP are still evolving. GAMP 5 2nd Edition acknowledges their existence and points toward the same risk-based classification approach described in this article, but specific guidance on virtual FAT evidentiary standards and live twin validation is limited. Organisations implementing digital twins in GMP-critical roles today are in some sense setting their own precedent — and that means conservative choices, thorough documentation, and early engagement with QA and regulatory teams are particularly important.