Evidence in eQMS: When Every Quality Action Needs to Be Verifiable

2026-10-04

Executive Summary

• A document says what should be done. Evidence shows what was done: who did it, when, on which version, under what authority, in what context, and in a way that can be verified. They are different things, and auditors ask for both.
• ISO 9001:2015 uses the idea of “retaining documented information as evidence” across many clauses, and asks that retained information be protected from unintended alteration.
• Weak evidence tends to fall into a few familiar forms: back-filled records, signatures without context, proof of intent rather than outcome, and records that can be edited without a trace.
• Each eQMS component produces its own kind of evidence. Knowing which kind is needed, and at what level of detail, avoids both extremes: too little to prove anything and too much to manage.
• An “evidence-by-design” approach creates evidence at the moment an action happens, as part of the workflow. It makes proving easier, but it doesn’t turn a poor action into a good one.

“We have a procedure” versus “Show me”

An auditor asks: “How does the company handle nonconformities?”

The quality manager answers, clearly, exactly as the released procedure says. The auditor nods, then says what every quality professional recognizes: “Show me a recent case.”

From that moment the question changes. It’s no longer “what does the procedure say” but “was it done as the procedure says, and how do you prove it?”

The distance between those two questions is the distance between a document and evidence. This article is about evidence: what it is, why auditors need it, what it looks like in each part of an eQMS, and how to design for it to exist from the start.

Document versus evidence: the distinction

The article How OKELAS Organizes eQMS introduced the general idea. Here we go into specifics.

A document (procedure, instruction, policy) describes what should be done. It needs updating when processes change, and its main problem is the current version.

Evidence (records, results, event logs) proves what happened. It needs to be kept intact and protected, and its main problem is integrity and traceability.

ISO 9001:2015 reflects this distinction in its wording: documented information the organization must maintain (typically documents) differs from information it must retain (typically evidence), as the standard’s Annex A explains. Clause 7.5.3 asks that information retained as evidence of conformity be protected from unintended alteration.

A record is only valuable as evidence if it can answer these questions:

• Who performed or confirmed it?
• When, at what time really?
• What, specifically?
• On which version of a document, under what authority?
• In what context (batch, equipment, supplier, related event)?
• Was it changed afterward, and if so by whom and when?

A signature on a form answers “who.” It usually answers none of the rest.

In pharmaceutical and medical device sectors, data integrity principles (commonly abbreviated ALCOA: attributable, legible, contemporaneous, original, accurate) describe this quite clearly. This is reference guidance from regulated sectors, not a requirement of ISO 9001, but the way of thinking is useful for any quality system.

Why audits require evidence, not just documents

Auditing a management system is, at its core, collecting audit evidence and comparing it with criteria. ISO 19011, the guidance on auditing management systems, describes audit evidence as records, statements of fact or other information relevant to the audit criteria and verifiable. Auditors sample, so they need things they can check.

Documents tell them how the system was designed. Evidence tells them how the system ran. Both are needed, but only evidence answers “is the system effective” (what the standard asks to be evaluated under 9.2).

And not only auditors. A customer asks about a batch, a regulator asks about an incident, leadership asks about a decision: all come down to the same question, where’s the evidence?

Across many manufacturing operations, weak evidence tends to fall into a few familiar forms. (A general observation, not measured figures.)

1. Back-filling. Records are completed after the event, sometimes a week later, “to make it complete.” Even with good intentions, it’s no longer contemporaneous evidence and is hard to defend when asked.

2. Signatures without context. A form has a signature and date but doesn’t show what the signer based it on or reviewed.

3. Proof of intent, not outcome. An attendance record proves a class took place, not that the person can do the job. A corrective action record marked “implemented” doesn’t prove the problem is gone.

4. Records that can be edited without a trace. A shared spreadsheet anyone can open and change.

5. Orphan evidence. A record exists, but can’t be linked to the related event, document or people, so it’s hard to use to rebuild the story.

6. Evidence in uncontrolled places. In personal inboxes, screenshots, or one person’s computer.

Evidence across eQMS modules

Each component of the quality system produces its own kind of evidence. The table summarizes the difference between what the document says and what the evidence needs to show. The specific level of detail should be proportionate to risk, since the standard asks for retained information at an appropriate level, not a maximum one.

The right-hand column is what auditors, customers and leadership actually want to see. Most earlier articles in this series covered each component from an operational angle; this table gathers them under a single question: what’s the evidence?

Illustrative example (a composite scenario, not a real customer case): a plant closes a corrective action record with an effectiveness check line: “no recurrence.” When the auditor asks for the basis, the team can’t show it: no monitoring period, no query of similar nonconformities afterward. The line is a claim, not evidence. In another version of the same process, the effectiveness check is scheduled from the start, and the result records the period monitored and the similar nonconformities checked, with a reference to the data itself. The difference isn’t the volume of paperwork but whether the answer can be verified.

