How do you validate a SaaS or cloud system for GxP use, and what is the vendor responsible for?

1Who is accountable for a SaaS system.

Moving a GxP system to the cloud moves the work, not the responsibility. EU GMP Annex 11 requires formal agreements whenever third parties provide, install, configure, validate, maintain or retain a computerised system or related service, with “clear statements of the responsibilities of the third party”, and treats in-house IT departments the same way.¹ EU GMP Chapter 7 adds that the company outsourcing a GMP activity is “ultimately responsible” for controlling it.² PIC/S says the same of data integrity: where computerised systems are outsourced, “the regulated entity retains the responsibility” for making sure the services are managed to GMP.³

In the US, 21 CFR 211.68 governs computers and related systems used in drug manufacture,⁴ and FDA has said those systems can include cloud infrastructure.⁵ For clinical investigations, FDA states that regulated entities using IT service providers for data hosting or cloud software, platform and infrastructure services “are responsible for ensuring that electronic records meet applicable part 11 requirements”.⁶

2What the vendor’s evidence can cover.

Regulators let you rely on the supplier’s work where it is sound, once you have assessed it. Annex 11 makes a supplier’s competence and reliability key factors in selecting it, bases the need for an audit on a risk assessment, and asks the regulated user to take “all reasonable steps” to ensure the system was developed under an appropriate quality management system. Documentation supplied with a commercial off-the-shelf product should be reviewed to check that it fulfils your user requirements.¹

FDA’s Computer Software Assurance guidance, reissued in February 2026 for medical device production and quality system software, lets manufacturers leverage validation activities performed by “developers, suppliers, cloud service providers”. It accepts that an onsite audit of a software vendor may not be feasible and lists other evidence: the vendor’s certifications and Service Organization Controls reports, its development, quality assurance and cybersecurity practices, and its data integrity controls, such as audit trails, access and signature controls, and accurate and complete copies of records.⁷ ISPE’s GAMP 5 Second Edition, published in July 2022, likewise encourages regulated companies to “maximize supplier involvement to leverage knowledge, experience, and documentation where possible”.⁸

3What only the regulated company can do.

The vendor can validate its product; it cannot validate your use of it. FDA’s data integrity guidance gives the example of a manufacturing execution system: qualifying the platform shows that it meets its requirements and specifications, but “does not demonstrate” that a master production record built in it has the correct calculations. Each CGMP workflow is an intended use to be validated, to an extent “commensurate with the risk posed by the automated system”.⁵ User requirements should describe the functions you rely on and stay traceable through the lifecycle.¹

4What the agreement should say.

MHRA’s data integrity guidance names SaaS, PaaS and IaaS providers. It says the technical agreement or contract should give the data owner and national competent authorities timely access to data, “including metadata and audit trails”, define responsibilities for archiving and readability through the retention period, and include business continuity arrangements that are tested. Arrangements must also exist to restore the system to its original validated state.⁹ For clinical investigations, FDA recommends a written agreement, such as a master service agreement with a service level or quality agreement, that sets out the scope, each party’s roles and responsibilities and a plan for access to data throughout the retention period.⁶

In FDA’s worked example of a SaaS product lifecycle management system, the manufacturer assesses the vendor’s development lifecycle, quality management system, cybersecurity and infrastructure availability, then agrees a service agreement covering “security, data integrity, privacy, availability, change management, and business continuity”.⁷

5How to handle vendor releases.

A SaaS product changes on the vendor’s schedule, so your change control has to reach it. Annex 11 allows changes, including configuration changes, only in a controlled manner under a defined procedure, and expects periodic evaluation to confirm the system remains in a valid state.¹ In FDA’s SaaS example, the vendor documents the changes, testing and results of each automatic update to the functions named in the service agreement. The manufacturer assesses the effect on its intended use, performs risk-based testing appropriate to the impact and keeps a record. For functions that maintain a quality record without posing high process risk, the example uses configuration verification and exploratory, unscripted user acceptance testing.⁷

6What the draft Annex 11 would add.

The European Commission consulted on a revised Annex 11, drafted by EMA’s GMP and GDP inspectors working group with PIC/S, from 7 July to 7 October 2025. The 2011 text is still the current Annex 11 on EudraLex.¹⁰¹¹ The draft adds a section on supplier and service management. Relying on a vendor’s or service provider’s qualification or operation of a system “does not change the requirements”, and the regulated user “remains fully responsible”. It asks for oversight against agreed service levels and indicators, documentation that can be explained from the regulated user’s own facility, and contracts that cover audits, inspection support, quality and security issues, an exit strategy and the chance to test new versions before release. Validation documentation may come from the vendor “in parts or in whole”, but the regulated user reviews and authorises it and checks that it covers the implemented version.¹²

7How it runs in Seal.

Seal’s validation and AI assurance guide sets out the same split for Seal itself. Seal provides the platform controls and the supplier verification and release evidence for the version in scope; your team owns the intended use, process requirements, risk acceptance and production approval, including integrations and migrated data. The hosting region is agreed at onboarding, and on the platform every change runs its tests before your team releases it, with failures kept on the record.

For the other cloud systems you rely on, the computer system assurance blueprint records each system’s intended use, the supplier evidence assessed against the claims it supports, and its configuration baseline. Each supplier release becomes a change control, and it cannot be published until every approved test has a passing run on the version being released and every sign-off is given.