Who is responsible for validating a GxP SaaS system?
The regulated pharma company, not the vendor. The SaaS provider is accountable for infrastructure security and uptime; the pharma company remains fully responsible for proving the system meets its intended GxP use. Vendor certifications like SOC 2 and ISO 27001 count as supporting evidence under GAMP 5, but they reduce the validation burden — they don't remove it.
A SOC 2 report gets filed in the validation package as if it were the validation. It's evidence for one — not a substitute for it.
The Shared Responsibility Model
Cloud responsibility splits differently depending on service type, and confusing the layers is where most cloud validation gaps start.
| Service Model | Vendor Responsibility | Pharma Company Responsibility |
|---|---|---|
| IaaS (e.g. AWS, Azure) | Physical infrastructure, network, hypervisor security | OS, application, data, access control, IQ of the environment |
| PaaS | Infrastructure + runtime/platform layer | Application logic, configuration, data integrity controls |
| SaaS (e.g. LIMS, QMS, ERP) | Infrastructure, platform, application code, patching | Configuration, intended use, GxP workflows, user access |
The boundary is rarely clean in practice — incident response and patching are often shared activities. A documented responsibility matrix, not just the service agreement, is what actually protects you at inspection.
GAMP 5 Category Doesn't Change With Hosting Location
A common assumption is that moving to the cloud changes a system's GAMP 5 category. It doesn't. Category depends on configuration, not on where the system runs: an unconfigured commercial cloud system is still Category 3, a configured one is Category 4, and custom code on top — cloud-hosted or not — is Category 5. What changes in the cloud is who is responsible for qualifying the infrastructure layer underneath that category, not the category itself.
Vendor Qualification: What to Actually Check
- Documented risk assessment before contract signing, not after go-live.
- Security certifications reviewed — SOC 2 Type 2, ISO 27001 — as supplementary evidence, not the whole qualification.
- Signed quality agreement defining GxP responsibilities, not just an SLA for uptime.
- Change notification process so vendor updates enter your change control before or immediately after deployment.
- Formal audit for high-risk systems — SaaS platforms tied to batch release or product disposition warrant more than a paper review.
- Data export and retention terms confirmed before you're locked in, not discovered during an exit.
The misconception to watch for: A vendor's ISO 27001 certificate proves their information security controls are sound. It says nothing about whether your specific configuration meets your intended GxP use. Treating a certificate as "the validation is done" is the single most common cloud validation gap — the certificate belongs in the vendor qualification file, not in place of your IQ/OQ/PQ.
Validating a System That Never Stops Changing
Traditional CSV assumes a system that's qualified once and stays static. SaaS platforms update on the vendor's schedule, sometimes without advance notice. Every communicated update needs to enter your change control process for GxP impact assessment — and where the vendor controls timing, negotiate a notification window into the contract rather than discovering the change after it's already live. For GxP-critical SaaS, a pre-production environment for testing vendor updates before they hit your validated system is worth the cost.
The Exit Strategy Most Teams Forget
Validation planning rarely covers what happens when the relationship ends — a vendor is acquired, a contract lapses, or the platform is replaced. Data export format, retention obligations under 21 CFR Part 11 and Annex 11, and secure deletion terms should be confirmed at contract signing, not negotiated under pressure during a migration. Validation artefacts and qualification reports also need to be archived independently of the vendor's platform, since they must remain inspectable long after the system itself is decommissioned.
How GoVal Supports Cloud and SaaS Validation
GoVal classifies cloud and SaaS systems by GAMP 5 category and scales documentation to that classification rather than defaulting to maximum effort everywhere. Vendor qualification evidence, quality agreements, and change notifications are tracked against each system's validated baseline, and periodic review is triggered automatically by risk tier — giving teams one audit-trailed record of validation status instead of a certificate folder and a hope.
Related Topics
Frequently Asked Questions
Who is responsible for validating a GxP SaaS system — the vendor or the pharma company? +
Does a SOC 2 or ISO 27001 certificate mean a SaaS system is validated? +
What GAMP 5 category applies to cloud and SaaS systems? +
How do you qualify a SaaS or cloud vendor for GxP use? +
How is change control handled for continuously-updating SaaS platforms? +
How does GoVal support SaaS and cloud validation? +
Manage cloud and SaaS validation without losing track of vendor evidence
GAMP 5 classification, vendor qualification tracking, and change-triggered periodic review — in GoVal.