Validating Cloud-Based Software in GxP Environments: What FDA Expects in 2026

FDA investigators issued Form 483 observations tied to inadequate electronic records controls in cloud-hosted systems at multiple major pharmaceutical sites in 2024 and 2025. The most common citation wasn’t a missing document. It was a gap in thinking: the assumption that because a LIMS, QMS, or MES is hosted by a reputable SaaS vendor, the validation obligation transferred with the hosting fee.

It didn’t. Under 21 CFR Part 11 and 21 CFR Part 211, you — the regulated entity — own the validation requirement. Vendor-supplied SOC 2 Type II reports, ISO 27001 certificates, and infrastructure qualification packages address their side of the shared responsibility model. They don’t document your workflows, your user access configuration, your data integrity controls, or your process-specific risk assessment. And in 2026, with cloud-hosted systems standard across the industry, that distinction is exactly what separates companies that sail through inspections from those drafting corrective action plans.

Here’s what FDA actually expects, and how to build a cloud validation package that holds up.

Why “The Vendor Validated It” Doesn’t Hold Up Under Inspection

This is the most persistent misconception in regulated industry cloud adoption. A cloud vendor might maintain impeccable infrastructure security, publish quarterly penetration test results, and provide a detailed Vendor Qualification Package — and none of it substitutes for your User Requirements Specification, your process-specific risk assessment, or your Operational Qualification protocol. Their documentation covers their environment. Yours must cover your use of that environment.

FDA’s Computer Software Assurance (CSA) draft guidance, published in September 2022, is the clearest statement yet of the agency’s current thinking. Rather than prescribing IQ/OQ/PQ documentation as a mandatory structure, CSA asks regulated companies to demonstrate “critical thinking” — a risk-proportionate approach where test activities are tied to genuine patient safety and product quality risk. The key word is “proportionate,” not “minimal.” You still produce evidence of assurance. The expectation is that you understand what could go wrong in your specific system and can show you’ve addressed it.

ISPE’s GAMP 5, 2nd edition — released in March 2022 — addressed cloud and SaaS systems explicitly for the first time with dedicated guidance. Under the updated GAMP framework, SaaS platforms are typically Category 4 (configured software), which means they require a URS, Configuration Specification, and OQ testing even though they’re not custom-built. If your team has been treating cloud-hosted software as exempt from the GAMP framework because “it’s off-the-shelf,” that reasoning doesn’t survive an inspection.

The practical starting point: document the shared responsibility model in your Vendor Assessment. Map what the vendor qualifies and what you qualify. That boundary document alone is often the first thing an FDA investigator asks for, and it frames everything that follows.

21 CFR Part 11 in the Cloud: Five Controls FDA Auditors Check First

Part 11 has been in force since 1997 — nearly 30 years — but its application to cloud architectures creates specific wrinkles that weren’t contemplated when the rule was written. These are the five controls we most consistently see cited in observations and warning letters.

Audit Trails. Section 11.10(e) requires computer-generated audit trails capturing date and time stamps, the identity of who made a change, and the nature of the change. In cloud systems, audit trail functionality is usually present — but you need to confirm it’s enabled for your GxP data specifically, that it’s tamper-evident, and that your OQ includes explicit test cases confirming the audit trail can’t be disabled by end users. We’ve seen Form 483 observations where audit trails existed in the platform but weren’t enabled for the specific module storing batch records. That’s a validation scope gap, not a vendor failure.

Access Controls and Role-Based Permissions. Section 11.10(d) requires that system access be limited to authorized individuals. For SaaS platforms, your IQ must document the access control model, your Configuration Specification must define roles and permission sets, and your OQ must include negative test cases — confirming that users without a specific permission genuinely cannot execute restricted actions. Checkbox evidence that the admin can grant and revoke roles isn’t enough; you need executed tests showing that a “read-only” user cannot modify a record.

System Validation for Intended Use — Including Vendor Updates. Section 11.10(a) requires that systems be validated to ensure accuracy, reliability, and consistent intended performance. Cloud and SaaS systems on rolling release cycles make this challenging. Your vendor may push 10 to 15 updates per year. Each one has the potential to modify GxP-relevant functionality. You need a formal change control procedure for vendor-side releases — a lightweight impact assessment workflow, completed by the system owner and reviewed by QA, that determines whether re-qualification testing is required. This process takes roughly 30 minutes per release for a well-scoped system. Its absence is one of the most common Part 11 citations we see.

