Cloud / SaaS Qualification Template

This is a ready-to-use cloud and SaaS qualification template. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, attach your supplier audit reports and certifications, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

The point of this document is to answer the one question an inspector always asks about a cloud system: you do not run the infrastructure and you cannot see most of the stack, so how do you know the system is fit for GxP use and stays that way. A signed qualification that draws the responsibility line, evidences the supplier, tests what only you can test, and re-checks on a schedule is the answer.

Document control header

1. Purpose

This document defines how <<FILL: COMPANY NAME>> qualifies the cloud or SaaS application <<FILL: application name>>, supplied by <<FILL: SaaS vendor>> and hosted on <<FILL: cloud service provider, e.g. a major public cloud>>, for GxP use. It records who is responsible for which controls, the evidence relied on for the parts of the system the company cannot directly test, the testing the company must still perform itself, and the schedule for confirming the qualified state stays valid over time.

2. Scope

This template applies to the named application and the GxP processes it supports at the sites listed below. It covers the application layer, its configuration, the data it holds, and the supplier and hosting arrangement behind it. It does not replace the computerized system validation of the workflows built in the application, which is governed by <<FILL: CSV / CSA SOP-ID>>, nor the general IT infrastructure qualification of company-managed components, governed by <<FILL: infrastructure qualification SOP-ID>>.

3. Responsibilities

4. Definitions

• SaaS, PaaS, IaaS: software, platform, and infrastructure as a service. The service model sets how much of the stack the supplier manages and how much the customer manages.
• Shared responsibility: the division of security and compliance controls between the customer, the SaaS vendor, and the cloud service provider. In SaaS the customer keeps least; the customer always keeps responsibility for its own data, user access, and configuration.
• CSP: cloud service provider, the operator of the underlying compute, storage, and network the SaaS vendor builds on.
• Multi-tenancy: one application instance serving many customers, with logical separation of each customer’s data.
• Configuration: settings turned on or set within the vendor-managed platform without changing vendor source code. Distinct from customization (code, scripts, or bespoke modules), which carries more validation effort.
• Sub-processor: a third party the vendor uses to process customer data, including the CSP itself.

5. System overview and service model

The update model matters more for cloud than for on-premise software. A vendor that pushes continuous releases you cannot defer changes the validated state without your action, so section 9 and section 11 must address how you detect and assess those releases.

6. Shared-responsibility matrix

Map every control to exactly one accountable party, customer (C), SaaS vendor (V), or cloud service provider (P), and name how the company verifies the parties it does not control. Do not leave a control unowned. The split shifts with the service model; the matrix below is a SaaS-typical starting point.

Two rules an inspector will test. First, the customer always owns its data, its users, and its configuration, no matter how much the vendor manages. Second, the supplier audit report you rely on must actually cover the controls you assigned to V and P; a report scoped to a different service or region does not count.

7. Supplier and CSP assessment

The company cannot inspect the vendor’s data center or read its source code, so qualification rests on a documented supplier assessment plus independent third-party evidence. Record the evidence and its currency below.

7.1 Supplier assessment

7.2 Third-party certifications and audit reports relied on

A SOC 2 Type II report is read, not just filed. Check the audit period covers a meaningful window, that the scope names this service and region, and review every exception and every Complementary User Entity Control (CUEC), because each CUEC is a control the report hands back to you. List the CUECs you must implement in section 8.

8. Customer-managed controls to implement

These are the controls the matrix assigned to the company, plus any CUECs handed back by the supplier audit report. They are configured and evidenced by the company, not the vendor.

9. Configuration versus the vendor-managed platform

Draw a clear line between settings within the vendor platform and any code-level customization, because the two carry different validation effort and different exposure to vendor updates.

Configuration of a vendor-managed platform is verified through testing the configured behavior; you are not validating the vendor’s code, which sits behind the supplier assessment. Customization, by contrast, is your code in the vendor’s environment and must be tested as such. Record which is which so the test effort in section 11 is proportionate and defensible.

10. Data location, retention, and portability

The two questions that catch teams out: can you get your GxP records back, complete, in a usable format, if the vendor relationship ends, and can you keep the records for the full retention period even though the vendor may retain them for less. If the application’s own retention is shorter than your obligation, your section 8 export routine is what closes the gap, and it must be qualified.

