For decades, validating lab software meant thick binders: requirements, specifications, protocols, hundreds of screenshots and a traceability matrix tying it all together. That approach produced plenty of documentation, but not always proportionate assurance. High-risk calculations and trivial screen layouts often received the same scripted treatment, and the cost of revalidation discouraged labs from applying upgrades and security fixes. Over the past several years, regulators and industry bodies have pushed in a different direction: focus effort where failure would actually harm product quality, patient safety or data integrity, use the evidence that already exists, and think critically rather than test mechanically. This article explains traditional computer system validation (CSV), the risk-based thinking in GAMP 5 Second Edition, FDA’s Computer Software Assurance (CSA) approach, and how all of it applies to a configurable SaaS LIMS.
Key takeaways
- The requirement to validate has not changed; what has changed is the expectation that effort should be proportional to risk.
- GAMP 5 Second Edition (2022) puts critical thinking at the center and encourages leveraging supplier documentation and testing.
- FDA’s CSA guidance was issued in draft in September 2022 and finalized in September 2025. It is addressed to medical device manufacturers, but its principles are widely discussed across GxP industries.
- Unscripted testing is acceptable for lower-risk functions, while high-risk functions still warrant rigorous, documented, scripted testing.
- For SaaS, validation is a shared responsibility. The vendor assures the platform; the lab assures its intended use and configuration.
- A good vendor validation package can remove a large share of duplicated testing, but it never replaces your own risk assessment.
What traditional CSV looks like
Classic CSV follows a lifecycle often drawn as a V-model. On the left side, the team writes a user requirements specification (URS), a functional specification and a design or configuration specification. On the right side, each is verified through qualification testing:
- Installation qualification (IQ): confirms the system and its components are installed and configured as specified.
- Operational qualification (OQ): confirms the system functions as specified across its intended operating ranges.
- Performance qualification (PQ): confirms the system performs as required for its intended use, with real processes, users and data.
A validation plan sets the approach, a traceability matrix links requirements to tests, and a validation report concludes whether the system is fit for use.
Why it became burdensome
Nothing in that structure is wrong. The problems came from how it was applied:
- Every function was tested with the same rigor, regardless of risk.
- Vendors’ standard functions were retested by each customer, often repeatedly.
- Screenshots and signatures on every step became the goal, rather than evidence of assurance.
- Defects found in test scripts themselves consumed time that could have gone into finding real system defects.
- Revalidation costs delayed upgrades, leaving labs on older, less secure versions.
The underlying requirement has not changed
Risk-based assurance is a way of meeting existing requirements, not a way around them. In the US, 21 CFR 11.10(a) requires validation of systems that manage electronic records, and 21 CFR 211.68 addresses automated equipment used in drug manufacturing. For medical device manufacturers, the Quality Management System Regulation, which incorporates ISO 13485:2016 by reference and took effect in February 2026, carries the expectation that software used in production and the quality system is validated. In Europe, EU GMP Annex 11 requires validation and calls for risk management throughout the lifecycle. For accredited labs, clause 7.11 of ISO/IEC 17025:2017 expects laboratory information management systems to be validated for functionality before use.
The idea of risk-based validation is not new either. FDA’s 2003 guidance on the scope and application of Part 11 encouraged a risk-based approach, ICH Q9 established quality risk management principles (revised as Q9(R1) in 2023), and the first edition of GAMP 5 in 2008 was built around risk. What is new is how explicitly regulators and industry guidance now endorse lighter-weight assurance for lower-risk functions. Our 21 CFR Part 11 checklist covers the specific controls a system must support.
GAMP 5 Second Edition and critical thinking
ISPE published GAMP 5 Second Edition in 2022. It retains the core framework of the first edition—a lifecycle approach, scaled effort and software categories—while updating it for how systems are now built and delivered. Key themes include:
- Critical thinking. Validation decisions should be driven by understanding of the process, the data and the risks, not by templates applied by default.
- Focus on patient safety, product quality and data integrity. Effort should scale with the potential impact of a failure on these outcomes.
- Supplier involvement. Regulated companies are encouraged to assess suppliers and use their documentation, testing and expertise where it is adequate, rather than duplicating it.
- Software categories as a guide. Infrastructure software, non-configured products, configured products and custom applications carry different levels of risk and warrant different approaches, but categories inform judgment rather than replace it.
- Modern delivery. Updated guidance on agile development, cloud and service-based models, automated testing tools and emerging areas such as AI and machine learning.
GAMP 5 Second Edition is broadly consistent with the direction FDA has taken with CSA, which is one reason many pharmaceutical and biotech organizations treat the two together.
FDA’s Computer Software Assurance approach
Status and scope
FDA issued the draft guidance “Computer Software Assurance for Production and Quality System Software” in September 2022 and finalized it in September 2025. It is addressed to medical device manufacturers and covers software used as part of production or the quality system, not software that is itself a medical device or part of one. Pharmaceutical, biologics and other GxP labs are not formally within its scope, but its principles are frequently cited as an expression of current regulatory thinking. Confirm with your quality and regulatory functions how it applies in your context, and read the final text directly when updating procedures, since wording and examples may differ from the draft.
The four-step framework
The guidance describes a risk-based approach that can be summarized in four steps:
- Identify the intended use. Determine whether the software, or a specific feature, is used directly in production or the quality system, or supports those processes indirectly.
- Determine the risk-based approach. Consider whether failure of the feature to perform as intended could create a high process risk, such as compromising product quality or safety, or whether it would not.
- Determine appropriate assurance activities. Match the activity to the risk. The guidance describes scripted testing, including more rigorous and more limited forms, and unscripted testing such as ad hoc testing, error guessing and exploratory testing. It also recognizes the value of supplier activities, built-in controls and ongoing monitoring.
- Establish an appropriate record. Capture enough to show what was done and why: the intended use, the risk determination, what testing was performed, by whom and when, any issues found and how they were resolved, and a conclusion on acceptability. Records the system already produces, such as logs and audit trails, can serve as evidence.
What CSA is not
CSA does not mean less assurance for high-risk functions, undocumented testing or ignoring Part 11. It means spending effort where it reduces risk, documenting the rationale for those decisions, and not producing evidence for its own sake.
CSV and CSA compared
| Aspect | Traditional CSV in practice | Risk-based assurance (GAMP 5 Second Edition and CSA) |
|---|---|---|
| Primary focus | Producing complete documentation | Confidence that the system is fit for intended use |
| Testing approach | Scripted testing for nearly everything | Scripted for high risk; unscripted or limited scripted for lower risk |
| Supplier role | Often retested by the customer | Supplier evidence assessed and leveraged where adequate |
| Evidence | Screenshots and step-by-step signatures | Fit-for-purpose records, including system logs and audit trails |
| Effort distribution | Roughly uniform | Concentrated on functions with the greatest impact |
| Upgrades | Large revalidation projects | Impact assessment and targeted regression testing |
Applying risk-based assurance to a configurable SaaS LIMS
Shared responsibility
In a SaaS model, the vendor builds, tests, hosts and releases the platform, while the lab defines how it is configured and used. Validation responsibilities split along the same line.
| Vendor responsibilities | Lab responsibilities |
|---|---|
| Quality management system and software development lifecycle | Intended use, URS and risk assessment |
| Testing of standard platform functions | Supplier assessment of the vendor |
| Infrastructure, hosting, security and backups | Verification of lab-specific configuration |
| Release testing, release notes and impact information | Release impact assessment and targeted regression |
| Change notification and supplier audit support | Procedures, training, periodic review and change control |
Classify functions by risk
Risk depends on your processes, so the table below is an example rather than a rule.
| LIMS function | Example risk level | Typical assurance approach |
|---|---|---|
| Specification evaluation and OOS flagging | High | Scripted testing of configured specifications, including boundary values |
| Result calculations | High | Scripted testing with boundary, rounding and significant-figure cases |
| Electronic signatures, audit trail and access control | High | Scripted testing of configured roles and workflows; leverage vendor testing of the underlying engine |
| CoA generation and release | High | Scripted testing of each template or a justified representative set |
| Instrument data capture | Medium to high | Scripted testing per interface type |
| Sample login and label printing | Medium | Limited scripted or unscripted testing |
| Dashboards and search | Low | Unscripted or exploratory testing |
| Personal display preferences | Low | Rely on vendor testing |
Managing frequent releases
SaaS platforms update more often than on-premises systems. A sustainable process includes vendor release notes that identify changed functions and their risk, a documented impact assessment by the lab, targeted regression testing of high-risk configured workflows in a validation environment before changes reach production, and automated test suites where possible. Agree with the vendor in advance how emergency security patches will be communicated and assessed.
Configuration change control
Configuration is where most lab-specific risk lives. Treat it as a controlled item: version it, review changes, promote it between environments through a defined process, and be able to compare one configuration baseline with another.
What a vendor validation package should contain
When you assess a LIMS vendor, ask to see the following:
- Quality system evidence: QMS overview, relevant certifications and summaries of the software development lifecycle procedures
- Specifications: functional requirements or specifications for standard functionality
- Risk assessment of standard functions, including those relevant to Part 11 and Annex 11
- Test evidence: test strategy, executed results (including automated tests) and a traceability matrix
- Release documentation: release notes, impact assessments and a known issues list
- Regulatory mapping: how the system supports Part 11 and Annex 11 controls
- Infrastructure and security: hosting and cloud provider qualification, security attestations such as SOC 2 Type II or ISO/IEC 27001, and penetration test summaries
- Continuity: backup, restore and disaster recovery testing results
- Templates: validation plan, configuration verification and protocol templates you can adapt
- Commitments: supplier audit access, a quality agreement and change notification terms
Vendor documentation reduces duplicated effort, but it does not transfer responsibility. You still own the decision that the system is fit for your intended use. Our articles on data integrity and ALCOA+ and ISO/IEC 17025 LIMS requirements cover related expectations.
Making the shift
- Update validation SOPs and templates to allow risk-based selection of assurance activities and unscripted testing.
- Define risk criteria that link LIMS functions to impact on product quality, patient safety and data integrity.
- Train validation and QA staff in critical thinking and in documenting unscripted testing well.
- Strengthen supplier assessment, since leveraging vendor evidence depends on trusting it.
- Pilot the approach on an upgrade or a lower-risk system before applying it broadly.
- Prepare to explain your rationale to auditors and inspectors, with the risk assessment as the anchor.
If you are selecting a new system, our LIMS buyer’s guide explains how to weigh validation support during evaluation.
How HDLIMS approaches this
We believe SaaS vendors should make risk-based validation easier for their customers, and we welcome assessment against the package described above. Our compliance and security pages describe how the HDLIMS platform supports regulated labs, and our services team can help plan a risk-based validation for your configuration.