GxP Cloud Computing: Validation, Data Integrity and Shared Responsibility

GxP Cloud Computing is the use of cloud-hosted applications and infrastructure to support regulated activities and their electronic records. It describes how a system is used, not a “GxP-certified cloud”. The hosting arrangement identifies where services run; assurance addresses whether an identifiable system is suitable for its intended regulated activity.

For this article’s examples, the working system boundary includes intended use, the configured application, supporting infrastructure, interfaces, records and responsible people. This is an analytical boundary, not a prescribed architecture. It keeps the discussion tied to actual workflows and evidence rather than a cloud service label.

These are complementary assurance questions, not substitutes. For medicinal-product GMP, the distinction is explicit in Annex 11, Principle: “The application should be validated; IT infrastructure should be qualified.” This is GMP guidance, not a cloud certification scheme.

In practical terms, paperless validation concerns how assurance evidence is managed, while data integrity concerns the trustworthiness of records. Neither question is answered simply by choosing cloud hosting. Start with the activity, identify its system boundary, and then distinguish the evidence needed for each assurance question.

Start an applicability assessment with the jurisdiction, product, activity and records—not the hosting model. Record the basis for each decision before selecting controls. This is illustrative operational practice: a way to organise the assessment, not an additional regulatory requirement.

The Annex 11, introductory legal-basis paragraph identifies its medicinal-product GMP context. Treat Annex 11 as official guidance in that context, not as a universal cloud regulation. 21 CFR Part 11 is binding US regulation; its controls bind only where Part 11 applies to the records in question. The FDA clinical-investigation Q&A is official guidance, kept separate from manufacturing control claims.

For the EU row, Annex 11’s Principle distinguishes application validation from infrastructure qualification. For the US row, 21 CFR 11.1(e) addresses inspection availability.

For clinical applications such as electronic data capture, check the current FDA electronic systems, records and signatures Q&A for scope and relevant cloud-service-provider discussion. Keep four labels distinct throughout the assessment: binding regulation, official guidance, illustrative operational practice and software support. The distinction matters because a provider's feature list or attestation describes what the service can do, not whether your use of it meets an obligation; no cloud service is “GxP-certified” by a regulator.

Shared responsibility is useful only when it identifies who performs an activity, who supplies evidence and who accepts the result. Annex 11’s supplier guidance in §3.1 calls for formal agreements between the manufacturer and third parties, with clear statements of third-party responsibilities. A service description alone is not an acceptance decision.

The following matrix is an illustrative contracting and governance aid, not a prescribed allocation. Adapt it to the service boundary and agreement. Provider cells identify example contractual commitments; user cells identify oversight and acceptance decisions; evidence cells identify technical records supporting those decisions.

A useful contract test is to walk through the verbs in Annex 11 §3.1 one by one. The paragraph covers third parties used “to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing”. In a typical SaaS arrangement the provider may provide, install and maintain the platform, and modify it through releases; the regulated company or its integrator may configure workflows and integrate them with other systems; validation of the configured intended use stays with the regulated company; and retention may be split, with the provider storing data during the subscription and the company responsible for retrievability afterwards. Each verb that a third party performs should map to a written responsibility statement in the agreement, and each verb nobody has claimed is a gap to close before go-live rather than after an inspection question. §3.1 also says that “IT-departments should be considered analogous”, so the same mapping applies when an internal IT function, not an external provider, runs the cloud tenancy.

Supplier selection is a separate judgement. Annex 11 §3.2 identifies competence and reliability as key selection factors and bases the need for an audit on risk assessment. Record the rationale for the supplier decision and any quality audit, rather than treating an audit as a universal purchasing step.

For commercial off-the-shelf products, Annex 11 §3.3 says regulated users should review documentation against user requirements. Use requirements traceability to distinguish what supplier documentation supports from what needs tenant-specific acceptance evidence. Keep the supplier’s statements separate from the authorised user’s acceptance record.

Finally, Annex 11 §3.4 says supplier or developer quality-system and audit information relating to software and implemented systems should be available to inspectors on request. Include an information-access arrangement in supplier governance so that contractual responsibilities connect to retrievable oversight information.

For systems within its GMP scope, Annex 11 provides a risk-based foundation: §1 says the extent of validation and data-integrity controls should follow a justified, documented system risk assessment. In practical risk-based validation, start with the configured workflow’s intended use and potential failure consequences, rather than treating the supplier’s general test results as the acceptance decision.

