Platforms, Cloud & Infrastructure for GxP
What the applications run on: hosting model, shared services, environment management, observability, portability, and the suppliers who operate any of it. Moving to a managed platform moves the work and not the accountability — the regulated organisation still has to demonstrate control over a system whose infrastructure it neither operates nor can inspect directly, which is a different evidentiary problem from the one validation was designed around.
What an explainer is not
A topic explainer is SPEQ’s synthesis of what a practice involves, cited to the standards that govern it. It does not reproduce their text, and it does not determine which of them apply to your product or process.
[ POSITION IN THE FRAMEWORK ]
7 DIMENSIONS · 24 LINKSInfrastructure is inside the validated state whether or not it is treated as such: the platform beneath a qualified application is patched, upgraded and migrated by people who were never told the application was validated.
06 · QUALITY MATURITY — PLATFORMS, CLOUD & INFRASTRUCTURE FOR GXP, REACTIVE TO ADAPTIVE
Infrastructure is an IT concern. Which platforms carry regulated applications has never been established.
Qualified infrastructure exists for named systems, and changes to it follow IT change management separately from application change control.
Platform and application change control are connected, so an infrastructure change reaching a regulated system is assessed for validated-state impact before it lands.
Hosted and cloud infrastructure carries the same expectations through contracted controls, with the responsibility boundary written per service.
The platform is treated as part of the regulated system throughout, so migration, scaling and patching are governed rather than discovered.
SPEQ’s shared five-stage progression, labelled synthesis — not the FDA QMM rating scale. Where does your organization sit? Score your quality system →
07 · REGULATORY & EVIDENCE
GOVERNING STANDARDS · 5
Derived from the 5 standards SPEQ maps to this subject, across 5 regulatory bodies: FDA, EMA, ISPE, ISO, EC.
RECORDS & OBJECTIVE EVIDENCE
- The mapping from regulated applications to the infrastructure carrying them
- Infrastructure qualification records, including for hosted services
- Change control connecting platform changes to affected regulated systems
- Responsibility boundaries for hosted infrastructure, per service
- Backup, restore and disaster recovery testing for regulated platforms
COMMON INSPECTION FINDINGS
- Operating system or database changes applied to regulated systems outside change control
- No mapping from applications to infrastructure, so change impact cannot be assessed
- Cloud infrastructure with no qualification and no documented responsibility split
- Migration of a regulated system between platforms with no revalidation assessment
- Restore never tested for a regulated platform
Qualification of infrastructure you do not control
Traditional infrastructure qualification rests on knowing and controlling the environment: named servers, documented configuration, controlled change. A managed cloud platform inverts that — the infrastructure is abstracted, changes continuously, and is not inspectable. The qualification argument has to shift from controlling the environment to demonstrating that the supplier controls it and that the application behaves correctly on it.
That means supplier assessment carries more weight, and the evidence has to be read rather than filed: which service is in scope of the attestation, which controls were tested, what was excluded. It also means the application-level verification matters more, because it is the layer the regulated organisation can actually test. Annex 11 leaves the responsibility with the regulated user regardless of who operates the infrastructure, which is the point that contract negotiations most often blur.
Continuous change under a validated state
Cloud platforms and SaaS applications update on the supplier’s schedule, sometimes without notice and sometimes without the option to defer. That is fundamentally incompatible with a validation model built around the regulated user approving every change before it happens, and pretending otherwise produces documentation that describes a control the organisation does not have.
The workable arrangements are contractual and procedural: advance notification of changes with a defined window, release notes sufficient to assess impact, a sandbox environment to verify in before production, and an agreed approach to emergency changes. Where a supplier will not provide those, that is a finding to record in the supplier assessment rather than a gap to paper over — and for a genuinely GxP-critical application it may be disqualifying.
Environments and the data in them
Development, test, validation and production environments exist to keep unverified change away from regulated data. Two failures recur. The first is production data copied into lower environments for realistic testing, which moves regulated and often personal data into systems with weaker access control and no audit-trail obligation. The second is configuration drift, where the validated environment and production diverge, so testing was performed against something that no longer represents production.
Both have ordinary answers — masked or synthetic test data, and infrastructure defined as code so environments are provably identical — and both are frequently absent because the environment strategy was set by an infrastructure team without a GxP requirement in front of them.
SPEQ interpretation — exit is a validation question, not just a commercial one
Portability is negotiated as a commercial protection: can we leave, on what notice, at what cost. In a regulated context it is also a records question. Leaving a platform means the regulated records it holds have to move somewhere that preserves their content, their metadata and their audit trail for the remainder of the retention period — and audit trails are the part suppliers export least well.
Asking for an export of a complete record with its audit trail during evaluation, and verifying that what comes back is usable, is a short exercise that has saved organisations from platforms they could enter and not leave. It is far more informative than a contractual portability clause, because the clause describes an intention and the export describes a capability.
FREQUENTLY ASKED
How do you qualify infrastructure you cannot inspect?
By shifting the argument from controlling the environment to demonstrating that the supplier controls it and that the application behaves correctly on it. Supplier assessment carries more weight and its evidence has to be read for scope and exclusions, while application-level verification matters more because it is the layer you can actually test.
How does a validated state survive supplier-driven updates?
Through contract and process: advance notification with a defined window, release notes sufficient to assess impact, a sandbox to verify in before production, and an agreed emergency-change route. A supplier who will not provide those has produced a supplier-assessment finding, and for a GxP-critical application it may be disqualifying.
What is wrong with using production data in test environments?
It moves regulated and often personal data into systems with weaker access control and no audit-trail obligation. Masked or synthetic test data is the ordinary answer, and it is frequently absent because the environment strategy was set without a GxP requirement in front of it.
What should portability testing actually verify?
That a complete record exports with its metadata and audit trail intact and usable. Audit trails are the part suppliers export least well, and running that export during evaluation is far more informative than a contractual portability clause — the clause describes an intention, the export describes a capability.