For regulated products, the system owner, not the software vendor, is responsible for demonstrating that COTS software is fit for its intended use. That means documenting a risk-based validation proportional to the system's criticality, backed by evidence you can defend to an inspector, anchored to FDA, EMA, and ICH expectations.

TL;DR:

>

- Validation efforts must be proportional to the system's criticality, with high-risk systems requiring full validation, traceability, and supplier audits.
- Regulatory standards such as FDA, EMA, ICH, and GAMP 5 dictate the evidence needed, emphasizing test reports, risk assessments, and documentation of version-specific validation.
- Vendor evidence is acceptable for reliance only after assessing sufficiency; incomplete documentation requires additional validation efforts before approval.
- Re-validation is necessary after major changes or patches that impact validated functionality, with detailed impact analysis and updated documentation required.
- Automated validation platforms can significantly reduce documentation gaps, improve traceability, and save time during audits by enforcing ALCOA+ standards at record creation.

Table of Contents

When Is COTS Software Validation Required?

Validation is required whenever a commercial-off-the-shelf (COTS or OTS) tool touches data, decisions, or processes that affect product quality, patient safety, or regulatory submissions. The FDA's guidance on off-the-shelf software makes clear that sponsors and manufacturers carry ultimate responsibility, regardless of who wrote the code. EMA guidance echoes this for clinical systems: sponsors remain accountable even when a vendor supplies the platform.

COTS and SaaS often get used interchangeably, but they're not the same thing. COTS is software purchased as-is, installed on infrastructure you control (a LIMS, a document management system). SaaS is vendor-hosted and updated on the vendor's schedule, which changes how you approach change control. Salesforce, for instance, is SaaS with COTS-like validation obligations layered on top.

Three terms get conflated constantly:

  • Verification confirms the software was built correctly against its specification.
  • Validation confirms it works correctly for your intended use, in your environment.
  • Testing is the activity that generates evidence for both.

What Regulatory Standards Apply to COTS Validation?

An inspector expects your validation file to cite the frameworks that govern your evidence, not just gesture at "GxP compliance." Build your file around these:

  1. FDA's OTS software guidance requires test plans and results showing the software addresses identified device hazards, plus version-specific validation.
  2. EMA's notice on computerized systems in clinical trials requires sponsors to retain validation documentation or perform supplemental validation when vendor evidence falls short.
  3. ICH E6(R2) sets expectations for computerized systems used in clinical trials.
  4. 21 CFR Part 820 and Part 11, plus EudraLex Annex 11, govern quality system and electronic record requirements.
  5. GAMP 5 principles provide the risk-based scaffolding most auditors expect to see referenced.

Each expectation maps to a specific evidence type: test reports satisfy V&V, a traceability matrix satisfies requirements coverage. Your Documentation Level, Basic or Enhanced, determines how much of that evidence you generate. Basic suits low-risk, low-configuration tools; Enhanced applies once the software touches submission data or patient safety.

How Do You Scope Validation by Risk?

Not every COTS tool deserves the same scrutiny. A spreadsheet tracking office supplies doesn't need the same rigor as a LIMS feeding batch release decisions. GAMP-style categorization gives you a defensible way to draw that line.

Map system function to consequence:

  • Low criticality: administrative tools with no GxP data touchpoints. Light testing, minimal documentation.
  • Medium criticality: configured COTS affecting internal workflows but not submissions or release. Functional testing plus configuration verification.
  • High criticality: systems generating data for regulatory submissions, batch release, or anything touching patient safety. Full V&V, traceability, and often supplier audit.

GAMP 5's category framework gives structure to this decision, but the judgment call is yours to make and document.

Pro Tip: Write your risk rationale as if the inspector will read it cold. "Category 4, high risk, because system output feeds batch disposition" survives scrutiny. "Standard validation applied" does not.

Record the decision in your risk assessment with the specific function, consequence, and mitigating controls. A documented risk-based approach is what separates defensible scoping from guesswork an auditor will challenge.

What Documents Belong in a COTS Validation Package?

An inspection-ready package needs objective evidence tied to specific claims, not a folder of generic templates. At minimum, include:

  • Validation plan and User Requirements Specification (URS)
  • Risk management file with documented criticality rationale
  • Test plans, test reports, and a traceability matrix linking requirements to test cases
  • Release notes for the validated version and configuration
  • Defect lists and resolution status

Vendors frequently withhold internal test artifacts, source code, or unit-test evidence, that's expected, not a red flag. When vendor documentation is thin, NASA's experience with COTS in safety-critical systems offers a useful precedent: treat the software as a black box and supplement with system-level testing, integration testing, and regression evidence generated on your side.

Every artifact should reference the exact vendor version and configuration tested. A traceability matrix that doesn't specify "v4.2.1, configuration profile B" is a gap an auditor will find in minutes.

How Should You Handle Vendor Reliance and Audits?

Reliance on vendor evidence is permissible, but only after you've assessed whether that evidence is sufficient. Request the SRS or equivalent specification, test summaries, defect logs, and the vendor's maintenance and patch policy before you decide how much sponsor testing to add.

  • Ask for contractual inspection access to vendor documentation and quality records.
  • Require change-notify clauses so patches don't land without warning.
  • Reserve the right to audit the vendor's development process for high-criticality systems.

