A refusal to provide underlying evidence does not automatically make the vendor unacceptable, but it changes what can reasonably be relied upon. The regulated company still needs enough evidence to understand whether controls supporting its GxP use are operating effectively. 

This situation is common with large cloud and AI providers. Detailed architecture, penetration testing, source code, training data, model information, or internal validation records may be restricted. Repeatedly requesting information the vendor will never release adds little value. 

The assessment should instead identify the assurance question that remains unanswered. Independent audit reports, controlled demonstrations, summarized test evidence, contractual commitments, performance records, third-party assessments, or targeted customer verification may provide sufficient evidence for some risks. 

Inspection exposure develops when the qualification record simply states that information was "vendor confidential" and closes the issue. Restricted access explains why evidence was unavailable. It does not explain why the remaining evidence was sufficient to support continued reliance on the service. 

Operational performance should cause the original vendor assurance conclusion to be reassessed. Certifications and successful audits provide useful evidence about the vendor's control environment, but recurring incidents can show that those controls are not adequately protecting the customer's specific regulated use. 

Consider repeated interface failures, unexpected configuration changes, delayed incident notifications, data availability problems, or defects introduced through releases. None necessarily invalidates a vendor's certification. They do, however, change the evidence available to the regulated company. 

This is where supplier files can become disconnected from operational experience. The vendor remains classified as acceptable because the scheduled reassessment is current while system owners repeatedly manage problems outside the qualification process. 

A stronger governance model feeds significant incidents, service performance, deviations, change history, and unresolved issues back into vendor assurance. Continued reliance should reflect current evidence rather than the strength of the vendor's original qualification package. A certificate cannot outweigh persistent evidence from the service actually being used. 

Reproducing vendor testing is unnecessary when the company can demonstrate why that evidence is credible, relevant to its intended use, and applicable to the configuration being relied upon. Independent verification should address remaining uncertainty rather than mechanically repeat work already performed competently. 

The difficult judgment concerns applicability. A vendor may provide extensive functional and regression testing for the standard platform, while the regulated implementation depends on customer-specific configurations, workflows, permissions, interfaces, calculations, or AI-assisted functions. Vendor evidence may strongly support the base product while providing little assurance for those implementation-specific elements. 

The assessment should therefore show which assurance questions the vendor evidence answers and which remain with the regulated company. Supplier capability, test scope, configuration, traceability, results, deviations, and change controls all affect how much reliance is reasonable. 

Inspection defensibility comes from showing why evidence was accepted. "Vendor tested" is a conclusion. The supporting record should demonstrate why that testing was sufficient for the particular GxP function under review. 

The original qualification can gradually stop describing the service that is actually being used. Cloud platforms, underlying infrastructure, security controls, integrations, subcontractors, AI models, data practices, and service capabilities can change substantially while the vendor itself remains approved. 

This becomes difficult to detect when periodic reassessment concentrates on renewed certificates, questionnaires, and contracts. Those records may remain current while the technical basis for the original assurance decision has materially changed. 

A mature review should ask what has changed since the previous assessment and whether those changes alter assumptions the regulated company relies upon. Significant incidents, vendor acquisitions, new subprocessors, major platform migrations, AI model changes, altered data handling, service changes, and recurring performance issues can all justify deeper review. 

Historical qualification provides useful evidence of where the relationship began. Continued vendor assurance depends on knowing whether the conditions supporting that original decision still exist.