OKELAS and evidence-by-design

The approach OKELAS follows is captured in the principle of evidence-by-design: evidence is created at the moment an action happens, as part of the workflow, rather than assembled afterward. This describes a design direction, as stated in the previous article, and it has four main ideas.

Create evidence concurrently with the action. When a person approves, confirms or handles something, the event is recorded at that moment, with who did it and when, rather than filled in later.

Tie evidence to context. Each event connects to the related document, version, batch, supplier and people, so evidence isn’t orphaned.

Protect integrity. Later changes don’t erase the trace of the original, in keeping with the spirit of the requirement to protect retained information.

Make it traceable. From one event you can follow the related chain, the Explain → Evidence → Trace principle OKELAS uses throughout.

This principle carries a broader meaning in the context of AI. An AI assistant answering questions about the quality system without being able to point to evidence gives an answer that can’t be trusted or checked. For organizations bound by ISO or GMP requirements, that is a concrete reason for structured evidence to come before AI, not after. This is analyzed separately in Evidence-Based AI and AI Reasoning vs. Organizational Truth.

The limits need stating plainly, because an article on evidence that isn’t honest about its limits contradicts itself.

Evidence-by-design doesn’t turn a poor action into a good one. A weak root cause analysis is still weak even when fully recorded and unalterable. The system can prove what happened, not that it was right.

It can’t prevent falsification at the source. If the person entering data records something untrue, the system just preserves it intact. A culture of honesty and safe reporting remains the foundation.

It must be proportionate. Not every action needs the same level of evidence. The standard asks for retained information appropriate to size and complexity. A system that records everything at maximum detail can create burden without value.

It needs processes that are clear enough. You can’t record a meaningful event if it isn’t clear what that event is, who does it, and under what authority.

As in the previous article, this article describes an approach and design direction, not the results of a specific customer or a fixed list of features.

A self-check: the evidence test

Pick a recent action at random in your quality system, for example a closed nonconformity, a newly released document, a supplier evaluation, then ask:

1. Can you show who did it and when it really happened, not the date the form was filled in?
2. Does the record show which document version the action took place on, and under what authority?
3. Does it connect to its context (batch, equipment, supplier, related event)?
4. Does it prove the outcome, or only that the action was carried out?
5. Has the record been edited since, and can you see the change history?
6. Was the record created at the time of the action, or back-filled?
7. Can you trace the related chain of events (before and after) in minutes?
8. Does the record live in a controlled place, not an inbox or personal computer?
9. Is the level of detail proportionate to the risk of the action, neither too light nor too heavy?
10. If an auditor asked about this action tomorrow, would you answer by opening the record or by reconstructing the story?

If three or more answers are “no” or “not sure,” your system may be storing more documents than evidence.

A note on ISO 9001 editions

References in this article are to ISO 9001:2015. According to certification bodies, a revised ISO 9001:2026 was scheduled for publication in September 2026, with a transition period expected to run about three years and 2015 certificates remaining valid during it. Clause structure and wording may change; check against the edition your organization is certified to.

Is your quality system storing documents, or producing evidence that can be verified?

→ Contact OKELAS to discuss how to organize evidence in an eQMS suited to your manufacturing business’s maturity and needs.

Further reading:

• How OKELAS Organizes eQMS: Document, Evidence, Audit Trail (previous)
• From eQMS to Knowledge OS: What Comes After Digital Quality Management (next)
• Evidence-Based AI: When Answers Need to Be Verifiable (related)
• AI Reasoning vs. Organizational Truth (related)
• Audit Preparation: Why It Takes Weeks (related)
• eQMS for Manufacturing SMEs: A Practical Guide (pillar)

Sources:

• ISO 9001:2015, clauses 7.5.3 (control of documented information), 9.2, 9.3, 10.2 and Annex A (use of “maintain” and “retain”): iso.org/standard/62085.html
• ISO 19011 (guidelines for auditing management systems), reference guidance, not a requirement of ISO 9001: iso.org/standard/70017.html
• LRQA, ISO 9001 revision update: Publication date confirmed (certification body source; verify with ISO): lrqa.com

ISO 9001:2015 clauses are summarized in practical language and do not replace the text of the standard. The example is a composite illustrative scenario based on common patterns in manufacturing, not a specific customer case. The weak-evidence forms described are general observations, not measured figures. The ALCOA principles are reference guidance from regulated sectors, not a requirement of ISO 9001. Content about OKELAS describes an approach and design direction, not a commitment on outcomes or a feature list.