THE PRACTITIONER POSITION
Supplier evidence is an input to an validation decision, not the decision itself. A vendor can demonstrate that its product was developed and tested under controlled conditions. Only the regulated user can establish that the configured service, interfaces, data, roles, and operating process are fit for the customer’s intended use.
THE THREE LEVERAGE QUESTIONS
Relevance: Does the evidence cover the product version, enabled capability, configuration, platform, data flow, and failure that matter to the customer?
Credibility: Is the method transparent enough to understand who performed the work, in which environment, against which acceptance criteria, with what independence and result?
Coverage: After the evidence is accepted, what customer-specific gap remains around configuration, integration, migration, security roles, procedures, and actual use?
THE Existing Evidence Assessment
Level 1 — Claim. Marketing language, certificates without scope, or an unsupported statement that the system is validated. Useful for orientation, not for a conclusion.
Level 2 — Summary. Test summaries, quality manuals, release notes, and audit responses. These may establish process maturity and broad coverage.
Level 3 — Traceable evidence. Requirements, risk records, test protocols, results, defect dispositions, and configuration-specific evidence that can be mapped to a customer risk.
Level 4 — Observable control. A customer can witness behavior, inspect logs, reconcile transactions, review audit trails, or monitor a service-level control in operation.
Level 5 — Customer-specific confirmation. Focused testing and process challenge address the residual gap created by the customer’s configuration and use.
WORKED EXAMPLE: ELECTRONIC SIGNATURE
A SaaS supplier provides a SOC report, development lifecycle summary, and test certificate for electronic signatures. The customer configures two approval steps, delegates roles through an identity provider, and exports signed records to a data lake.
The supplier package supports confidence in core signature logic and development controls. It does not establish that the customer’s identity mapping prevents shared accounts, that the configured meaning of signature is displayed, that approval order is enforced, or that the export retains the signature-record linkage. Customer evidence therefore focuses on those boundaries instead of repeating every vendor functional test.
DOCUMENT THE LEVERAGE DECISION
For each critical function, record the evidence relied upon, its source and scope, the failure it addresses, any limitation, the complementary customer control, and the accountable conclusion. This makes leverage visible and reviewable. It also prevents a vendor audit from becoming a ceremonial checklist detached from intended use.
WHEN NOT TO LEVERAGE
Do not rely materially on evidence that cannot be matched to the deployed service, hides unresolved critical defects, excludes the relevant module, lacks basic execution integrity, or conflicts with observed performance. Increase independent testing when supplier transparency is weak, the use is novel, detectability is poor, or the potential harm is high.
SCOPE AND LIMITATIONS
This method does not prescribe a universal supplier score or minimum document list. Evidence sufficiency is contextual and must account for applicable requirements, contractual rights, technical architecture, intended use, and credible harm.
Practitioner interpretation; apply the sources within their scope and follow your approved procedures. Original publication and source links are retained; this revision updates the summary and resource navigation.