Most validation programmes re-prove things their vendor has already proved, at their own cost, and then describe the result as rigour. It is not rigour. It is effort spent on a risk that was already addressed, which means it is effort not spent on a risk that was not.
The FDA's Computer Software Assurance guidance, finalised in September 2025 and reissued in February 2026, makes vendor evidence a legitimate assurance activity rather than a shortcut you apologise for. The condition is that you assess it and document the assessment. That condition is the whole discipline.
This is how we approach supplier qualification so that leaning on vendor evidence survives an audit.
What you are actually entitled to rely on
Vendor evidence is not a single thing, and the distinction matters because the four categories carry very different weight.
- Evidence you have read. A vendor test summary, a validation certificate, an audit report you have reviewed. This is usable.
- Evidence that exists and you have not seen. A vendor who says their testing is comprehensive and will not show you anything is offering a claim, not evidence. Common with large platform vendors, and the honest treatment is to record that you could not obtain it and test accordingly.
- Certifications about the organisation. ISO 27001, SOC 2 and ISO/IEC 42001 say something real about how a supplier runs itself. None of them says the software does what your intended use requires. They support the supplier assessment; they do not substitute for validation.
- Evidence about a different version. Testing performed against a release you are not running is weaker than it looks, and this is easy to miss with continuously updated cloud products.
Intended use is the line vendor evidence cannot cross
A vendor can prove their software works. They cannot prove it works for what you are using it for, because they do not know your process, your configuration or your data.
That line is clean and it is where the split in your test strategy belongs. Platform behaviour, standard supplied functionality and infrastructure sit on the vendor's side. Your configuration, your workflows, your master data, your integrations and your intended use sit on yours, and no amount of vendor documentation reduces that obligation.
The practical consequence: for a well-documented commercial product with light configuration, vendor evidence can carry a large share of the package. For the same product configured heavily, it carries much less, because most of what you depend on did not exist when the vendor tested.
Risk-based supplier assessment
Not every supplier warrants the same scrutiny, and treating them uniformly means either over-auditing a commodity tool or under-auditing something that could affect product. Two factors set the depth: what the software does in your process, and how much you are relying on the vendor rather than your own testing.
A system making or directly supporting a GxP decision, where you intend to rely substantially on vendor evidence, warrants real diligence — an audit, whether on site or remote, or at minimum a thorough documented questionnaire with evidence attached. A low-impact tool where you are testing the behaviour you depend on anyway warrants a proportionate paper assessment.
Write the reasoning down either way. The assessment is the deliverable, and an auditor asking why you relied on a vendor is asking to read it.
Cloud and SaaS: the shared responsibility problem
Cloud changes supplier qualification more than most organisations have adjusted for. With on-premise software you qualified the installation. With SaaS, the infrastructure, the platform and increasingly the application version are outside your control entirely.
What you need from the supplier is therefore different: how changes are communicated and on what notice, whether you can defer or stage an update, what the qualification status of their infrastructure is, where data resides, how it is segregated from other tenants, and what happens to it on exit.
The change notification question is the one that bites. If a vendor can update production with little notice and no option to defer, your validated state has a dependency you do not control, and the only honest mitigations are monitoring and a defined response rather than a pretence of control. cloud & SaaS validation covers how to document that defensibly.
AI components and what to ask for
Where a supplier's product includes AI, the questions extend. The draft EU GMP Annex 22, published for consultation in July 2025 and not yet in force, sets out the direction clearly enough to ask against: how the model is governed, what it is and is not approved for, what evaluation gates a release, what safeguards sit on its outputs, how drift is monitored, and what happens when it is unavailable.
The reasonable ask of a vendor is that they can answer those questions about their own AI with documentation rather than assertion. A vendor who cannot has not validated their AI, and you will be the one explaining that. EU Annex 11 & Annex 22 readiness is where we assess this, and Annex 22 assurance is how we hold ourselves to the same standard.
Documenting a vendor-evidence test path
This is the part that determines whether the approach holds up, and it is mechanical once decided. For each requirement where you are relying on vendor evidence, record four things: what the requirement is, what evidence you are relying on and its version, why that evidence is adequate for your intended use, and what residual testing you are performing yourself.
Four fields per requirement. The absence of those four fields is what turns a legitimate risk-based approach into something an auditor reads as an untested system — and the difference between the two is entirely in the writing, not in the engineering.
Keeping qualification current
Supplier qualification decays. A supplier assessment that predates two product versions describes a product you are no longer running. An assessment performed before a vendor was acquired describes an organisation that no longer exists.
Set a review interval proportionate to impact and to the pace of change, and treat a major version change, an acquisition, a security incident or a change of hosting arrangement as triggers in their own right. Overdue supplier assessments are among the first things an inspector checks, they are among the cheapest to fix, and they signal whether the estate is under control. audit readiness is where that gets planned, and book a demo if you want an existing supplier file reviewed.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
