Navata
← All Library

Validation & Evidence

Deep

Who Qualifies the Infrastructure When a GxP System Runs on Multi-Tenant SaaS?

AI-assisted research and drafting · Practitioner reviewed by Rohith Karanam Sreedhar · 24 September 2026

ⓘ Library content is researched and drafted with AI assistance and reviewed by a Navata practitioner before publication. For original analysis and long-form practitioner perspectives, visit Navata Insights →

When Can a Regulated Customer Rely on Supplier Test Evidence? answers the functional question: which of the supplier's tests can stand in for the customer's own, and which cannot. This reference answers the layer underneath it. Infrastructure qualification is a separate expectation from application validation, and in a multi-tenant SaaS arrangement the customer has no physical access to the thing being qualified, no ability to schedule its requalification, and often no right to execute a test against it. That is a different problem from reusing a test script, and it is routinely settled with a sentence in a validation plan that says the supplier qualifies the infrastructure.

What the expectation attaches to when you own no hardware

EU GMP Annex 11 in its currently operative 2011 revision separates two obligations in a single sentence of principle: the application should be validated and IT infrastructure should be qualified. It defines IT infrastructure in its glossary and it does not make the obligation conditional on ownership. PIC/S PI 011-3, the guidance EU inspectors have used as the reference for inspecting computerised systems, treats the supporting environment, security, back-up and operational controls as part of what is inspected, not as somebody else's file.

Nothing in either source says the regulated organisation must personally execute installation qualification on a server rack. What they establish is that the qualified state has to exist and has to be demonstrable, and that using a third party does not move the accountability. Annex 11's section on suppliers and service providers requires formal agreements that state the third party's responsibilities clearly, expects the competence and reliability of the supplier to be a key factor in selection, expects documentation supplied with commercial products to be reviewed by the regulated user, and expects quality system and audit information to be available to inspectors on request.

Read together, those give the actual shape of the obligation in a SaaS arrangement. The customer does not personally perform qualification of the supplier-controlled infrastructure. The customer is responsible for knowing that it was performed, to what standard, covering what, by whom, and for holding evidence of that knowledge.

What the supplier typically performs, and how to establish it

A mature SaaS supplier in this market publishes what it does. Veeva's own validation features material, for example, states that Veeva performs and documents all elements of installation qualification and operational qualification for each major release, maintains qualification of the hosting infrastructure, and makes a validation package available to customers for each release including a validation plan, requirements, test protocol, installation and operational qualification records, traceability matrices and a validation summary report. It also provides a sandbox environment and user acceptance test scripts that a customer can adapt.

That is a genuinely substantial position and a customer can reasonably rely on much of it. The reliance becomes defensible when three things are true, and not before.

The customer has assessed the supplier rather than read its marketing. A supplier assessment with a conclusion, a date, a scope and an owner. It can be documentation-based, remote or on site, proportionate to the risk of the use, but it has to reach a stated conclusion about whether the supplier's quality system supports the reliance being placed on it.

The customer has established what the supplier's evidence covers. The distinction that matters is between a platform release being qualified and the customer's own configured use being proven on that release. A supplier's operational qualification demonstrates that standard platform functions behave as specified. It does not demonstrate that the customer's document types, lifecycles, workflows, security model and integrations behave as the customer's procedures assume. Read the supplier's requirements and traceability, not just its summary report, and record which of the customer's assurance claims the supplier's evidence actually supports.

The customer has recorded what it reviewed, when, and what it concluded. Annex 11 expects supplied documentation to be reviewed by the regulated user. A review that leaves no trace is indistinguishable from no review.

The frequently repeated claim that a SaaS supplier's qualification leaves the customer with performance qualification only is a simplification, and it is the one that causes trouble. It is true that the customer does not repeat the platform's installation and operational qualification. It is not true that everything except performance qualification has gone away.

Evidence that stays with the customer regardless

Five things remain in the customer's own quality system in every SaaS arrangement examined here.

The supplier assessment and the decision that followed it. Including what was accepted, what was not, and any compensating control the customer put in place because a supplier evidence gap was accepted rather than closed.

