In an accredited laboratory, doing things right is not enough. You have to be able to prove they were done right, with evidence that is organized, dated and attributable.
With instruments this was solved decades ago: they are calibrated, it is recorded, there is a certificate. With software, almost never. And software influences the result just as the instrument does: it calculates, it rounds, it decides whether something is within tolerance and it produces the report someone signs.
What the standard asks, in plain terms
ISO/IEC 17025 requires that software used to acquire, process, record, report, store or retrieve data be validated as fit for use.
In practice that means being able to answer four questions for every screen of the system:
- What was it supposed to do? — the use case.
- How was it checked? — the test case, the specific condition being verified.
- Who verified it and when? — the validation, with a name and a date.
- What happened when it failed? — the next round, the correction and the re-check.
If those four can be answered for any screen, the audit stops being an event.
Why a spreadsheet falls short
Almost everyone starts with one. And it works for a while, until three problems show up:
- There is no history. If a case was rejected, corrected and revalidated, the spreadsheet usually keeps only the last state. The intermediate round is gone — and that is exactly the one showing the control worked.
- There is no reliable attribution. A cell with initials does not prove who wrote it or when. Anyone could have changed it afterwards.
- The link is lost. The sheet says the screen was validated, but not against which version or under which exact condition.
None of that matters while nobody asks. It matters the day they do.
What does work
Four design decisions that change the outcome:
A hierarchy, not a flat list
System → screen → use case → test case → validation. Each level hangs off the previous one. That way you can answer both "is the system validated?" and "why was this particular condition validated?".
States that cannot be skipped
A case cannot go from proposed to validated without walking the path. A transition machine prevents it by design, rather than trusting nobody makes a mistake.
Validations by round
Every attempt stays on record: what was checked, by whom, when and with what verdict. The failed round is not deleted — it is evidence the control caught something.
Reconstructed data, labelled as reconstructed
This is the one most often done wrong.
When history is imported from an old spreadsheet, those records are not primary evidence: they are a reconstruction. If loaded without distinguishing them, the whole record is contaminated, because the auditor cannot tell which is original and which was reassembled later.
Labelling them with their source is what lets you use them without costing the rest its credibility. It is the difference between a data point and a problem.
And a rule that seems obvious
The system doing the validating cannot write to the system being validated. If data has to be pulled from production, the connection is read-only, and only the import processes use it.
It sounds evident until somebody, fixing something quickly, leaves the door open the other way.
Where this comes from
We write it because we built it. Sitragol QA is a custom development to record exactly this: the validation traceability of every feature, with history rescued from the spreadsheet and labelled as reconstructed, separate developer and validator roles, an audit log on every change, and a status report for compliance with the standard and the internal procedure.
We have worked with laboratories for years — calibration, clinical analysis, occupational health — and the pattern repeats: the operation is well run and the evidence for the software side is what is missing.
If you have to demonstrate the validation of your systems, let's talk.