What should I understand about the supplier?
Review development practices, testing, security, change management, incident management, data handling and release management. Focus on the service you actually use and the responsibilities your organization retains.
Can supplier testing be used?
Yes, when it is relevant, reliable and provides suitable evidence for your intended use.
Check what was tested, the version and configuration, expected and actual results, unresolved defects and the controls around the test process. A certificate or supplier approval alone does not demonstrate your configured use.
When is additional testing needed?
Add local verification for configuration, interfaces, migrated data, roles, regulated records, intended-use differences and gaps in the supplier evidence. Reassess evidence after material changes.
Worked example
Example
Worked exampleFictional example. A supplier demonstrates its standard CAPA workflow. Your organization adds a site-specific approval condition and an ERP interface. Use the relevant standard-workflow evidence, then challenge the configured approval paths, unauthorized transitions and interface failures locally.
Keep the accepted evidence, limitations and additional testing decision in one review record.
Detailed practice, examples and references
Supplier assessment scope
Assess the organization and responsibilities, quality-management practices, software development lifecycle, requirements and design controls where applicable, supplier testing, release and configuration management, incident and problem management, security, backup and recovery, business continuity, data handling and retention, sub-processors, AI or model suppliers, customer notification, and contractual responsibilities.
Supplier assessment supports the validation approach. It does not replace assessment of the regulated company’s intended use, configuration, interfaces, data, electronic records, procedures, roles, or local controls.
Completed fictional assessment
A multi-tenant eQMS supplier provides a software development lifecycle summary, security control report, release process, problem-management process, recovery description, sub-processor list, and customer-change terms. The regulated company finds the supplier suitable for the proposed service, subject to contract actions for material-change notice and recovery evidence. The customer retains responsibility for its CAPA configuration, identity mapping, signed exports, migrated records, procedures, user access, and release decisions.
Related evidence decision
Use the Existing Supplier Evidence Assessment to determine what each supplier source can support and what local evidence is still required.
Regulatory and procedural context
Primary sources. FDA CSA guidance ↗ supports a risk-based approach and consideration of available information. EU GMP Annex 11 ↗ includes supplier and service-provider expectations for applicable GMP systems.
Company procedure. The organization’s approved validation, change-control, supplier-management, information-security, data-integrity, records-retention, and Quality approval procedures determine the required records, roles, and approval route.
CSVtoCSA practitioner interpretation. Supplier suitability and responsibility must be assessed for the service and intended use; a supplier assessment is not customer validation. This is a recommended validation approach, not a statement that every listed activity is a direct regulatory requirement.
Evidence assessment table
| Supplier evidence | Potential use | Key limitation |
|---|---|---|
| Requirements or specifications | Understand standard functionality and intended product behavior | May not describe local configuration or business process |
| Supplier development testing | Support standard functionality | Applicability, version, environment, acceptance criteria, and scope must be understood |
| Supplier regression testing | Support release assessment | May not cover customer-specific configuration, data, roles, or interfaces |
| Release notes | Identify reported changes and known issues | May not identify every dependency relevant to local use |
| SOC report | Support review of applicable organizational or security controls | Does not demonstrate GxP functional suitability |
| ISO certification | Provide context on supplier management systems | Does not replace validation of the intended use |
| Penetration testing | Support security assessment | Does not demonstrate regulated-process functionality |
| Backup and recovery documentation | Clarify supplier capabilities and responsibilities | Customer recovery, retrieval, retention, and interpretation needs may differ |
Evidence decision record
For each source, record the issuer, title, version, date, system or service scope, function or risk supported, review performed, credibility, limitations, accepted use, local evidence still needed, reviewer, and approval. Do not translate a certificate or pass count into functional coverage it does not contain.
Completed fictional decision
A supplier provides an SDLC summary, SOC 2 report, release notes, standard-workflow regression summary, defect list, and recovery description for a multi-tenant eQMS. The customer uses the SDLC and SOC report as context, accepts version-specific regression evidence for unchanged standard controls, and uses the recovery description to define responsibilities. Local CAPA routing, identity mapping, signed exports, migrated records, and recovery of customer-required attachments remain subject to customer testing.
Link to supplier assessment
Evidence credit depends on the service boundary and responsibility model documented in the Supplier Assessment.
Regulatory and procedural context
Primary sources. FDA CSA guidance ↗ supports a risk-based approach and consideration of available information. EU GMP Annex 11 ↗ includes supplier and service-provider expectations for applicable GMP systems.
Company procedure. The organization’s approved validation, change-control, supplier-management, information-security, data-integrity, records-retention, and Quality approval procedures determine the required records, roles, and approval route.
CSVtoCSA practitioner interpretation. Credit supplier evidence only for the version, function, configuration, environment, and failure modes it actually addresses; state the limitation and local gap explicitly. This is a recommended validation approach, not a statement that every listed activity is a direct regulatory requirement.
Existing evidence can help when it matches the claim
Supplier evidence may include development and test records, release information, known-defect lists, security reports, configuration specifications, and service arrangements. Different evidence answers different questions. A security certification does not demonstrate that your CAPA routing is correct.
Before relying on evidence, establish the product and version it covers, the tested environment, the tested behavior, the expected and actual outcomes, the handling of failures, and any exclusions. Decide whether you can review enough detail to support your use.
Example 1: Standard password behavior
A supplier test demonstrates the standard authentication behavior for the installed version. Local checks confirm your identity-provider integration and actual policy settings. The supplier record helps with the standard feature; local evidence covers your configuration and connection.
Example 2: Configured CAPA approval
The supplier proves that its workflow engine supports conditional routing. Your organization configures escalation according to site, severity, and product family. You need evidence that those local conditions route correctly, including blank fields and unauthorized edits. Engine evidence cannot establish the correctness of values the supplier never configured.
Example 3: Restricted SaaS documentation
The supplier provides only a summary and refuses detailed test records. Document what is available and why it is insufficient for particular claims. Compensating activities may include focused local testing, stronger monitoring, contractual clarification, or rejecting the proposed use. Do not describe unseen tests as reviewed.
Completed reliance note — fictional: “Supplier package SP-42 supports standard document versioning in release 8.3. It excludes our migration utility and role configuration. We will use SP-42 for standard behavior and execute local tests for migrated version relationships, effective-state permissions, and retrieval of historical approved records.”
Questions worth asking the supplier
How are significant defects communicated? Can a release be deferred? Which components can change without advance notice? What evidence identifies the deployed version? How are records returned at contract termination? How is restoration tested? Which responsibilities remain with the customer?
The output of this review should be a clear reliance decision, not just a completed questionnaire.
Typical supplier-assessment records
Depending on risk and the service provided, the validation package may include a supplier questionnaire or audit report, quality or service agreement, software development lifecycle (SDLC) summary, security and availability information, release notes, defect summary, test summary, certificate, and existing evidence assessment. Record exactly which supplier document supports which requirement or risk. Local configuration, interfaces, migrated data, roles, procedures, and UAT remain customer responsibilities unless specific evidence demonstrates otherwise.
Practitioner guidance by Sandip Thorat · Simplified 17 September 2026. Apply the requirements and approved procedures relevant to your system. Report a correction.
Questions and discussion
Ask a question or share a perspective. Contributions are reviewed before publication.
Loading contribution options…