ISO/IEC 17025 clause 7.11.2: validate laboratory systems and changes
Clause 7.11.2 requires the laboratory to validate the functionality of information-management systems before introduction, including correct functioning of interfaces. Changes must be authorised, documented and validated before implementation. The focus is whether the system reliably supports the laboratory's intended functions, not whether the software merely starts successfully.
What clause 7.11.2 requires in practice
Clause 7.11.2 deals with the laboratory information management systems, whether computerised or not, used to collect, process, record, report, store or retrieve data. Before such a system comes into use, the laboratory validates it for functionality, which includes checking that the interfaces inside the system work properly.
Afterwards, any change, including configuration changes and modifications to commercial software, is authorised, documented and validated before it is put into service. The aim is that no alteration reaches live work without a recorded decision and evidence that the system still does its job.
Two notes sit beside the clause. The first says the term covers non-computerised arrangements too, although some requirements apply more naturally to computer systems. The second accepts that widely used, ready-made commercial software, run only within the range it was designed for, may be treated as validated to an adequate degree. The laboratory therefore concentrates its own effort on what it has added: formulas, mappings, interfaces and settings.
Define what the system must do
Identify relevant collection, processing, recording, reporting, storage and retrieval functions. Map interfaces with instruments, calculation tools and other systems. Specify the expected result for representative normal and exceptional situations so validation has a clear technical purpose.
The standard does not prescribe one software-validation template or exhaustive test count. Choose evidence proportionate to the functions and risks. Include factors such as data identity, units, calculation logic and transfer behaviour where they can affect laboratory results.
Why validating laboratory systems and changes matters
A single wrong unit conversion or a broken instrument interface can affect every report produced after an update. The cost is not only the corrected reports; it is the customer conversations, the recalls and the doubt cast on earlier work.
Validation before use and control of change give the laboratory a defensible answer to the question every customer eventually asks: how do you know your software gives the right answer? They also reduce the temptation to fix a configuration directly on the live system under deadline pressure. Assessors frequently test this area because software changes are an easy place for informal practices to creep in.
How to implement clause 7.11.2
Aim for evidence that fits the risk, not a heavyweight template. A small laboratory with one spreadsheet needs less than a multi-site system, but both need a clear record. Validation here means showing fitness for the laboratory's own use. Keep the records brief but specific, so that a reviewer can see what was tested, on which version, by whom and with what outcome.
- State what the system must do: the functions, the data it handles and the interfaces with instruments or other tools.
- Define expected results for normal and awkward cases, including units, rounding and transfer behaviour.
- Run those cases before first use and keep the outcomes together with the version tested.
- Separate what a supplier can evidence from what the laboratory has configured, and test the second part yourself.
- Set a change route: who proposes, who reviews technically, who approves, and what testing happens before release.
- Plan how to return to the earlier version if a change misbehaves, and tell users when a change goes live.
Use commercial-software evidence carefully
The standard notes that off-the-shelf software in general use within its designed application range can be considered sufficiently validated. This qualification avoids unnecessarily recreating all vendor testing. It does not establish that a laboratory's custom configuration, spreadsheet formula, interface or modified reporting logic is correct.
Review supplier evidence for what it actually covers and identify the laboratory-specific work still needed. A vendor demonstration using sample data may be helpful without proving the correctness of your instrument mapping, calculation and report workflow.
Control changes before release
Changes include configuration and modifications to commercial software. Establish who proposes, technically reviews and authorises the change, what validation is needed and when it may enter use. Document the evidence before implementation, not as a retrospective explanation after an incorrect report appears.
Consider related functions and historical records. A change to a unit field can affect calculations, displays and exports even when the original request seems cosmetic. A practical release plan may include a recovery route and user briefing; these are useful controls, not separately prescribed universal forms under this subclause.
Two illustrative validation exercises
A calibration laboratory modifies a spreadsheet to use a new correction factor. It verifies the relevant formulas, units and expected outputs using suitable test cases and authorises the changed version before use. The spreadsheet application's general reputation does not validate the laboratory's formula.
A testing laboratory introduces a LIMS interface that imports instrument results. It checks item identity, decimal handling, units, exceptional data and report output. A successful import message alone would not reveal that two sample identifiers were mapped incorrectly.
Evidence and common mistakes
Keep the intended-function description, relevant validation evidence, identified issues, resolution and release authorisation in a traceable form. Clause 7.11.2 explicitly requires changes to be documented; technical records and broader system controls support the evidence for reliable operation.
Avoid relying solely on installation acceptance, treating a configuration change as exempt, validating only happy-path examples, or allowing a support provider to release a technically significant update without laboratory involvement. Conversely, avoid asserting that every unchanged generic software function needs a complete independent redevelopment study.
Frequently asked questions
Does every standard office application need full custom validation?
The standard recognises general-use commercial software within its designed application range as potentially sufficiently validated. Laboratory-specific configurations, calculations and interfaces still need appropriate evaluation.
Does a software update count as a change?
Evaluate what changes in the laboratory system. Relevant configuration or functionality changes must be authorised, documented and validated before implementation, with the extent based on the affected functions.
Can the vendor perform the testing for us?
Vendor evidence can contribute, but the laboratory remains responsible for establishing that its system and interfaces function appropriately for the intended laboratory application.
Turn this requirement into reliable laboratory practice
Ask Sterling to help organise responsibilities and evidence for a planned laboratory software change. A free consultation can identify the implementation controls and staff learning needed, while competent technical personnel approve the system functions and results.
Build the team's understanding through Method Validation and Verification (ISO/IEC 17025:2017). Discuss the relevant scope, employee learning and agreed access to Effivity ISO & GRC automation software with Sterling; laboratory technical decisions remain with competent, authorised personnel.
ISO/IEC 17025 requirements hub · Information-management controls · Planned changes · Record history