Computer system validation was designed for software a company installed, configured, and then left alone for years. SaaS breaks every one of those assumptions. The vendor owns the infrastructure, the code changes on the vendor's schedule, and the customer never sees an installer.
The regulated company still has to show that the system does what it is meant to do. The vendor still has to give them enough evidence to make that case. Most friction comes from each side expecting the other to do the work.
This article sets out what validation means under FDA rules, how the work divides between a SaaS vendor and its regulated customer, and how to keep a validated state when releases are frequent. It assumes you know where 21 CFR Part 11 applies.
What validation means here
Section 11.10(a) of Part 11 requires validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records. The predicate rules carry their own validation expectations too, for example in device and drug manufacturing.
The FDA's "General Principles of Software Validation" guidance (2002) defines software validation as confirmation, by examination and objective evidence, that software specifications conform to user needs and intended uses, and that the requirements implemented through software can be consistently fulfilled.
Two words in that definition carry the weight. Intended use means validation is always for a specific purpose. The same eQMS product can be validated by two customers in different ways, because they use different modules for different records. Objective evidence means test results and records, not assurances.
It follows that a vendor cannot validate a product on its customers' behalf. It can supply evidence that its own development and testing are controlled, which the customer then relies on to reduce its own effort.
Who does what
A workable split looks like this. The customer owns the validation; the vendor supplies inputs.
The regulated customer:
Writes the user requirements for its intended use
Assesses risk, and decides how much testing each function needs
Assesses and qualifies the vendor as a supplier
Documents and tests its own configuration: workflows, roles, signature meanings, required fields
Approves the validation and releases the system for regulated use
Assesses each vendor release and decides what to retest
The SaaS vendor:
Runs a documented development lifecycle with requirements, design review, code review, and testing
Keeps test evidence for each release, traceable to the functions it covers
Publishes release notes before changes reach production, with enough detail to assess impact
Controls its hosting environment and can describe how it is qualified
Supports supplier audits and answers supplier questionnaires
Agrees all of the above in a quality agreement
A vendor that already maintains code review as a change management control has much of the raw material. The work is packaging it so a quality reviewer can follow it.
A risk-based approach
The FDA's 2003 Part 11 scope guidance recommends basing validation decisions on a justified, documented risk assessment, considering the system's impact on product quality, safety, and record integrity. Industry practice builds on that.
GAMP 5. ISPE's GAMP 5 guide, now in its second edition, is a widely used industry framework for validating GxP systems. It is guidance from an industry body, not a regulation. It sorts software into categories that set the default depth of validation:
Category 1: infrastructure software, such as operating systems and databases
Category 3: non-configured products used as supplied
Category 4: configured products, where the customer sets up workflows and parameters
Category 5: custom applications
A configurable SaaS quality or laboratory system is often treated as category
Testing then concentrates on the customer's configuration and critical functions, and relies on the supplier's evidence for the standard product.
Computer software assurance. For medical device manufacturers, the FDA's guidance on computer software assurance for production and quality system software, first issued as a draft in 2022, pushes the same direction. It encourages testing effort in proportion to risk and accepts unscripted or exploratory testing for lower-risk functions. Check the current version and whether it applies to your product area.
Neither approach permits skipping validation. Both permit spending less effort on functions that cannot affect product quality or patient safety.
The validation deliverables
A typical validation package for a SaaS system, built by the customer, follows this sequence:
Validation plan. Scope, intended use, roles, approach, and acceptance criteria.
User requirements specification. What the system must do for this customer, written so each requirement can be tested.
Supplier assessment. The vendor qualification, based on questionnaires, certifications or reports, and an audit where risk warrants it.
Risk assessment. Which requirements are high, medium, or low risk, and what testing each receives.
Configuration specification. The settings, roles, workflows, and signature meanings in use.
Test protocols and results. Often labeled installation, operational, and performance qualification. For SaaS, installation qualification usually confirms the tenant, environment, and configuration rather than an install.
Traceability matrix. Each requirement mapped to its test and result.
Validation summary report. What was done, any deviations and their resolution, and the decision to release.
Test evidence should show the expected result, the actual result, who ran the test, and when. A screenshot with no expected result attached proves very little. The reasoning in screenshots versus system-generated evidence applies here with more force, because a validation record may be read years later.
Staying validated when the vendor ships monthly
This is the hard part, and no approach removes it entirely. A validated state is a snapshot. Each release changes the snapshot.
What makes it manageable is a predictable change process on both sides:
Advance notice. The vendor publishes release notes before deployment, classifies each change by impact, and flags anything that touches regulated functions such as audit trails, signatures, or record retention.
A preview environment. Customers can test a release on their own configuration before it reaches production.
Vendor regression evidence. A test summary for each release, so the customer can rely on it for unchanged functions.
Customer impact assessment. For each release, the customer records which changes affect its intended use and which tests it will rerun.
Periodic review. At set intervals, the customer confirms the system is still in a validated state, including configuration drift and open deviations.
Some vendors offer controlled release schedules for regulated customers, holding them on a version for a defined window. That buys time. It does not remove the need to assess each change.
What goes wrong
Validating everything to the same depth. Equal effort on every screen exhausts the budget before the critical functions get proper attention.
Re-executing the vendor's tests. If the vendor's evidence is credible and the supplier assessment says so, repeating standard product tests adds cost, not assurance. Put that effort into your configuration.
Treating validation as a project. The package is finished at go-live. The validated state has to be maintained for as long as the system holds regulated records.
No agreed change process. Without a quality agreement covering notification and evidence, each release becomes a negotiation.
Vendor marketing as evidence. "Validated" or "Part 11 ready" on a product page carries no weight in a validation file. The evidence behind it does.
How TrustLynce helps
TrustLynce collects evidence from your code and cloud systems on a schedule, timestamped and attributed, so the change control records a supplier assessment asks for already exist (evidence collection). Our auditor portal keeps a customer's supplier audit requests, your responses, and any findings in one place.