A LIMS validation that runs over budget almost never does so because of the LIMS. It happens because the team scoped the software and forgot that a laboratory system is mostly a set of boundaries: instruments feeding results in, an ERP or MES pulling dispositions out, and a dozen calculations in between that nobody wrote down.
LabWare, LabVantage, STARLIMS and Benchling are different enough that a single test strategy copied between them will waste effort in one place and miss risk in another. What they share is where the evidence actually has to be strong, and that is rarely the part of the system people demonstrate in a workshop.
This is the playbook we use on LIMS validation engagements, written in the order the work actually happens.
Start by separating the software from the instruments
This is the distinction that causes the most rework, and it is a vocabulary problem before it is a technical one. A LIMS is software, so it is classified and validated as software — GAMP 5 category 4 where it is configured, category 5 for the parts genuinely written for you. The analytical instruments connected to it are not software, and they are not qualified against GAMP at all. They sit under analytical instrument qualification, which USP General Chapter <1058> frames as design, installation, operational and performance qualification of the instrument itself.
Two frameworks, two evidence sets, two sets of owners. Teams that run them as one project usually end up with a package that proves an HPLC was installed correctly and says very little about whether the LIMS parsed its output properly. Keep them separate, then test the join between them deliberately.
Where the risk actually sits
Work outward from the reportable result, because that is the thing a regulator cares about and the thing a patient is eventually exposed to. Ask what could make it wrong, and the list is short and consistent across platforms.
- Specification limits and the pass or fail decision. If a limit is held in configuration, the risk is that it can be changed without the change being visible. This is the single highest-risk configuration item in most LIMS.
- Calculations. Dilution factors, moisture correction, potency on an as-is versus dried basis. Each is simple; the aggregate is where errors hide.
- Rounding and significant figures. A result that rounds to the limit rather than against it will pass a batch it should have failed. Rounding behaviour is configuration, and it is almost never tested at the boundary.
- Instrument result capture. Parsing, unit handling and what happens to a result that arrives malformed.
- Re-test, re-injection and invalidation. The paths that exist precisely because something went wrong, and therefore the paths most likely to be audited.
- Sample and aliquot identity. Label reprints, splits, pooled samples. Identity errors are rare and catastrophic.
Interfaces are the work, not an appendix
Most LIMS validation plans allocate a small section to interfaces. Most LIMS problems after go-live are interface problems. The imbalance is worth correcting at the planning stage rather than discovering in OQ.
Test the failure directions, not the happy path. A result file in the wrong units. A file that arrives twice. A file that arrives for a sample that has already been dispositioned. An instrument that returns a value below the limit of quantitation as text rather than a number. A worklist pushed to an instrument that has been taken out of service. Each of these has a correct behaviour, and the correct behaviour is usually to refuse the transaction and raise something a human sees.
Bidirectional interfaces deserve particular attention, because the LIMS is now writing to an instrument rather than reading from it. If a worklist can be sent to the wrong instrument, or sent twice, the result is a real laboratory incident and not just a data problem.
ALCOA+ inside a LIMS
LIMS platforms generally handle the attributable and contemporaneous parts of data integrity (ALCOA+) well, because they were built to. The parts that drift are the ones that depend on behaviour rather than architecture.
Audit trail review is the clearest example. The trail exists, it is complete, and nobody reads it. An audit trail that has never been reviewed is a control on paper. Define what gets reviewed, how often, by whom, and what a reviewer is actually looking for — unusual result changes, repeated invalidations against one analyst or one instrument, changes made outside working hours.
Then look at result modification. Can a result be changed after approval, and if so does the system force a reason, retain the original value, and make the change visible to the next reviewer rather than only to someone running a report? Those three behaviours are worth testing explicitly, because each one fails independently.
Platform differences that change the test strategy
Treat these as orientation rather than rules — every implementation is configured differently, and the only reliable classification comes from reading what was actually built.
Highly configurable platforms such as LabWare and LabVantage can be taken a long way with configuration, and are often taken further with custom code. The practical consequence is that the GAMP category is not a property of the product, it is a property of your implementation. If static data templates, calculations and workflows were written for you, parts of the system are category 5 whatever the vendor brochure says. Scope the classification after design, not before.
Cloud and SaaS platforms such as Benchling shift the question from what you tested to what you are entitled to rely on. The infrastructure qualification is the vendor's; the configuration, the intended use and the data are yours. That makes supplier qualification and cloud & SaaS validation load-bearing parts of the package rather than an annex to it.
Established on-premise platforms such as STARLIMS often carry years of accumulated configuration. The risk here is not the software, it is that the documentation describing it has drifted. A gap assessment before validation planning usually saves more effort than it costs.
A CSA-native test strategy
The FDA finalised its Computer Software Assurance guidance in September 2025 and reissued it in February 2026, and the part that matters for LIMS is the principle that testing depth should follow the risk a given function carries. That is a licence to stop scripting everything, and the laboratory is where it pays off most.
In practice: script the result pathway, the calculations, the specification limits, the approval controls and the interfaces, and script them at the boundaries rather than in the middle. Then use unscripted and exploratory testing for the large surface of low-risk functionality — searches, list views, standard reports, navigation — recording what was examined and what was found rather than pre-writing steps for a function that cannot affect a disposition.
Where the vendor has tested something properly and will show you the evidence, use it. Re-proving that a commercial database writes rows is effort spent on the wrong risk. The CSA services shift only works if you are prepared to write down the reasoning, and that reasoning is the deliverable auditors ask about.
The obligation that gets skipped
Periodic review is where laboratory systems quietly fall out of a validated state. Instruments are added. A calculation is corrected. A specification is revised after a method transfer. Each change is individually small and reasonable, and the validation documentation is told about none of them.
Set the review interval before go-live and schedule the first one. An undefined interval is a finding on its own, and a defined interval that is routinely missed is worse than a longer one that is actually kept. The questions worth asking are narrow: does the configuration specification match the live configuration today, how many changes has the system had since the last review, and how many of those have an impact assessment attached.
What good looks like at the end
A LIMS validation package is in reasonable shape when three things are true. The traceability between requirements, risk and test evidence is live rather than reconstructed at the end — a matrix maintained by hand reports whatever it was last told. The instrument qualification evidence and the software validation evidence are separate, complete, and joined by tests that cover the interface between them. And the periodic review is scheduled rather than intended.
If you are planning a LIMS implementation or inheriting one with documentation you do not trust, LIMS validation is the practice, and book a demo is the fastest way to get a view on where the real gaps are.
Where to go next
Explore GxP Copilot for AI-native validation, TraceDraft for source-traceable clinical documentation, or book a demo to see either on your own data.
