Cloud and SaaS Systems in GMP Environments

Cloud services support quality systems, laboratory operations, manufacturing, data storage, analytics, collaboration, infrastructure, and regulated-record management throughout pharmaceutical and biotechnology organizations.

Use of cloud technology does not change the fundamental validation objective. The regulated organization must establish and maintain confidence that the complete computerized system is fit for its intended use, protects regulated records, supports applicable Good Practice (GxP) requirements, and remains controlled throughout its lifecycle.

Cloud use changes how that objective is achieved because application software, platforms, infrastructure, security, backup, release management, and technical administration may be distributed among several organizations.

A cloud system may depend on:

the regulated organization;
the application supplier;
a cloud infrastructure provider;
an implementation partner;
a managed-service provider;
identity and security services;
data-center operators;
and additional subcontractors.

Cloud validation therefore requires more than testing application functions. It requires a documented allocation of responsibilities, qualified suppliers, appropriate contracts, relevant supplier evidence, site-specific verification, continuous service oversight, and a credible exit strategy.

What Is Cloud Computing?

The National Institute of Standards and Technology (NIST) defines cloud computing as on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released.

NIST identifies three principal service models:

software as a service;
platform as a service; and
infrastructure as a service.

It also identifies deployment arrangements including:

private cloud;
public cloud;
community cloud; and
hybrid cloud.

Service model and deployment model answer different questions.

The service model defines which technical layers the provider supplies. The deployment model describes how the cloud environment is made available and shared.

A system can therefore be:

public-cloud SaaS;
private-cloud SaaS;
public-cloud PaaS;
private-cloud IaaS;
or another combination.

The validation strategy should identify the actual architecture and responsibilities rather than rely only on the term “cloud.”

Software as a Service

Software as a service (SaaS) provides an application operated by the provider and accessed by customers through a browser, client, or application programming interface.

Examples may include cloud-based:

electronic quality-management systems;
laboratory information management systems;
document-management systems;
training systems;
clinical systems;
maintenance-management systems;
data repositories;
analytics platforms;
and collaboration applications.

The provider commonly controls:

application development;
core application code;
application deployment;
underlying platform;
databases;
operating systems;
infrastructure;
and some security, backup, and recovery services.

The regulated organization commonly retains responsibility for:

intended use;
GxP and Part 11 assessments;
user requirements;
process design;
configuration;
master data;
user access;
procedures;
training;
validation;
record review;
change-impact assessment;
and release for regulated use.

Responsibilities such as backup, restoration, incident management, audit-trail availability, data export, and security may be shared. They should be defined explicitly.

A provider-operated application is not validated for the regulated organization merely because other pharmaceutical companies use it or because the provider describes it as compliant.

Platform as a Service

Platform as a service (PaaS) provides a managed platform on which the customer or another supplier develops, configures, deploys, or operates applications.

The provider may manage:

computing infrastructure;
operating systems;
runtime environments;
middleware;
database services;
development services;
scaling;
monitoring;
and platform security.

The regulated organization or application developer may remain responsible for:

application architecture;
custom code;
configuration;
data;
interfaces;
application security;
testing;
deployment controls;
and business continuity above the platform layer.

Examples include:

managed database platforms;
integration platforms;
low-code development platforms;
managed container services;
data-processing platforms;
and cloud application-development environments.

PaaS can reduce infrastructure-management effort but may increase dependency on provider-specific services, interfaces, development tools, and data formats. Portability and supplier-exit risks should be considered early.

Infrastructure as a Service

Infrastructure as a service (IaaS) provides computing resources such as:

virtual machines;
networks;
storage;
load balancing;
backup services;
and related infrastructure.

The provider manages the physical facilities and underlying infrastructure. The regulated organization or its managed-service provider may remain responsible for:

operating systems;
databases;
middleware;
applications;
configuration;
patching;
security settings;
backup configuration;
monitoring;
and restoration.

Responsibility depends on the selected managed services. A managed database or managed backup service can move activities that would normally belong to the customer back to the provider.

IaaS should not be assumed to have low GxP significance because it is infrastructure. It may store authoritative records, support critical applications, provide identity services, or determine system availability and recoverability.