11. What the customer must still test

A supplier audit report and a vendor validation pack do not discharge the company’s testing duty. The company tests its intended use, its configuration, its data, and its controls. Risk-based and critical-thinking-led under current CSA thinking: test the GxP-critical, high-risk functions deeply and rely on supplier evidence for the platform underneath.

12. Acceptance criteria

This system is accepted as qualified for GxP use only when all of the following are true.

13. Periodic re-assessment

A cloud qualification is a point in time; the vendor keeps changing the system under you. Define when the qualified state is re-confirmed, by schedule and by trigger.

The single most common cloud gap is a supplier whose SOC 2 audit periods leave an uncovered gap between reports, or a new sub-processor added without notice. Re-assessment checks both: continuous audit coverage with no gap, and the current sub-processor list against the one you assessed.

14. Acceptance and approval

15. References

21 CFR Part 11 (electronic records and electronic signatures). 21 CFR 211.68 (automatic, mechanical, and electronic equipment). EU GMP Annex 11 (computerised systems), including supplier and service provider expectations. EU GMP Chapter 7 (outsourced activities). FDA Computer Software Assurance for Production and Quality Management System Software, final guidance issued 3 February 2026 (superseding the 24 September 2025 version). GAMP 5 (Second Edition) and the ISPE GAMP Good Practice Guide on IT infrastructure and cloud / SaaS. PIC/S PI 011 (good practices for computerised systems) and PIC/S PI 041 (data management and integrity). ICH Q9 (Quality Risk Management) for the risk-based scope and re-assessment frequency. ISO/IEC 27001 (information security management); ISO/IEC 27017 (cloud security) and ISO/IEC 27018 (PII in public clouds) where relied on.

Confirm the current version and clause numbers of each reference before issue.

16. Attachments

17. Revision history

Filled specimen

The following shows the responsibility, supplier, and acceptance sections completed for an example multi-tenant SaaS quality management system, so you can see the level of detail an inspector expects. The company, vendor, and numbers are illustrative; replace them with your own.

In this example the team drew the responsibility line first, read the SOC 2 report rather than filing it, pulled the four CUECs into its own control set, found the in-app retention was shorter than the legal obligation and closed the gap with a qualified export, tested only what it owned, and set re-assessment on both a clock and a trigger. That sequence, draw the line, evidence the supplier, claim the CUECs, test your own scope, schedule re-assessment, is exactly what a reviewer is expected to demonstrate.

Common inspection findings this template prevents

• A control in the stack with no owner, because the company assumed the vendor had it and the vendor assumed the company did.
• A SOC 2 or ISO certificate on file but never read, with exceptions and CUECs unassessed and the customer controls never implemented.
• An audit report whose scope covers a different service or region than the one actually used.
• The supplier’s validation pack treated as the company’s validation, with no customer testing of intended use or configuration.
• Continuous vendor releases changing a validated system with no process to detect, assess, or regression-test the change.
• In-application data retention shorter than the GxP retention obligation, with no qualified export or archive to bridge it.
• No exit plan, so GxP records cannot be retrieved complete and usable if the vendor relationship ends.
• A new sub-processor or a changed data region added by the vendor and never re-assessed.
• A gap between consecutive SOC 2 audit periods, leaving a window with no independent assurance.

How to adapt this template

1. Set your document number, owner, service model, and effective date in the header, and link your URS and risk assessment.
2. Adjust the shared-responsibility matrix in section 6 to your actual service model; an IaaS or PaaS arrangement moves more controls to the customer column than the SaaS-typical split shown.
3. Replace the certifications in section 7 with the exact reports you hold, confirm each one’s scope and period, and list every CUEC the report hands back into section 8.
4. Separate true configuration from customization in section 9 so the testing in section 11 is proportionate.
5. Fill the data table in section 10 with your real regions, sub-processors, retention, and exit terms, and confirm the in-app retention against your legal obligation.
6. Set the re-assessment frequency and trigger list in section 13 to your risk level and your vendor’s release cadence.
7. Confirm every regulation in section 15 against the current published version before issue.