Many life sciences organizations commonly ask this question when implementing a SaaS platform:
“If the vendor already validated the system, what do we still need to do?”
The answer is straightforward. The vendor is responsible for the platform it develops, operates, and maintains. The regulated company remains responsible for how that platform is configured, governed, and used within its own GxP processes.
This distinction is one of the most important concepts in modern SaaS validation. Vendor validation and customer validation are not competing activities. They address different responsibilities and generate different evidence.
Understanding those ownership boundaries helps organizations focus validation effort where it adds the most value.
The Real Question Is Not Validation. It Is Ownership.
When teams discuss SaaS validation, the conversation often focuses on testing.
In reality, the more important discussion is ownership.
Who owns system configuration?
Who owns user access?
Who owns data governance?
Who owns periodic review?
Who owns the final decision that a system is fit for intended use?
These responsibilities do not automatically transfer to a vendor simply because the software is hosted externally.
A SaaS deployment succeeds when both parties understand which activities belong to the vendor and which remain with the regulated company.
What the Vendor Typically Owns
Most SaaS vendors are responsible for the platform itself.
This typically includes:
- Software development and maintenance
- Platform testing
- Release management
- Infrastructure operations
- System monitoring
- Cybersecurity controls within the hosted environment
- Backup and disaster recovery capabilities
- Defect management
- Platform documentation
- Release notes and change communications
Many vendors also provide supporting compliance documentation such as:
- Validation summaries
- Testing evidence
- SOC reports
- Security assessments
- Quality certifications
- Service level agreements (SLAs)
These documents can significantly reduce validation effort by providing evidence that the regulated company can leverage during supplier qualification and validation activities.
What the Regulated Company Owns
The regulated company remains accountable for how the platform supports regulated business processes.
This responsibility does not change because the software is delivered as a service.
Intended Use
The intended use statement belongs to the regulated company.
The vendor can explain platform capabilities, but only the customer can define how the system supports manufacturing, quality, laboratory, clinical, or regulatory processes.
Two companies can implement the same SaaS application and require very different validation approaches because their intended use is different.
Configuration Decisions
Most modern SaaS platforms contain configurable workflows, approval routes, business rules, permissions, forms, dashboards, and notifications.
The vendor provides the functionality.
The regulated company owns how that functionality is configured.
User Access and Role Management
Organizations remain responsible for:
- User provisioning
- Role assignments
- Segregation of duties
- Access approvals
- Access reviews
- Account deactivation
These activities are often reviewed during audits because they directly impact data integrity and process control.
Procedures and Training
The vendor may provide system training.
The regulated company remains responsible for ensuring personnel understand how to use the system within approved business processes.
Training records, procedures, and work instructions remain customer-owned controls.
Data Governance
Ownership of regulated records does not transfer to the SaaS provider.
The regulated company remains responsible for:
- Data review processes
- Data retention requirements
- Record ownership
- Audit trail review expectations
- Data integrity controls
- Business continuity planning
Periodic Review
The responsibility to evaluate whether the system remains fit for intended use remains with the regulated company throughout the system lifecycle.
Periodic review programs typically assess:
- Vendor performance
- Significant releases
- Deviations and incidents
- User access reviews
- System changes
- Validation status
Vendor Evidence vs Customer Evidence
One of the simplest ways to understand SaaS validation ownership is to separate vendor evidence from customer evidence.
| Vendor Evidence | Customer Evidence |
|---|---|
| Platform testing | Intended use |
| Release testing | Risk assessments |
| Security documentation | Configuration verification |
| Disaster recovery evidence | User access controls |
| Quality certifications | Procedures and training |
| Release notes | Periodic reviews |
| Service level commitments | Validation conclusion |
Both types of evidence support compliance, but they answer different questions.
Vendor evidence demonstrates how the platform was built and maintained.
Customer evidence demonstrates how the platform supports the regulated process.
Where Quality Agreements and SLAs Fit
Quality Agreements and Service Level Agreements are often overlooked when discussing SaaS validation responsibilities.
These documents help define operational ownership between the vendor and the regulated company.
For example:
- Who notifies customers of major releases?
- Who investigates service interruptions?
- Who maintains backup processes?
- Who provides audit support?
- Who reviews cybersecurity incidents?
Clearly defined agreements help prevent assumptions and establish accountability throughout the system lifecycle.
Practical Examples
eQMS Platform
A company implements a SaaS electronic Quality Management System for deviations, CAPAs, change controls, and document management.
The vendor owns the platform and its maintenance. The customer owns workflow configuration, approval routing, role design, training, and validation of how those workflows support the quality system.
LIMS Platform
A laboratory implements a SaaS LIMS.
The vendor may provide testing evidence for standard functionality. The laboratory remains responsible for sample lifecycle controls, user permissions, procedural controls, and verification of any configured workflows or integrations.
AI-Enabled SaaS Platform
A company deploys an AI-enabled document review platform.
The vendor may test the underlying model and software functionality. The regulated company remains responsible for defining acceptable use, establishing human review controls, and determining how AI-generated output is incorporated into regulated decision-making.
What Belongs in the Customer Validation Package?
A common misconception is that a vendor validation package is the customer validation package.
In practice, customer validation packages typically include:
- Intended use documentation
- Supplier assessment records
- Risk assessments
- Configuration assessments
- User access strategy
- Testing appropriate to intended use
- Procedural controls
- Training records
- Validation summary documentation
The vendor package supports these activities, but it does not replace them.
Practical Perspective
The most efficient SaaS validation programs do not duplicate vendor activities. They leverage vendor evidence where appropriate and focus internal effort on the responsibilities that only the regulated company can own. Clear ownership boundaries create stronger validation programs, better supplier relationships, and a more sustainable compliance model throughout the system lifecycle.