When Can a Regulated Customer Rely on Supplier Test Evidence?

Supplier evidence is neither decisive nor worthless. It can be strong evidence about a released product and its standard behaviour. The regulated customer still has to show that its configured service supports the intended process and remains controlled in operation.

EU GMP Annex 11 places validation and lifecycle risk management around the computerised system used by the regulated organisation. It also expects regulated users to review supplier documentation for commercial off-the-shelf products to determine whether user requirements are fulfilled, and it addresses supplier competence, reliability and responsibilities where third parties are used. Supplier documentation is therefore an input to the customer's decision, not a substitute for that decision. FDA's Computer Software Assurance guidance is limited to its stated medical-device production and quality-management-system scope. These sources support proportionate evidence decisions; they do not convert a supplier binder into a customer acceptance certificate.

Start with a claim, not a document label

Do not begin with a request for the validation pack. Begin with the claim the customer needs to make. A supplier test may support standard product behaviour, documented feature limits or a released interface contract. It normally does not support a customer's workflow rule, security model, reference data, report logic, integration mapping or procedure.

A passing supplier result can be credible and still be irrelevant to local reliance. The first control is a sentence: “We rely on this evidence to show that…”. If the answer describes the whole system, it is too broad.

Test applicability before accepting reuse

Use a short reliance record for each material claim.

The aim is not to recreate a supplier dossier. It is to make the reuse decision inspectable. A reviewer should see both the supported claim and the excluded conditions.

Separate product evidence from configured-use evidence

Supplier test evidence may support claims about standard product behaviour and released functionality within its stated scope. Supplier quality-system, audit, certification and service evidence may support different claims about development and operational controls. These evidence types should not be treated as interchangeable.

Customer evidence normally remains necessary for intended use, configuration, permissions, record lifecycles, electronic approval meaning, local reports, interfaces, data migration, procedures, training and operational readiness.

The boundary is control and applicability, not cloud versus on-premise. A supplier may test a workflow engine thoroughly. The customer still decides the routing conditions, role assignments, escalation timing and records that make a configured workflow consequential.

Review quality and currency

For a consequential claim, inspect whether the evidence identifies version, objective, prerequisites, test data, expected result, actual result, deviation disposition and approver. Compare the tested environment and configuration assumptions with the customer's service.

Also examine currency. A complete report may concern an older release or different service tier. A certificate may cover the supplier organisation but not the application, region or subprocessors used by the customer. Record these limits plainly.

ICH Q9(R1) supports science-based and proportionate quality-risk management, with the level of effort, formality and documentation commensurate with risk, complexity, importance and uncertainty. A proportionate approach can therefore justify avoiding unnecessary repetition where existing evidence is relevant, reliable and applicable. That judgement still needs to be documented against the customer's risk and intended use. It does not mean accepting an evidence gap because the supplier is well known.

Define the residual customer evidence

Each accepted supplier claim should lead to a local question.

Residual evidence may be a targeted challenge, configuration inspection, interface reconciliation or operational demonstration. It need not duplicate a supplier script. It should trace to intended use and risk.

Record the decision and reopen it

Retain the supplier evidence reference, version, review date, supported claim, applicability assessment, excluded conditions, residual evidence, open limitations and accountable decision. Link it to relevant requirements, risks and acceptance records.

Avoid blanket statements such as “supplier validation accepted”. They hide whether evidence was accepted for a product baseline, one interface or an entire business process.

Reassess when the supplier changes a relevant release, service component, hosting arrangement, interface behaviour or documented limitation. Reopen the decision when the customer changes configuration, intended use, data, roles, procedures or connected systems. Incidents and repeated deviations can show that the original claim was too broad.

Important boundaries

Supplier evidence can reduce unnecessary repetition. It does not transfer the regulated customer's accountability for its GxP process or validate a local implementation by itself. The exact acceptance record, evidence threshold and approving authority belong to the organisation's quality system and risk context.

The method in this article is Navata practitioner guidance. It organises a supplier-evidence decision and does not prescribe a universal validation deliverable set.

Sources

• European Commission, EU GMP Annex 11: Computerised Systems: validation, lifecycle risk management and the regulated organisation's computerised-system responsibilities.
• FDA, Computer Software Assurance for Production and Quality Management System Software: final guidance within its stated medical-device scope.
• ICH Q9(R1), Quality Risk Management: science-based, proportionate quality-risk management.