If vendor evidence is incomplete or unverifiable, EMA's Annex III guidance on computer systems inspections puts the burden back on the sponsor to perform additional validation. Reserve full supplier audits for high-risk systems; targeted evidence requests usually suffice below that threshold.

When Does a Vendor Update Trigger Re-Validation?

Version control is one of the most common inspection focus points precisely because teams underestimate how often a "minor" patch touches validated functionality.

  1. Classify the change. A security patch with no functional impact is minor; a UI change affecting data entry fields or a new calculation engine is major.
  2. Run impact analysis. Identify which validated requirements the change touches, then determine what regression testing is needed to confirm they still hold.
  3. Document and sign off. Update release notes, re-run the relevant regression suite, and record the decision in your configuration records, even when the conclusion is "no re-validation required."

Specifying the exact vendor version and configuration in your URS from the start makes this workflow far less painful. It gives you a fixed baseline to compare against every time a patch notification arrives.

How Automation Closes Common COTS Evidence Gaps

Most validation gaps aren't caused by weak testing. They come from documentation that can't survive scrutiny: missing timestamps, unclear traceability, review evidence assembled after the fact. Agentic validation platforms address this by enforcing ALCOA+ checks at the moment a record is written, not weeks later during a pre-audit scramble.

The traceability matrix updates live as tests execute, and every record carries a timestamped, versioned audit trail from authoring through review. Teams using this approach report over 70% time savings in authoring compared to manual CSV documentation cycles.

That shift matters most for teams juggling dozens of COTS systems where manual documentation simply can't keep pace with change control demand.

What Should QA Leads Actually Do First?

Start with three moves: risk-classify every COTS system in scope, secure vendor documentation before you need it in an emergency, and run targeted testing on the highest-criticality functions first. Present your validation package to an inspector as a risk-first narrative, criticality, mitigation, evidence, not a document dump. Escalate to a formal supplier audit or contract renegotiation only when vendor evidence gaps sit on a high-risk system you can't otherwise defend.

— Matt

How Qualitum Turns COTS Validation Into Audit-Ready Evidence

Qualitum gives QA and regulatory teams a faster path to defensible COTS validation than building traceability matrices and test reports by hand. Every record is checked against ALCOA+ at write-time and again at review-time, so the evidence you generate during scoping, testing, and change control is inspection-ready from the moment it's created, not patched together before an audit.

Qualitum

The platform integrates with existing quality management systems, generates live traceability matrices automatically, and applies the same rigor to Basic and Enhanced documentation levels without adding authoring burden to your team. For teams managing dozens of COTS systems across GxP functions, that difference shows up directly in validation cycle time.

If you want a clear picture of where your current COTS validation approach has gaps before your next inspection, request a Free Validation Gap Report and see exactly where automated evidence collection would save the most time.

Sources

FAQ

What Is COTS in Software Testing?

COTS stands for commercial-off-the-shelf software, meaning a tool purchased and used largely as-is rather than custom-built for one organization. In testing, it means verifying the specific version and configuration you deployed performs correctly for your intended use.

What's the Difference Between COTS and SaaS?

COTS software typically runs on infrastructure you control and updates on a schedule you manage, while SaaS is vendor-hosted and updated by the vendor, often without your direct control over timing. Both carry the same underlying validation obligation: you must prove fitness for intended use regardless of hosting model.

Is Salesforce a COTS Application?

Salesforce is delivered as SaaS, but it functions like COTS from a validation standpoint because it's configured rather than custom-coded and used as-is within regulated workflows. Teams using it for GxP processes still need risk-based validation covering configuration, integrations, and vendor change control.

Can You Give Me an Example of COTS Software?

Common examples in regulated environments include laboratory information management systems (LIMS), electronic quality management systems, and enterprise resource planning platforms used for batch records. Any of these requires validation scoped to how critically it affects data integrity or patient safety, an approach platforms like Qualitum are built to automate.

FAQ

What Is COTS in Software Testing?

COTS stands for commercial-off-the-shelf software, meaning a tool purchased and used largely as-is rather than custom-built for one organization. In testing, it means verifying the specific version and configuration you deployed performs correctly for your intended use.

What's the Difference Between COTS and SaaS?

COTS software typically runs on infrastructure you control and updates on a schedule you manage, while SaaS is vendor-hosted and updated by the vendor, often without your direct control over timing. Both carry the same underlying validation obligation: you must prove fitness for intended use regardless of hosting model.

Is Salesforce a COTS Application?

Salesforce is delivered as SaaS, but it functions like COTS from a validation standpoint because it's configured rather than custom-coded and used as-is within regulated workflows. Teams using it for GxP processes still need risk-based validation covering configuration, integrations, and vendor change control.

Can You Give Me an Example of COTS Software?

Common examples in regulated environments include laboratory information management systems (LIMS), electronic quality management systems, and enterprise resource planning platforms used for batch records. Any of these requires validation scoped to how critically it affects data integrity or patient safety, an approach platforms like Qualitum are built to automate.