From Prototype to Audit: How Infrastructure Requirements Change Over Time

The Three Phases of a Regulated Programme

Every computational programme in regulated life sciences follows a broadly similar trajectory, even though the specifics vary by therapeutic area, organisational size, and regulatory jurisdiction. The trajectory can be understood as three distinct phases, each with fundamentally different infrastructure requirements.

The mistake that most organisations make is treating infrastructure as a static decision—something chosen at the outset and left in place. In reality, infrastructure requirements shift dramatically as a programme moves from exploration to operation to regulatory scrutiny. Organisations that fail to anticipate these shifts find themselves trapped: their platform served them well in Phase 1 but cannot support the demands of Phase 3.

Phase 1: Experimentation

In the experimentation phase, the priority is speed. Scientists need to test hypotheses, iterate on models, and explore datasets without waiting for provisioning approvals or navigating complex access control workflows. The infrastructure requirements are relatively modest: compute capacity that can be spun up quickly, storage for intermediate results, and basic collaboration tools.

At this stage, many organisations use general-purpose cloud platforms or even local workstations. The data involved is often non-sensitive—public datasets, synthetic data, or early-stage exploratory results that do not yet carry regulatory significance. Compliance controls are minimal, and that is appropriate. Over-engineering the infrastructure at this stage slows innovation without delivering proportionate risk reduction.

However, even in Phase 1, certain foundational decisions matter enormously. The data formats chosen, the workflow orchestration patterns established, and the identity management model adopted will all carry forward into subsequent phases. If these foundations are incompatible with regulated operations, the cost of correcting them later is substantial.

Phase 2: Operationalisation

As experimental results show promise, the programme transitions from exploration to operationalisation. Workflows become standardised. Datasets grow in size and sensitivity. The outputs of computational pipelines begin to feed into decision-making processes that carry regulatory weight—candidate selection, dosing calculations, safety assessments.

This is the phase where infrastructure requirements shift most dramatically. The controls that were unnecessary during experimentation become mandatory. Specific requirements that emerge during operationalisation include:

• Asset inventories: Every hardware and software component must be documented, versioned, and tracked. Regulators expect to see a current, accurate inventory that reflects the actual state of the environment.
• Backup and recovery: Data must be backed up according to a defined schedule, backups must be tested regularly, and recovery time objectives must be documented and validated.
• Access control formalisation: The informal access patterns of the experimentation phase must be replaced with role-based access controls, documented in an access control matrix and subject to periodic review.
• Audit trail activation: Every significant action—data access, configuration change, workflow execution—must generate an immutable audit trail entry that can be reviewed by quality assurance and presented to regulators.

Organisations that built on a compliant foundation during Phase 1 can activate these controls incrementally. Those that did not face a difficult choice: retrofit controls onto a platform that was not designed for them, or re-platform entirely.

Phase 3: Controlled Deployment

In the controlled deployment phase, computational workflows operate in a fully regulated environment. The outputs directly support regulatory submissions, clinical decisions, or manufacturing processes. Infrastructure is no longer a support function—it is part of the validated system and subject to the same scrutiny as the application layer.

Requirements at this stage include:

• Formal change control: Every change to the infrastructure—no matter how minor—must follow a documented change control process that includes impact assessment, approval, implementation, and verification.
• Periodic review: The validated state of the infrastructure must be reviewed at defined intervals to confirm that it continues to operate within its qualified parameters.
• Continuous monitoring: Performance, availability, and security metrics must be monitored continuously, with automated alerting for deviations from established baselines.
• Regulatory traceability: Every element of the infrastructure must be traceable to a requirement in the user requirements specification (URS), and every requirement must be verifiable through documented evidence.

Controls by Phase

The following table maps the key infrastructure controls to the phase in which they typically become necessary. Organisations planning their infrastructure strategy should use this as a minimum baseline.

Avoiding the Re-Platforming Trap

Re-platforming mid-programme is one of the most expensive and disruptive events in regulated IT. It typically involves migrating data between systems (with full chain-of-custody documentation), re-validating workflows on the new platform, re-training users, and updating quality management system documentation. The direct costs are significant, but the indirect costs—programme delays, regulatory uncertainty, organisational disruption—are often larger.

The re-platforming trap is sprung when an organisation makes infrastructure decisions in Phase 1 that are incompatible with Phase 3 requirements. Common triggers include:

• Choosing a platform that cannot generate audit trails in a GxP-compatible format
• Adopting storage architectures that lack the immutability guarantees required for regulatory data
• Building on managed services whose change cadence is incompatible with formal change control
• Using identity management systems that cannot support the segregation of duties required in controlled environments

The solution is not to impose full Phase 3 controls from day one—that would stifle the agility needed during experimentation. The solution is to choose infrastructure that can support Phase 3 controls when they become necessary, even if those controls are not activated initially. This is the distinction between a platform that is compliant and one that is compliance-ready.

The most expensive infrastructure decision is not the one you make at the start. It is the one you are forced to remake halfway through, when the cost of change is highest and the tolerance for disruption is lowest.

Annex 11 Expectations Across the Lifecycle

EU GMP Annex 11 does not prescribe a single set of controls that must be in place at all times. Instead, it establishes the principle that controls should be proportionate to the risk associated with the computerised system at each stage of its lifecycle. This principle directly supports a phased approach to infrastructure compliance.

During early development, Annex 11 expects documented risk assessments that identify which controls are necessary and which can be deferred. As the system moves toward operational use, the expectation shifts to documented evidence that appropriate controls are in place and functioning. In the operational phase, periodic review ensures that controls remain effective and that the system continues to operate within its validated parameters.

What Annex 11 does not accept is the absence of planning. An organisation that arrives at the operational phase without documented evidence of how controls were implemented progressively will face difficult questions from auditors. The infrastructure strategy must be documented from the outset, even if the implementation is phased.

A Practical Framework for Infrastructure Planning

Based on the phase model described above, organisations can adopt a practical framework for infrastructure planning that balances agility with compliance readiness.

1. Start with the endpoint: Define the infrastructure requirements for Phase 3 first. Work backward to identify which foundational decisions in Phase 1 must be compatible with those requirements.
2. Choose compliance-ready platforms: Select infrastructure that supports the full range of controls you will eventually need, even if you do not activate all controls immediately.
3. Document the roadmap: Create a written infrastructure strategy that maps controls to phases and defines the triggers for activating additional controls.
4. Build activation mechanisms: Ensure that controls can be activated without re-architecting the platform. Access control formalisation, audit trail activation, and change control processes should be configuration changes, not infrastructure migrations.
5. Review at phase transitions: Conduct a formal infrastructure review at each phase transition to verify that the platform meets the requirements of the incoming phase.