FDA’s current Computer Software Assurance guidance discusses SaaS, PaaS, and IaaS in the context of medical-device production and quality-management-system software. The guidance is specific to the medical-device Quality Management System Regulation, but its focus on intended use and risk provides useful supporting principles for evaluating cloud services.

Private, Public, and Hybrid Cloud

Private Cloud

A private cloud is provisioned for the exclusive use of one organization. It may be operated internally, by a third party, or through a combination of responsibilities, and it may exist on or off the organization’s premises.

Private cloud can provide greater control over architecture, access, maintenance windows, and configuration. It does not automatically provide better validation, security, availability, or data integrity.

The responsible organization must still establish:

qualified infrastructure;
controlled configuration;
security;
monitoring;
backup;
recovery;
change management;
and lifecycle support.

Public Cloud

A public cloud is offered for use by multiple customers and operated by a provider. Public cloud may provide:

geographic distribution;
rapid scalability;
mature security services;
resilient infrastructure;
independent assurance reports;
and extensive monitoring.

It also introduces dependencies involving:

multi-tenant architecture;
provider-controlled changes;
standardized contracts;
subcontractors;
data locations;
service availability;
and supplier exit.

Public cloud does not mean that customer records are publicly accessible. It describes the service’s availability to multiple customers, not the access classification of individual customer data.

Hybrid Cloud

A hybrid cloud uses two or more distinct environments linked to support data or application portability. Examples include:

an on-premises manufacturing system connected to cloud analytics;
a private-cloud application using public-cloud backup;
or a cloud quality system connected to site-based laboratory and enterprise systems.

Hybrid systems require clear control over:

authoritative data sources;
interfaces;
synchronization;
security boundaries;
time;
monitoring;
recovery;
and reconciliation.

GxP Applicability and Intended Use

Cloud status does not determine whether a system is GxP-relevant. Intended use does.

The assessment should determine whether the cloud service:

controls or supports a regulated process;
creates or maintains required records;
performs calculations used for GxP decisions;
manages specifications or status;
supports product disposition;
transmits critical data;
provides the authoritative record;
protects record availability;
or supports another GxP system.

The intended-use statement should identify:

supported business process;
principal users;
relied-upon functions;
records and metadata;
calculations;
decisions;
interfaces;
cloud services;
geographic scope;
and relevant limitations.

The Computerized System Types, Intended Use, and GxP Classification article provides the broader classification framework.

Shared Responsibilities

Cloud providers commonly describe security as a shared responsibility. For GxP use, the responsibility model must extend beyond cybersecurity.

It should address:

validation;
requirements;
configuration;
software development;
infrastructure;
identity management;
access administration;
privileged access;
audit trails;
electronic signatures;
data integrity;
interfaces;
monitoring;
backup;
restoration;
disaster recovery;
incidents;
releases;
patches;
vulnerabilities;
record retention;
data export;
and retirement.

Responsibility should be assigned at the activity and control level—not merely by department or organization.

For each control, the matrix should identify:

accountable party;
performing party;
required evidence;
review responsibility;
notification requirements;
and escalation route.

A control should not be classified as shared unless the separate responsibilities are clearly defined. “Shared” without allocation creates an assurance gap.

Shared-responsibility comparison for SaaS, PaaS, and IaaS showing regulated-company, provider, and shared responsibilities across business process, data, application, platform, operating-system, network, storage, and compute layers. — Responsibility shifts among the regulated organization and provider across SaaS, PaaS, and IaaS, but intended use and GxP accountability remain with the regulated organization.

System Boundary and Architecture

The system boundary should include all components and services that can affect the intended use. The architecture should identify:

application modules;
tenant;
configured functions;
custom components;
databases;
storage;
interfaces;
application programming interfaces;
identity services;
time services;
encryption and key management;
monitoring;
backup services;
recovery environments;
administrative tools;
provider support access;
subcontractors;
and external repositories.

The architecture should distinguish:

production;
test;
validation;
development;
training;
and disaster-recovery environments.

Logical diagrams should show data flows, trust boundaries, authoritative sources, and responsibility boundaries.

The cloud supplier’s generic architecture may provide useful context but does not replace the site-specific architecture.

Supplier and Service Assessment

Cloud-provider assessment should address the complete service chain. The regulated organization should evaluate:

application supplier;
cloud infrastructure provider;
managed-service providers;
implementation partners;
support organizations;
and critical subcontractors.

