Blog Post

The Fast Track to Audit Readiness: How to Qualify Vendors and Validate Software with Confidence

Loading…

Nancy DiGioacchino

VP, Quality Management and Global Compliance

Suppose you buy two identical digital scales.

One will measure coffee beans in an office kitchen. The other will measure material used in a laboratory process.

The scales are the same. Their intended uses are not. If the kitchen scale is wrong, the coffee may taste bad. If the laboratory scale is wrong, the result could affect an important record or decision.

You would not demand the same evidence for both scales. You would first ask what each one must do, what could happen if it fails, and how much confidence you need before relying on it.

Software should be assessed the same way.

The same company can be both customer and vendor

Florence sits on both sides of the vendor relationship. We evaluate the systems that support our operations, while our customers evaluate Florence before using our platform in clinical research workflows. In both cases, the central questions are the same:

Is the vendor capable of providing the service?
Is the product fit for its intended use?

This is a shared responsibility. The vendor provides evidence showing how the standard product was designed, tested, released, and maintained. The customer determines whether that evidence is sufficient for its own procedures, configurations, integrations, and risks. Florence formalizes this division through its shared-responsibility model: Florence addresses the platform’s technical controls, while customers manage the procedural controls within their organizations.[1]

Qualification and validation are not the same thing

People often use “vendor validation” to describe the entire review, but qualification and validation serve different purposes.

Vendor qualification is the broader process used to determine whether a vendor and its product are acceptable for a defined use. It may include reviewing the vendor’s quality system, security controls, development practices, continuity planning, support model, and past performance.

Software validation is a more focused activity performed when the system and its intended use require it. It asks whether the software, as configured and used by the customer, performs as intended.

A qualified vendor may still offer a product that does not fit a particular use. A strong product can also become risky when it is configured poorly or used outside the purpose that was originally assessed.

ICH E6(R3) supports this risk-based approach. It states that computerized systems used in clinical trials should be fit for purpose, with controls proportionate to the risks to participants and the importance of the data involved.[2]

The goal is not to label a vendor “validated.” It is to show that the vendor is qualified and, when validation is required, that the software is fit for its intended use.

Start with the job, not the questionnaire

A vendor questionnaire can collect useful information, but it cannot tell you which answers matter until the intended use is clear.

“We will use the system to create, route, approve, electronically sign, store, and retrieve controlled training records.”

That sentence immediately shapes the review. User access matters. Electronic signatures matter. The audit trail matters. Record retention matters. An error could affect evidence that personnel were qualified to perform their work.

Before collecting documents, define:

What process will the software support?
Who will use and administer it?
What data or records will it create, change, store, transmit, or delete?
What systems will it connect to?
What decisions or activities will rely on its output?
What would happen if the software produced the wrong result or became unavailable?
Will any AI-enabled features be used?

Focus on the functions your organization will actually use, not the entire product catalog. If a platform contains twenty modules and you use four, the review should concentrate on those four and the connections between them.

Let risk determine the depth of the review

Once the intended use is defined, ask what could reasonably go wrong.

Data access is part of the answer, but it is not the whole answer. The review should consider whether failure could affect:

A participant’s rights, safety, or well-being
The reliability or integrity of clinical trial data
A regulated record, approval, or signature
The confidentiality or availability of sensitive information
A critical customer or business service
The ability to detect and correct an error

A general administrative tool with no sensitive data or regulated function may require a lighter review. A system that manages trial records, transfers data between clinical systems, or supports regulated decisions will usually require more evidence and testing.

The risk classification is not the final decision. It determines the depth of review and testing required. This directs effort toward the functions whose failure would matter instead of treating every feature as equally important.

Review the vendor’s evidence

A vendor should be able to explain how its product was built, tested, released, and maintained. Useful evidence may include requirements, risk assessments, test summaries, traceability records, validation certificates, release notes, known issues, security reports, and continuity information.

A document is useful only when it supports the use being assessed.

A validation certificate may cover an older version. A test summary may exclude the module you plan to use. A security report may confirm that controls exist without showing that your workflow behaves correctly. Vendor testing may leave your configuration and integrations untouched.

For each important document, ask:

Is it current?
Does it cover the product version and functions we will use?
Does it address our critical requirements?
Are exceptions and known issues visible?
Will the evidence remain available during an audit or inspection?

EMA guidance states that a responsible party may rely on vendor validation documentation after determining that the vendor’s validation activities and supporting documentation are adequate. The documentation must cover the customer’s intended use and defined requirements. Additional validation may still be needed, and the responsible party remains ultimately responsible for the system used in the trial.[3]