The agreement that fixes responsibilities. Annex 11 expects formal agreements with clear statements of third-party responsibilities. In practice this needs to be specific enough to answer operational questions: who restores data and to what point, who notifies whom of a platform change and how far in advance, what the customer's audit rights actually are, what happens to the customer's data and its retrievability at exit, and what the supplier commits to for security incident notification. A contract that assigns risk commercially but does not answer those questions is not a responsibility record.

The record of which platform release the customer's configured system was proven on. This is the join between the supplier's world and the customer's. Without it, the customer can say the platform is qualified and can say its configuration was tested, but cannot say the two statements refer to the same thing.

Qualification of everything on the customer's side of the boundary. In a SaaS arrangement this is usually more than teams expect: identity provider and single sign-on configuration, multi-factor enforcement, network access controls, client-side components, local integration middleware, extract and reporting layers that pull data out of the platform, and any endpoint or file-transfer mechanism in the regulated path. These are infrastructure in the sense Annex 11 uses the term, they are within the customer's control, and no supplier has qualified them.

The customer's own continuity position. The supplier's redundancy and backup arrangements are the supplier's. The customer's ability to continue the regulated process when the platform is unavailable, and to verify that data can actually be restored and read, is the customer's, and is developed in Business Continuity and Disaster Recovery for GxP Computerised Systems.

Recording the boundary so that it is inspectable

A responsibility matrix is the usual artefact, and it is usually too abstract to be useful. Rows such as "backup: supplier" do not survive the follow-up question.

Make each row an activity with an evidence location and an owner on both sides. For each item, state who performs it, who verifies it, where the evidence lives, how the customer obtains or reviews that evidence, and how often. Where the customer's access to evidence is an attestation or a certificate rather than the underlying records, say so on the row rather than leaving the reader to discover it. A row that reads "platform installation and operational qualification: performed by supplier per release; customer receives release validation package; reviewed by system owner at each general release; evidence held in the customer change record" answers the inspection question. A row that reads "qualification: supplier" does not.

Where the supplier provides third-party certifications or attestations for the hosting environment, treat them as what they are: evidence that an independent party examined a defined scope at a point in time against a standard that is not a GxP standard. They support a supplier assessment conclusion. They do not substitute for one, and their scope and date both matter.

Keeping the boundary current when the supplier changes the platform

The characteristic of multi-tenant SaaS is that the supplier changes the system on its own schedule and the customer cannot decline. That makes change notification a control, not a courtesy.

The customer needs a defined route by which supplier-side change reaches its own change process: who monitors release material, on what cadence, who assesses impact on the customer's configured use and on the assurance claims the supplier's evidence was relied on to support, and what triggers customer-side testing. That assessment path is the subject of How to Assess Veeva Release Impact and Determine What Evidence Must Be Re-established and should be connected to this boundary rather than run separately from it.

Two supplier-side changes deserve specific attention because they change the qualification position rather than the functionality. A change of hosting region, sub-processor or data centre can invalidate an assumption underlying the customer's assessment. A change to the supplier's own validation approach or to the contents of its release package changes what the customer is actually receiving, and can do so without any change to the software the customer sees.

Set a review point for the supplier assessment itself, not only for the system. An assessment concluded three years ago against a supplier quality system that has since reorganised is a document, not a current judgement.

When supplier evidence cannot be obtained

This happens, and the honest answer is not to pretend otherwise in the validation plan.

Where evidence is summarised rather than provided, record precisely what was received, what was withheld, and what the customer therefore cannot claim from it. Where review is available only on the supplier's premises or under a restricted reading arrangement, that review still produces customer evidence: a record of what was examined, by whom, when and what was concluded. Where a material element is unavailable altogether, the options are to narrow the reliance, to add a compensating control on the customer's side, to accept the residual risk through a documented decision at the right level of authority, or to not use the system for that purpose. Quietly assuming the evidence exists is not among them.

Two scope boundaries are worth stating plainly. Within its scope of production and quality system software for medical devices, the FDA's Computer Software Assurance guidance, finalised in September 2025 and updated in February 2026, recommends assurance proportionate to intended use and risk and supports leveraging supplier evidence where appropriate; it is not a general pharmaceutical GMP requirement and should not be cited as one. The European Commission's 2025 consultation draft of Annex 11 addresses cloud services and supplier oversight more explicitly than the operative 2011 text, but it is draft material issued for consultation and is not the source of any current obligation.

Sources