Relevant assessment topics include:

quality and development practices;
product maturity;
software testing;
release management;
defect management;
security;
service operations;
tenant controls;
backup;
recovery;
business continuity;
customer support;
incident notification;
change notification;
subcontractor oversight;
audit access;
financial stability;
and exit support.

The assessment method should reflect supplier criticality, dependency, uncertainty, and available evidence. Detailed guidance is provided in Computerized System Supplier Assessment and Evidence Leverage.

Tenant Separation

Multi-tenant SaaS and PaaS services may use shared application, database, compute, or storage resources while logically separating customer data and operations.

The assessment should determine how the provider prevents:

one tenant from accessing another tenant’s records;
cross-tenant search results;
cross-tenant administrative activity;
incorrect tenant assignment;
data leakage through support tools;
incorrect backup restoration;
and exposure through logging or analytics.

Evidence may include:

architecture;
access-control design;
security-testing summaries;
penetration-test results;
independent assurance reports;
encryption design;
administrative procedures;
and incident history.

Tenant separation should be tested or otherwise supported by credible evidence proportionate to risk. A provider statement that data are segregated is not sufficient by itself for critical services.

Provider and Subcontractor Access

Provider personnel may require access for:

support;
troubleshooting;
maintenance;
migration;
security;
backup;
recovery;
and incident response.

The organization should understand:

which personnel can access customer data;
what level of access is possible;
how access is authorized;
whether access is time limited;
whether multifactor authentication is required;
how privileged activity is logged;
whether customer approval is required;
whether records can be copied;
how access is reviewed;
and how access is removed.

Controls should also cover subcontractor and offshore access where applicable.

Support access to production should be exceptional, justified, traceable, and reviewable. Generic contractual language permitting unrestricted provider access creates unnecessary data-integrity and confidentiality risk.

Data Ownership and Control

The regulated organization should retain appropriate ownership and control of:

regulated data;
metadata;
audit trails;
electronic signatures;
attachments;
configuration;
master data;
reports;
derived data;
and retained records.

Agreements should address whether the provider may:

use customer data for analytics;
aggregate data;
copy data into support environments;
use data for artificial-intelligence training;
retain data after termination;
or provide data to subcontractors.

Ownership should be supported by practical capabilities to:

retrieve records;
generate accurate and complete copies;
export data and metadata;
support inspection;
preserve retention;
and migrate away from the service.

Data Location and Cross-Border Processing

Cloud records may be stored, replicated, backed up, processed, or supported in several locations.

The organization should identify, as applicable:

primary hosting regions;
backup regions;
disaster-recovery regions;
support locations;
subcontractor locations;
data-transfer routes;
and restrictions on location changes.

Data-location decisions may be affected by:

privacy laws;
contractual requirements;
customer commitments;
government-access considerations;
encryption;
latency;
recovery design;
and record-retention requirements.

The contract should define whether the provider may relocate data or processing without notification.

Data residency does not by itself establish data control. Provider access, encryption-key control, subcontractors, and export capability remain relevant.

Configuration Management

Cloud applications commonly use configuration rather than custom development to establish regulated behavior. Configuration may include:

workflows;
status transitions;
roles;
permissions;
audit-trail settings;
electronic-signature settings;
master data;
calculations;
forms;
reports;
interfaces;
notifications;
retention settings;
and business rules.

The approved configuration baseline should be identifiable and reproducible.

Controls should address:

authorized configuration access;
environment separation;
configuration specifications;
review and approval;
migration between environments;
production deployment;
comparison to the approved baseline;
change history;
and rollback.

The provider’s underlying application version and the customer’s configuration baseline should be controlled as separate but related elements.

Validation Strategy and Supplier Evidence

Cloud validation may use supplier evidence for:

development;
architecture;
product testing;
security;
release management;
backup;
restoration;
failover;
availability;
and infrastructure.

Supplier evidence should be assessed for:

relevance;
version applicability;
completeness;
traceability;
approval;
visible results;
deviations;
and relationship to the selected service.

Site-specific verification should address:

intended use;
configuration;
access roles;
calculations;
reports;
audit trails;
electronic signatures;
interfaces;
migration;
procedures;
and representative end-to-end processes.

Provider testing cannot establish that the customer’s configuration, data, users, interfaces, and procedures are correct.