Annex 11 §4.1 says validation documentation and reports should cover relevant lifecycle steps. Its glossary definition of life cycle extends from initial requirements until retirement, including operation and maintenance—not just initial deployment.

Under Annex 11 §4.4, user requirements should describe required functions, reflect documented risk assessment and GMP impact, and remain traceable throughout the lifecycle. A practical requirements traceability chain is: intended use → requirement → configured function → test and result → deviation disposition → acceptance decision → operational changes → retirement evidence.

Separately, for closed systems subject to Part 11, 21 CFR 11.10(a) requires validation for accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. This US regulatory obligation is distinct from the Annex 11 guidance above.

Testing should address more than the normal successful path: Annex 11 §4.7 specifically identifies system/process parameter limits, data limits and error handling for consideration.

Worked case: changed approval permissions

Assume a supplier update changes role permissions in a configured approval workflow. The local requirement permits designated approvers to approve, denies operators that action, and requires a failed approval to leave the record unapproved. The scenarios below illustrate reasoning, not a mandated test count; no quantitative units apply.

Annex 11 §4.2 says validation documentation should include applicable change-control records and reports of validation deviations. In this example, link the update, affected requirement, configuration, execution evidence and validation deviation report. The authorised decision-maker records a no-go for this workflow because the failed-approval result contradicts its requirement. Correction and targeted retesting would provide evidence for reconsideration; passing the other scenarios does not resolve that failure.

Cloud storage answers where data resides; record preservation planning asks whether the retained evidence remains usable and interpretable. As an implementation practice, connect each regulated record to its relevant history, signature information and system context rather than treating a stored file as the entire evidence package.

Changes, copies and signature meaning

EU GMP guidance in Annex 11 §9 calls for risk-based consideration of a system-generated record of all GMP-relevant changes and deletions—not an unqualified requirement to capture every cloud event. The same provision says reasons for changing or deleting GMP-relevant data should be documented, and audit trails need to be available, convertible to a generally intelligible form and regularly reviewed. An audit-trail review workflow addresses review, not merely log collection.

For systems subject to its controls, 21 CFR 11.10(b) requires the ability to generate accurate and complete record copies in both human-readable and electronic form suitable for agency inspection, review and copying. Separately, 21 CFR 11.50(a)(2)–(3) identifies the signature execution date/time and its meaning, such as review, approval, responsibility or authorship. These answer different questions: when was the signature executed, and what did it signify? These are selected signature controls, not a complete Part 11 checklist.

An illustrative evidence relationship model

Use the following model for traceability and retrieval planning. Field names are example implementation choices, not prescribed records or product features. A CSV traceability matrix can organise the requirement-evidence branch.

Retention and archival retrieval

Add an explicit retention-planning entry for each record class: applicable retention basis and reference, retention trigger, period determined from that basis, and responsible owner. This is a planning approach, not a universal retention duration.

Annex 11 §17 says archived data should be checked for accessibility, readability and integrity. Where relevant system changes are planned, the ability to retrieve the data should be ensured and tested. An archival retrieval check therefore addresses preserved evidence, rather than the operational restoration arrangements covered in the resilience section.

Access governance, recoverable data and continuity answer different questions: who can use the system, whether its data can be restored, and how critical activities continue during disruption. Treat them as separate acceptance questions rather than one cloud-availability check.

Authorised access and its history

EU GMP Annex 11 guidance addresses both access restrictions and authorisation records. Annex 11 §12.1 calls for physical and/or logical controls restricting access to authorised persons; §12.3 says creation, change and cancellation of access authorisations should be recorded. As an implementation practice, distinguish the current permission set from its authorisation history. A role-based access control model can structure that comparison; a current user list alone does not explain how permissions changed.

Backup evidence versus restoration evidence

A backup artifact is not, by itself, evidence that restoration works. Annex 11 §7.2 says backup data integrity and accuracy, and the ability to restore data, should be checked during validation and monitored periodically. For practical acceptance, distinguish evidence that a backup was created from evidence of restoration and the resulting data checks. This keeps data integrity in view rather than reducing recovery to service availability.

Continuity and a bounded recovery calculation

Annex 11 §16 addresses continuity of support for critical processes during system breakdown. The time to bring alternative arrangements into use should be risk-based and appropriate to the system and business process; those arrangements should be documented and tested.