Electronic Signatures. If your cloud system is being used to approve batch records, sign deviation reports, or execute any electronic signature workflow, Section 11.50 requires that e-signatures be permanently linked to their records and include the signer’s printed name, date and time, and the meaning of the signature. Many SaaS platforms support 21 CFR Part 11-compliant e-signatures — but “supports” doesn’t mean “configured correctly for your use case.” Your OQ must include signature workflow tests and confirm the output meets Part 11 requirements.

Record Integrity, Availability, and Retention. Section 11.10(c) requires that electronic records be protected against destruction or alteration and remain accessible for the required retention period. Cloud contracts must address data retention commitments, data export capabilities in an unaltered format, and provisions for what happens to your records if the vendor is acquired, goes out of business, or terminates the contract. This is a contractual and technical control — it belongs in your Supplier Assessment and should be re-verified at each contract renewal.

Building a Defensible Cloud Validation Package

The good news under FDA’s CSA framework is that volume is no longer the objective. A thoughtful 45-page validation package with evidence-based test cases and genuine defect resolution history is more defensible than a 200-page boilerplate protocol that looks comprehensive and doesn’t reflect real usage. For a typical mid-complexity SaaS platform in a GxP environment — a cloud-based QMS or electronic batch record system, for example — a defensible package includes at least 8 core documents:

1. Validation Plan — Defines scope, responsibilities, validation approach, and risk acceptance criteria
2. User Requirements Specification (URS) — Functional and regulatory requirements the system must satisfy
3. Vendor/Supplier Assessment — Documents vendor quality system maturity, SOC 2 status, security controls, and what the vendor’s qualification documentation does and doesn’t cover
4. Risk Assessment — Maps URS requirements to risk ratings; directly drives OQ test coverage
5. Configuration Specification — Documents all system configurations: roles, workflows, data fields, integrations, and retention settings
6. Installation Qualification (IQ) — Confirms the system is installed and configured as specified (including SSL/TLS review, integration point verification, and role configuration confirmation)
7. Operational Qualification (OQ) — Executed test scripts with pass/fail evidence, including negative tests
8. Validation Summary Report — Summarizes execution outcomes, open defects, and a formal declaration of validated state

For cloud systems specifically, add two more: a Data Migration Protocol and Report if legacy records are moving into the new system, and a Periodic Review SOP that triggers a documented impact assessment whenever the vendor releases a platform update affecting GxP functionality. That last document is missing in roughly 60% of the cloud validation packages we review in regulatory compliance consulting engagements — and it’s among the first things a prepared FDA investigator will ask about.

One consistent observation: the IQ is often the weakest document. Teams invest significant effort in OQ test scripts and then produce a two-page IQ that amounts to “we logged in and it was there.” A proper cloud IQ should include version and build number confirmation, SSL/TLS configuration review, integration endpoint verification, and explicit confirmation that all configured roles and permission sets match the Configuration Specification. That document should be executable by someone who wasn’t involved in the original build — because someday, it will need to be.

What to Do Before Your Next FDA Inspection

FDA’s inspection cadence hasn’t slowed. Software validation and data integrity are consistently among the top five citation categories in pharmaceutical cGMP inspections. But the CSA framework also gives companies something valuable: a clear signal that FDA wants proportionate, intelligent assurance — not documentation theater.

If you’re preparing for an upcoming inspection or standing up a new cloud GxP system, three actions surface the majority of your exposure quickly. First, inventory your GxP cloud systems and confirm each one has a current Validation Plan and Summary Report on file. “Current” means reviewed within the last 12 months or following any significant vendor update. Second, pull your last 3 vendor release notes for each system and check whether you performed a documented impact assessment for each. If not, that gap needs to be addressed before an investigator asks. Third, verify your Supplier Assessments reflect the current vendor quality system status — a Supplier Assessment completed at go-live three years ago may not reflect the vendor’s current SOC 2 coverage or security posture.

Those three steps take a few days of QA effort. They won’t close every gap — but they’ll tell you exactly where your program stands and what a risk-based remediation plan needs to prioritize.

Written by Sam Sammane, Founder & CEO, Aurora TIC. Learn more about our team

Talk to our compliance consultants — Contact us

Related from our network

• GMP-Compliant Laboratory Testing for Pharmaceutical Manufacturers — ISO 17025-accredited testing services supporting FDA-regulated supply chains in the US
• Health Canada GMP and NHP Testing Services — Canadian pharmaceutical and natural health product testing with full regulatory traceability