Provider Release Cadence

SaaS providers may release changes much more frequently than traditional installed-software suppliers.

The validation strategy should account for:

scheduled releases;
continuous delivery;
feature flags;
mandatory updates;
emergency fixes;
security patches;
infrastructure changes;
database changes;
and subcontractor changes.

The organization should determine:

whether production updates can be deferred;
what advance notice is provided;
whether release notes are sufficiently detailed;
whether a preview or test environment is available;
whether tenant-specific impact information is provided;
how known defects are communicated;
and how rollback is managed.

Each release should be assessed for potential impact on:

intended use;
configuration;
records;
calculations;
reports;
workflows;
audit trails;
electronic signatures;
interfaces;
security;
procedures;
and validation evidence.

Not every provider release requires extensive regression testing. The scope should reflect the affected functions, risk, supplier evidence, configuration, and operational experience.

The organization should not accept provider release cadence as justification for uncontrolled production changes.

Service Availability

Cloud availability should be evaluated against the regulated process—not only against the provider’s advertised uptime. The assessment should consider:

required operating hours;
maximum tolerable outage;
critical process timing;
batch or sample impact;
ability to delay work;
manual alternatives;
data synchronization;
and recovery priorities.

Service-level agreements should define:

availability measurement;
planned maintenance;
excluded events;
incident severity;
response times;
restoration targets;
escalation;
and reporting.

A high annual availability percentage can still permit an operationally unacceptable continuous outage.

Local procedures should define what users do when the service is unavailable and how delayed or manually recorded transactions are reconciled after restoration.

Security Controls

Cloud security should address:

identity federation;
unique accounts;
multifactor authentication;
role-based access;
least privilege;
privileged access;
service accounts;
session controls;
encryption in transit;
encryption at rest;
key management;
network protection;
secure configuration;
vulnerability monitoring;
patching;
malware protection;
security logging;
intrusion detection;
incident response;
and protected backups.

Responsibility for each security control should be assigned.

Independent certifications and assurance reports may support the assessment, but their scope, exclusions, service coverage, and reporting period should be reviewed.

Cybersecurity controls are addressed more broadly in Cybersecurity Controls for GMP Computerized Systems.

Backup and Restoration

Backup responsibility should be defined separately from data retention and archival.

The assessment should identify:

data included;
metadata included;
audit trails included;
electronic signatures included;
configuration included;
backup frequency;
retention;
storage location;
encryption;
protected or immutable copies;
monitoring;
failed-backup response;
and deletion.

Restoration controls should address:

individual records;
tenant-level restoration;
point-in-time recovery;
complete-system recovery;
configuration recovery;
interface recovery;
and restoration to an alternate environment.

A provider may be able to restore an entire service but not one customer’s deleted or corrupted record. The actual restoration capability should be understood and tested or supported by credible evidence.

Disaster Recovery and Business Continuity

Disaster recovery concerns restoration of the technical service after a major disruption. Business continuity concerns maintaining or resuming the regulated process.

The cloud strategy should define:

recovery-point objective;
recovery-time objective;
recovery regions;
failover method;
dependency recovery;
disaster declaration;
customer notification;
recovery testing;
alternate processing;
return to normal operation;
and transaction reconciliation.

Provider recovery tests should be reviewed for relevance to the subscribed service. A general corporate exercise may not demonstrate recoverability of the specific application, tenant, data, and configuration.

The Backup, Restoration, Disaster Recovery, and Business Continuity article provides detailed control expectations.

Incident Notification and Investigation

Contracts should define notification requirements for incidents affecting:

availability;
data integrity;
confidentiality;
tenant separation;
unauthorized access;
record loss;
backup;
restoration;
interfaces;
cybersecurity;
and regulatory commitments.

Notification requirements should define:

reportable events;
notification timeframe;
communication route;
preliminary information;
continuing updates;
root-cause analysis;
affected records;
corrective actions;
and final reports.

The regulated organization should independently determine the GxP impact. The provider’s severity rating may not reflect the significance of the incident to the regulated process.

Incident records should support investigation, record assessment, corrective action, and regulatory inspection.

Audit and Regulatory Access

The cloud agreement should provide access to information needed to establish and maintain confidence in the service.

This may include:

supplier questionnaires;
certifications;
independent assurance reports;
security assessments;
recovery evidence;
audit summaries;
corrective actions;
incident reports;
subcontractor information;
remote audits;
or on-site audits.

Large providers may restrict individual customer audits. Alternative assurance may be acceptable when its scope and evidence are adequate.

The provider should support regulatory inspection by making accurate and complete records available in an accessible form. The regulated organization should not depend on negotiating access after an inspection request occurs.

Data Export and Record Portability

Export capability should be treated as a validation and lifecycle requirement—not merely a termination feature. The organization should determine whether it can export:

complete records;
metadata;
audit trails;
electronic signatures;
attachments;
relationships;
record status;
code-table meaning;
configuration;
and relevant logs.

Exports should support:

human-readable review;
electronic inspection;
migration;
investigation;
archival;
and retrieval throughout the retention period.

A simple report or comma-separated-values file may not constitute a complete regulated record.

Export capability should be tested before release and periodically when the provider, format, volume, or configuration changes.

Under 21 CFR 11.10, applicable closed systems must be capable of generating accurate and complete copies in human-readable and electronic form suitable for FDA inspection, review, and copying.

Contract Termination and Supplier Failure

Termination planning should address both orderly transition and unplanned supplier failure.

The plan should consider:

contract expiration;
provider acquisition;
service discontinuation;
financial failure;
prolonged outage;
security compromise;
unacceptable performance;
regulatory concern;
and loss of support.

Required protections may include:

advance termination notice;
continued read-only access;
data export;
migration assistance;
documentation transfer;
configuration export;
custom-code transfer;
source-code escrow where justified;
support during transition;
backup disposition;
data deletion;
and deletion certification.

The organization should know what happens if the provider becomes unavailable and cannot perform the agreed exit activities.

Exit Planning

Exit planning should begin during selection and contracting.

The exit plan should identify:

triggers;
decision authority;
replacement strategy;
exported content;
export format;
extraction tools;
migration responsibilities;
reconciliation;
record verification;
archived-record access;
interface shutdown;
user-access removal;
provider-access removal;
data deletion;
backup expiration;
and retirement approval.

A successful exit should demonstrate that:

required records were completely exported;
metadata and relationships were preserved;
migrated or archived records were reconciled;
records remain readable and retrievable;
interfaces were controlled;
access was removed;
and provider-held data were appropriately disposed.

Cloud computerized-system lifecycle covering supplier selection, contracting, configuration, validation, operation, provider change, recovery, data export, migration, supplier failure, and controlled exit. — Cloud lifecycle control extends from supplier selection and validation through provider-managed change, continuity, recovery, migration, and verified exit.

Maintaining the Validated State

The validated state depends on coordinated technical, supplier, procedural, and contractual controls. Ongoing controls should include:

service monitoring;
incident review;
access review;
privileged-activity review;
audit-trail review;
release assessment;
configuration control;
interface monitoring;
backup monitoring;
restoration testing;
recovery exercises;
vulnerability management;
supplier monitoring;
subcontractor monitoring;
periodic review;
and exit-plan maintenance.

Periodic review should confirm that:

intended use remains current;
responsibilities remain accurate;
the architecture remains current;
provider services remain supported;
configuration remains controlled;
data locations remain acceptable;
supplier evidence remains valid;
incidents and changes are resolved;
recovery remains credible;
and export capability remains adequate.

Cloud systems may change frequently even when the regulated organization does not initiate a formal internal project. Supplier releases, infrastructure changes, subcontractor changes, security updates, and service modifications should remain visible within the validated-state process.

Practical Cloud-Control Outcome

A defensible cloud strategy should establish:

what service and deployment models are used;
what the regulated organization relies upon;
where the system boundary lies;
which parties perform each control;
who can access records;
where data are stored and processed;
how tenant separation is assured;
how configuration is controlled;
what supplier evidence is accepted;
what is verified by the regulated organization;
how provider changes are assessed;
how service interruption is managed;
how data are backed up and restored;
how incidents are communicated;
how records are exported;
and how the organization can exit without losing regulated control.

Cloud adoption does not eliminate validation responsibilities. It redistributes technical activities while increasing the importance of supplier oversight, shared-responsibility definition, service monitoring, contractual controls, data portability, and exit readiness.