Worked case 2: assume a site-defined recovery objective of 120 minutes. The measurement window begins when service restoration starts and ends when record reconciliation and verification finish. Within that window, the only activities are sequential: 75 minutes to restore service, then 30 minutes to reconcile and verify records.

• Total elapsed time: 75 + 30 = 105 minutes.
• Remaining margin: 120 − 105 = 15 minutes.

These are hypothetical planning values, not regulatory limits. The calculation meets the assumed timing objective only within this window; timing alone does not demonstrate record completeness.

For medicinal-product GMP systems, Annex 11 §10 states that changes, including system configurations, should follow a defined procedure in a controlled manner. Treat provider releases and tenant configuration changes as inputs to change control, with assessment tied to the deployed system rather than the release label alone.

The following is an illustrative practice sequence, not a prescribed regulatory workflow or release cadence. Build on the validation case described above:

1. Identify the deployed baseline: application version, relevant configuration and connected components.
2. Describe the change, distinguishing provider modifications from tenant-controlled settings.
3. Identify affected requirements and interfaces; use the CSV traceability matrix to connect the change to existing acceptance evidence.
4. Select evidence appropriate to the impact, identifying what existing evidence remains applicable and what needs additional testing.
5. Assess deviations and unresolved findings, documenting their significance for intended use in the CSV deviation report.
6. Record the authorised person's disposition, including conditions, responsibilities and the accepted baseline.

Keep documentation control distinct from application testing. Where applicable, 21 CFR 11.10(k)(2) requires revision and change-control procedures maintaining an audit trail of time-sequenced development and modification of systems documentation. That documentation history is not, by itself, evidence that changed application behaviour meets acceptance criteria.

Automation does not remove the tool-assurance question: Annex 11 §4.7 states that automated testing tools and test environments should have documented adequacy assessments.

As practical planning options, assess rollback, delayed deployment and alternative operation against the actual service arrangement. Do not assume the provider supports them; establish feasibility and decision ownership before relying on an option.

For electronic exchanges between systems, EU GMP guidance in Annex 11 §5 calls for built-in checks for correct and secure data entry and processing to minimise risks. For transfers to another format or system, Annex 11 §4.8 says validation should check that migration does not alter data value or meaning. This is central to GMP data migration, not merely successful transmission.

As risk-based implementation reasoning—not a regulatory field list—consider checks on record identifiers, field mappings, units, status values and source-to-destination relationships. For an MES–historian integration, for example, test whether the destination associates each measurement with the intended production record and interprets its unit correctly.

Worked case: reconcile IDs before replay

Assume a transfer contains 1,000 expected unique record IDs, with each ID assigned to exactly one outcome group. Reconciliation shows 970 accepted, 20 quarantined and 10 with unconfirmed outcomes: 970 + 20 + 10 = 1,000 IDs. The unit counted is unique record IDs, not messages or transmission attempts.

The 10 unconfirmed outcomes establish neither failure nor success: destination processing may have occurred without confirmation reaching the sender. Investigate destination state before replay to avoid creating duplicates. Count reconciliation is one check; even a balanced total does not establish preserved field meaning.

In a proposed evidence model, transfer_id identifies the transfer; source_record_id identifies each originating record; destination_record_id links its destination counterpart, where established; and reconciliation_id identifies the comparison and its findings. Retain unresolved relationships explicitly rather than assuming a destination record exists.

1. Contain the affected transfer to prevent uncontrolled retries.
2. Identify record-level outcomes using source and destination evidence.
3. Assess mapping or processing errors and affected records.
4. Have authorised people approve correction or replay after checking destination state.
5. Reconcile again, checking both outcomes and affected field meanings.

This sequence is a proposed recovery method, not a mandated protocol or an assertion that an application performs these functions automatically.

These hypothetical gaps concern specific evidence mismatches, not whole-service compliance verdicts. The roles below are suggested investigation leads, subject to the agreed responsibility allocation. Keep supplier assurance, validation, security and record preservation tied to their separate questions, as covered above.

Before relying on an assurance conclusion, ask: does the evidence describe this intended use, this configuration and this record flow?

Use this implementation aid—not a statutory checklist—to consolidate earlier sections. Replace suggested roles with named accountable people and document unresolved issues.

Separately, Annex 11 §11 says periodic evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.

Annex 11 §13 says all incidents—not only system failures and data errors—should be reported and assessed. A critical incident’s root cause should be identified and form the basis of corrective and preventive actions.

Close with the recorded decision, accountable authorised person and unresolved conditions—not a release decision or compliance verdict by itself.