A laboratory can run excellent calibrations or tests and still struggle come assessment time with UKAS in the UK, or A2LA, ANAB or NVLAP in the US, not because the technical work is wrong, but because it cannot show the history behind a result. An assessor picks a report, asks why a figure was changed, or wants to know which version of a method was in use on a particular date, and the answer needs to come from the records themselves, not from someone's memory.
That history is what an audit trail provides. It is not a separate document to produce for the assessment day, but rather a reflection of how a laboratory's methods, records, and data are managed day-to-day, and ISO/IEC 17025:2017 builds this expectation into several of its clauses.
Understanding where those expectations sit and what they actually require makes the difference between an audit trail that exists on paper and one that holds up when tested.
An audit trail is the chain of evidence that shows who created or changed a document or record, when, and (where relevant) why, in a way that allows the original version to be reconstructed alongside the change.
The concept is widely used in data integrity guidance from bodies such as the UK's Medicines and Healthcare products Regulatory Agency (MHRA), which describes an audit trail as a record that permits reconstruction of the course of events and identifies who made a change, when, and for what reason. That guidance was written for pharmaceutical and healthcare environments, not testing and calibration laboratories, so it is a useful reference point rather than an ISO/IEC 17025 requirement in its own right.
ISO/IEC 17025:2017 does not use the term "audit trail" itself. What it does is set out, across several clauses, exactly the properties an audit trail has: traceability to a previous version, identification of who was responsible, and protection of records from being altered without that alteration being visible. The result is the same expectation under a different name.
Clause 7.5 requires records that allow the test or calibration to be repeated under conditions as close as possible to the original. Where a technical record is amended, clause 7.5.2 explicitly requires that it can be tracked to previous versions or original observations, with both the original and amended data retained, along with the date of the alteration, an indication of what was altered, and the person responsible. A spreadsheet cell that is simply overwritten does not meet this: the previous value, and the fact that it ever existed, are gone.
Clause 7.11 applies to laboratory information management systems (LIMS), spreadsheets used for calculations, and other software the laboratory relies on. It calls for the laboratory to validate that its systems work as intended before relying on them, to protect them from unauthorised access, tampering and loss, to maintain them in a way that ensures the integrity of the data, and to authorise, document and validate any change to system configuration before it is implemented.
For an electronic system, this clause is where the case for a genuine, system-generated audit trail is strongest: manual workarounds are hard to evidence consistently, while a validated system can be shown to log changes reliably.
Clause 8.3 governs methods, procedures and templates rather than results, but the same logic applies. A document needs a unique identifier, a visible revision status, and controls that prevent the unintended use of obsolete versions. Recording when each version was withdrawn goes beyond the clause's wording, but it is what allows work carried out 18 months ago, for example, to be checked against the method used at the time.
Clause 8.4 requires controls for the identification, storage, protection, back-up, retrieval and retention of records, with records retained for a period consistent with the laboratory's contractual obligations. An audit trail is, in effect, how a laboratory demonstrates that protection: not just that a record has not been tampered with, but that if it was legitimately corrected, the correction itself is on the record.
A usable audit trail answers four questions for any change: what was changed, who changed it, when, and, for a correction, why.
In practice, that means a laboratory should be able to show the original value or version alongside the new one, not just the latest state. For a technical record, this typically includes the initial observation, the corrected observation, the date of correction, and the identity of the person who made it. For a document, it covers the previous revision, the current revision, the approval that authorised the change, and the date the old version was withdrawn from use.
For example, a technician transcribes a test result and later notices the decimal point is in the wrong place. Corrected the right way, the record shows the original figure, the corrected figure, the date of the correction, and the technician's identity, so a reviewer can see exactly what happened. Corrected the wrong way, the technician deletes the old figure and types in the new one, leaving no trace that a correction was ever made. Both records now show the right number. Only one of them can survive an assessor asking how the laboratory knows that number is right.
Paper systems can hold an audit trail, but only if someone actively maintains it. Electronic systems can generate one automatically, which is what makes them more reliable at scale.
On paper, an audit trail depends on discipline: striking through an entry rather than erasing it, initialling and dating every correction, and keeping copies of superseded documents in a controlled, findable place. This works, but it depends entirely on every person following the convention every time, and it is difficult to prove that a gap did not exist.
An electronic system, once validated under clause 7.11, can log the change itself: the previous value, the new value, the user, and the timestamp, without relying on anyone remembering to record it. This, however, does not remove the laboratory's responsibility. The system still needs to be configured so the trail cannot be switched off by an ordinary user, and access controls still need to match people to the permissions their roles actually require. What changes is where the burden sits: proving the trail exists, rather than hoping it was kept.
The most common gap is not a missing control but an inconsistent one, such as an audit trail that exists for some records but not others.
Typical patterns include a corrected result overwritten rather than tracked, a superseded method still accessible because a local copy was never removed, an intermediate check that was decided on but never actually logged, and a spreadsheet used for calculations that was never validated or locked down under clause 7.11. None of these points to poor technical work. They point to a laboratory that can do the work correctly but cannot yet, on request, show that it always has.
This is also where a document management system changes the economics of compliance. Rather than relying on individual discipline to maintain a paper trail, the system automatically retains every draft, approval, and superseded version and applies the same access controls and revision history across all methods and records, without anyone having to police it by hand.
Our guide to ISO/IEC 17025 document control covers the broader set of controls it connects to, from approval workflows to the withdrawal of obsolete documents.
An audit trail is not a document that a laboratory produces for assessment. It is what is left behind once records, methods, and data have been managed correctly over time, and ISO/IEC 17025:2017 asks for it through clauses 7.5, 7.11, 8.3 and 8.4, even though it never uses the phrase. The laboratories that find this straightforward are usually not the most sophisticated technically. They are the ones where the trail is generated as a by-product of how the work is done, rather than reconstructed under pressure once an assessor asks for it.
Getting there does not require a large, complex quality platform. It requires methods, records, and data held in one place, with version history and change records maintained by the system rather than by a person, so that governance holds up without adding bureaucracy to the day-to-day work.
If your laboratory is preparing for ISO/IEC 17025 accreditation, or relying on shared drives and spreadsheets to track changes, the Cognidox team can show you what a working audit trail looks like in practice, with version history, controlled amendments, and access records maintained automatically rather than by hand.
Book a demonstration with the Cognidox team and bring the questions your last assessment raised about records and traceability.
No. The standard requires that documents and records be controlled and that amendments be traceable, not that a laboratory use particular software. A disciplined paper-based system can meet clauses 7.5 and 8.4, but in practice, an electronic system makes the trail far easier to maintain consistently, because it automatically generates the record of change rather than relying on everyone following the same convention every time.
Not quite, though they do overlap. ALCOA+ (attributable, legible, contemporaneous, original, accurate, and complete, consistent, enduring, available) is a data integrity concept most commonly associated with FDA and MHRA guidance in pharmaceutical and healthcare settings. ISO/IEC 17025 does not use ALCOA+ as a term, but its own requirements, particularly in clauses 7.5 and 7.11, ask for many of the same properties: traceable changes, identified individuals, and protected, retrievable data.
It is typically raised as a finding against the relevant clause, most often 7.5 for a technical record or 8.4 for records generally, rather than treated as evidence of incompetent work. The laboratory is usually asked to demonstrate corrective action, such as reconstructing the missing history where possible and implementing a control to prevent the gap from recurring, before the finding is closed out.