\1.
The right question is which settings, code, interfaces, data, and supplier services affect intended use and controls.
Define the boundary
Document the SaaS service, enabled modules, configured workflows, integrations, user roles, data flows, and supplier-managed components. State which controls are performed by the supplier and which remain with the regulated organisation.
A supplier's platform validation package can support your assessment. It does not prove that your configuration, intended use, users, data, and procedures are controlled.
Classify the change
Configuration changes may alter approval routes, calculations, required fields, retention, notifications, or access. Custom code may add another layer of lifecycle and regression risk. Interfaces can create risk even when the SaaS screen itself is unchanged.
Classify by impact, not by the label used in a vendor release note. A single setting can matter more than a large cosmetic customisation.
Test the tenant and process
Use representative configuration and controlled data. Verify workflows, roles, audit trails, electronic signatures, reports, integrations, error handling, and data exports where relevant. Test the decisions the system supports, not just the configuration screen.
For vendor releases, review the supplier change notice, assess impact on your intended use, and run focused regression evidence where required.
Control supplier evidence
Assess supplier quality information, release practices, incident communication, security and continuity controls, support arrangements, and access to records. Keep a supplier record that explains what was reviewed and what remains your responsibility.
The SaaS supplier qualification guide covers questions to ask before relying on a cloud service.
Keep the configuration reproducible
Maintain an approved configuration baseline, change history, environment details, and export or backup strategy. If a setting cannot be reconstructed, investigation and recovery become harder than they need to be.
| Area | Validation question |
|---|---|
| Configuration | Which setting changes the regulated workflow or control? |
| Customisation | What code or extension needs lifecycle evidence? |
| Integration | What data crosses the boundary and how is it reconciled? |
| Supplier release | What changed and what is the impact on intended use? |
| Responsibility | Who performs and evidences each control? |
FAQ
Does a vendor certificate replace validation?
No. Vendor evidence can support supplier qualification and reduce duplicate work, but your intended use and configuration still require assessment.
Do SaaS updates require full revalidation?
Not automatically. Use change impact and risk to determine focused review, regression, or broader evidence.
Is configuration documentation enough?
No. It should be supported by testing and other evidence appropriate to the risk.
Who owns SaaS data integrity?
Responsibility is shared according to the service and quality agreements, but the regulated organisation must know and control its responsibilities.
Decision rule: choose evidence from the consequence of failure, the control being relied on, and the ability to detect a problem. A larger document set is not automatically stronger. Clear scope, reproducible evidence, and an approved conclusion are what make the decision defensible.
Keep the rationale with the controlled record. Future reviewers should be able to see what was considered, what was tested or reviewed, what remains uncertain, and who accepted the residual risk.
During review, compare the approved requirement with observed use, current configuration, and retained evidence. That simple comparison often finds drift before an auditor does.
For related work, read our validation traceability matrix guide.
Primary sources
Bring validation work under control
VLMS Software helps healthcare teams organise validation, evidence, and audit readiness around the work that matters.
Talk to VLMS Software