A supplier assessment should answer how the service will be controlled
SaaS can reduce infrastructure work, but it does not make the regulated use of a system someone else’s problem. The organisation remains responsible for defining intended use, assessing risk, approving the service, controlling access and data, and retaining evidence. The {A("FDA quality-agreement guidance", S["quality_agreements"])} is focused on contract manufacturing arrangements, but its central lesson is broadly useful: responsibilities should be clearly defined rather than assumed.
Start with intended use and data
Describe the process, data, users, integrations, records, retention period, and decisions the service will support. Classify the impact if the service is unavailable, inaccurate, changed without notice, or unable to return records. This gives procurement and quality teams a common basis for supplier questions.
Supplier questions to document
- What quality system governs development, release, support, incidents, and corrective action?
- How are customer environments, roles, configuration, and data separated and protected?
- What validation or assurance evidence exists, and what part of the customer intended use remains to be verified?
- How are changes communicated, assessed, tested, and approved when they affect the customer process?
- How are audit trails, backups, restoration, retention, export, and deletion controlled?
- What are the service levels, incident-notification expectations, support ownership, and escalation paths?
- What happens at termination, including data format, timing, assistance, retention, and secure deletion?
- Which subcontractors or hosting regions are involved, and how are they governed?
Certificates are evidence, not the conclusion
Independent certifications and audit reports can inform the assessment. They do not automatically prove that the service is fit for your process or that your configured workflow is validated. Review scope, dates, exceptions, complementary customer controls, and the relationship to your intended use. Record what the supplier evidence covers and what your organisation must still test or control.
Put the shared model in the contract
The agreement should identify responsibilities for access, change notices, incidents, records, support, audits, data return, and exit. Tie those obligations to operational procedures and validation records. A supplier review that ends at contract signature has missed the lifecycle.
Use the VLMS lifecycle view to keep supplier evidence, risks, requirements, approvals, and review dates connected. Good supplier qualification is not suspicion. It is clarity.
Build a defensible SaaS qualification package
Start with the system, process, and evidence questions that matter to your team.
Talk with VLMS about your validation programme →