SaaS validation starts with the regulated process, not the vendor brochure. Define intended use, qualify the supplier, assess configuration and data, and maintain evidence as the service changes.
Why is SaaS validation different?
In a SaaS model, the vendor operates part of the infrastructure and releases changes on a schedule the customer does not fully control. The customer still owns the regulated use of the system. Validation therefore becomes a shared responsibility.
The organisation must understand what it controls, what the supplier controls, and what evidence is needed to show that the complete process remains fit for use.
What should be defined before selection?
Write the intended use before signing a contract. Describe the records, decisions, workflows, integrations, users, approvals, retention needs, and data types involved. Avoid validating a generic product while leaving the actual configuration and process undefined.
- Business and GxP process supported
- Critical records and data flows
- Required roles, approvals, and electronic signatures
- Interfaces, exports, and downstream systems
- Retention, availability, and continuity needs
- Reporting, audit trail, and review requirements
How do you qualify a SaaS vendor?
Vendor qualification should be proportionate to the risk and service. Review the supplier's quality system, development and change practices, security controls, incident process, business continuity, support model, and subcontractors where relevant.
Questionnaires are useful starting points, but they are not a complete assessment. Review available audit reports, certifications, policies, service commitments, and evidence of how the supplier manages the controls that matter to your intended use.
SaaS validation workstreams
| Workstream | Evidence to consider |
|---|---|
| Intended use | Process map, system boundary, critical functions |
| Supplier | Qualification review, contracts, service responsibilities |
| Configuration | Approved settings, roles, workflows, fields, reports |
| Integration | Interface mapping, error handling, reconciliation |
| Data | Migration, retention, export, backup, and recovery evidence |
| Testing | Risk-based tests for critical use and controls |
| Change | Release review, impact assessment, regression decisions |
What should configuration testing cover?
Test the configuration that makes the product your regulated system. That may include roles, approval paths, required fields, alerts, calculations, reports, integrations, and electronic signatures.
- Record the baseline. Capture the approved configuration and version.
- Test critical workflows. Use realistic data and roles.
- Test negative paths. Check rejected approvals, missing data, and unauthorised actions.
- Test interfaces. Confirm transfers, errors, retries, and reconciliation.
- Approve release. Record deviations and residual risk.
How should vendor changes be managed?
Cloud vendors can release frequent updates. Establish a process to review release notes, identify impact, decide whether testing is needed, and document the decision. Not every change needs a full regression cycle, but every relevant change needs an accountable assessment.
Useful control: keep a release register linking vendor changes to affected functions, impact decisions, tests, deviations, and approvals.
What should contracts cover?
Contracts and quality agreements should clarify data ownership, access, availability, incident notification, support, change communication, audit rights, subcontractors, retention, export, and exit assistance. The exact terms depend on the risk and the service, but ambiguity creates trouble during an incident or inspection.
Common SaaS validation mistakes
- Accepting a vendor certificate as proof that the configured use is validated.
- Ignoring integrations because the core application passed testing.
- Failing to test roles and approval paths with realistic users.
- Not planning how records will be exported at contract exit.
- Treating every vendor release as either harmless or a full revalidation.
What belongs in the shared-responsibility model?
Write a responsibility matrix that names the owner for each control. Include identity management, configuration, validation evidence, data classification, incident response, backup and recovery, release assessment, and record retention. This prevents the common gap where the customer assumes the vendor owns the regulated process while the vendor assumes the customer owns the configuration.
Review the model when the service, contract, integration, or intended use changes. A vendor's security controls may be strong while the customer's role design or export procedure remains weak. Cloud assurance is only as strong as the weakest customer-controlled step.
Keep a current service record with the supplier contact, escalation route, approved version, key dependencies, and exit plan. That record supports both routine review and incident response.
FAQ
Can a SaaS product be validated without access to its source code?
Yes. Assurance can use intended-use analysis, supplier assessment, configuration review, risk-based testing, contracts, and available vendor evidence.
Who is responsible for SaaS validation?
The regulated organisation remains responsible for its use of the system, while the vendor is responsible for the controls assigned to the service. Responsibilities should be explicit.
Do vendor updates require revalidation?
Assess each relevant update. The result may be documentation review, targeted regression testing, or a broader assessment depending on impact.
What about data stored in another country?
Assess legal, contractual, privacy, access, continuity, and regulatory requirements for the organisation and the records involved.
How does a VLMS support SaaS validation?
It can connect supplier records, system configuration, requirements, risks, test evidence, changes, and approvals in one controlled lifecycle.
Conclusion
Validate the service as it is configured and used. Qualify the supplier, define responsibilities, test critical workflows, and keep pace with vendor change.
Build a defensible SaaS validation plan
Turn supplier evidence, configuration, testing, and release review into one traceable record.
Plan your SaaS validation →