That is the balance: reuse credible evidence without giving up independent judgment.

Test what is unique to your use

The vendor can test the standard product, and the customer does not always need to repeat that testing. When a qualified vendor provides adequate validation evidence for out-of-the-box functionality, customer acceptance testing may be limited to the configurations, integrations, workflows, or requirements unique to the customer’s intended use. In some cases, the vendor’s validation evidence may provide sufficient support for standard functionality without additional customer testing.[3]

Suppose a system will be used to approve a regulated record.

The business requirement may state:

“Only an authorized approver may complete the approval.”

The acceptance criteria could require that:

A standard user cannot approve the record.
An authorized user can approve it.
The system records the approver’s identity and the date and time.
The approval remains linked to the correct record.
The audit trail captures the action.

The customer tests these conditions in the configured environment and records the results. If the system does not behave as expected, the issue is documented. The customer then corrects the issue, adds a control, accepts a justified residual risk, or decides that the system cannot be used as planned.

This creates a visible evidence chain:

Intended use → risk → requirement → acceptance criterion → evidence or test → result → exception or mitigation → approval

When customer acceptance testing is needed, it should not recreate the vendor’s development and validation work. It should focus on the critical workflows, configurations, roles, integrations, or other requirements that are specific to the customer’s intended use.

Add an AI checkpoint

AI now appears inside ordinary business software. A summarization tool, recommendation engine, document classifier, or writing assistant may arrive as an optional feature in a product that was approved years earlier.

Do not stop at asking whether the product uses AI. Identify the specific feature, the data it receives, and the action or output it produces.

Ask:

Is the feature enabled for our use?
What information is sent to the model?
Are prompts, outputs, or derived data retained?
Can our data be used to train or improve a shared model?
Is another company providing the underlying model?
Does the output advise a person, or can it change a record or trigger an action?
What must a reviewer check before relying on the output?
How are errors, overrides, and material changes monitored?

AI may also require a different kind of acceptance test. A conventional workflow often has one expected result. An AI feature may need a representative set of cases and defined performance limits.

For example, an AI-generated document summary could be tested to confirm that it captures specified facts, avoids unsupported statements, preserves links to the source material, and remains a draft until a qualified person reviews it.

For generative AI, NIST recommends updating vendor due diligence for embedded AI capabilities, assessing data privacy and third-party risks, documenting intended use, and monitoring systems after deployment.[4]

AI does not replace the validation framework. It changes the risks and the evidence needed to support the decision.

Define the approval boundaries

A completed review should end with a clear outcome:

Approved, approved with conditions, or not approved.

The record should identify the version, modules, configuration, integrations, data types, AI features, and intended use assessed. It should also record unresolved issues, controls, and acceptance of any remaining risk.

These boundaries prevent approval from expanding silently.

Approval of a document repository does not automatically cover a new electronic signature process. Approval of a platform without AI does not automatically cover an AI assistant added later. A new integration may change the risk even when the core application has not changed.

Keep the decision current

The review does not end when the system goes live.

The product, the vendor, and the way the customer uses the system will change. A defined review process should identify changes that require another assessment, including:

A major release or new module
A material configuration change
A new integration or data transfer
Expanded access to sensitive or regulated data
A significant incident or performance failure
A change in hosting or subprocessors
New or expanded AI functionality
A new regulated use

Periodic review should consider support performance, downtime, known issues, security documentation, and whether the intended use remains accurate.

A vendor that passed the first review can become unsuitable later. A vendor that once had a weakness may improve. The decision should follow the evidence available now.

Faster reviews come from better-ordered work

A risk-based approach does not make reviews faster by removing important questions. It makes them faster by asking those questions in the right order.

First define the use. Then identify the risk. Review the evidence that already exists. Test the customer-specific gaps. Document the decision and monitor for changes.

Florence applies this logic from both perspectives. We qualify the vendors that support our operations, and we provide development, testing, release, and validation evidence to customers evaluating Florence.

Florence customers can access product-specific Part 11 checklists, user acceptance testing templates, and shared-responsibility resources to support their review.[5] By starting with Florence’s existing validation evidence, customers can avoid rebuilding work that has already been completed and focus on the configurations, integrations, workflows, and risks unique to their intended use.

The result is not less validation. It is less duplicate validation.

When vendor evidence and customer testing fit together, audit readiness becomes more than a folder of questionnaires and certificates. It becomes a documented explanation of why the organization trusts the software for the work it is expected to perform.