“Show Me How You Verified It” — The Question That Breaks Most Quality Systems

There is a question auditors ask that sounds harmless and isn't.

Not do you have a procedure — everyone has a procedure. Not is it approved — of course it's approved, it has a revision number and a signature. The question that actually does damage is quieter than that:

"Show me how you verify that the required quality activities were actually completed, reviewed and closed out."

I've watched capable teams walk into that question with total confidence and come out the other side with a nonconformity. Not because they weren't doing the work. Because they were doing the work in a way that only made sense to the people doing it.

If you want to know whether your own system would survive it, read on. But I'd suggest you already know the answer, and that faint discomfort you're feeling is the article working.

The most common finding isn't what you'd guess

Ask a project manager to predict their worst audit finding and they'll usually reach for something absent. A missing procedure. An expired calibration. An uncontrolled document.

In my experience the most common finding in project-based organisations is none of those. It's this: the organisation cannot consistently demonstrate that its quality activities were controlled and verified.

Note what that says. Not "quality activities weren't happening." They were. Inspections were carried out. Submissions were reviewed. Defects were spotted and raised. Meetings were held, photographs were taken, comments went out, and people who knew what they were doing did it competently.

The finding is narrower and more uncomfortable: nobody outside the project can prove any of that from the records.

Clause 8.5.1 of ISO 9001:2015 requires control of production and service provision — including the implementation of monitoring and measurement activities at appropriate stages to verify that criteria have been met. The obligation is not to do verification. It's to control it. And control that can't be evidenced isn't control. It's habit.

What the auditor is actually doing

Understand the mechanics and the finding stops being mysterious.

A good auditor doesn't attack the procedure. The procedure is usually fine — it was written carefully, probably by someone senior, and it says sensible things. Attacking it is a waste of everyone's morning.

Instead they pick a project, pick a requirement, and follow the thread. Not asking does this exist, but can I get from one end to the other without you helping me:

1. What was the applicable quality requirement?
2. What inspection or review was performed against it?
3. What was the result?
4. Against which acceptance criteria was that result judged?
5. Who accepted it, and were they authorised to?
6. If something was found, what action was required, by whom, by when?
7. Was closure verified — and by someone other than the person who did the work?
8. Was any of this visible to management while it was still open?

Eight links. The auditor is not testing whether your people are good. They're testing whether the chain holds without the people.

And here is the part worth sitting with: an auditor is, by definition, a stranger with no context. They weren't in the meeting. They don't know that Miguel always checks the rebar before the pour, or that the reason there's no record of the third inspection is that it was folded into the second one after the sequence changed. They have the documents and nothing else.

So the audit isn't really a test of your quality. It's a test of whether your quality survives contact with someone who doesn't already know the answer.

Most systems fail that test, and their owners are genuinely shocked.

An illustration

A surveillance audit. The team is relaxed, and reasonably so. Quality is an area they consider themselves strong in. There are quality plans. There are inspection records. There are project reports referencing quality issues, and there are photographs — a great many photographs.

The auditor selects two projects and starts pulling.

He finds a project report noting that a submission was reviewed and comments issued. Good. He asks to see the comments. They're in an email. Fine — he asks what happened to them. Someone explains that the contractor responded and it was resolved. He asks to see the resolution. There's a later email, from a different thread, in which the issue is referred to in passing as closed.

He asks: closed by whom, against what criteria, and verified by whom?

The room goes quiet — not because the answer is bad, but because everyone in it knows the answer and none of them can point to where it's written. The site engineer explains what happened. He's completely credible. He remembers the detail. He's also, at that moment, functioning as the missing link in a documented control chain, which is precisely the problem.

The auditor tries a second project. Same shape: real work, real competence, real outcomes — and a trail that only holds together if you already know the story.

Minor nonconformity, Clause 8.5.1. Not for absent quality. For quality that couldn't be demonstrated as controlled.

Why the team never saw it coming

This is the part I find most interesting, and it's the reason this finding recurs across organisations that are, by any reasonable measure, good at what they do.

The team weren't blind. They were compensating.

Experienced people carry the system in their heads. They know which inspections matter and which are ceremonial. They know that the ITP says one thing but the sequence changed in week six. They know the outstanding item from March was closed because they were standing there when it was closed. They connect the pieces automatically, and because the connection happens in their heads, they don't notice that it never happened on paper.

From inside, the process appears to work. It does work. Right up until you remove the people.

Which leads to something worth stating plainly:

Competent, experienced staff are the single most effective concealer of QMS defects.

They are also, therefore, the reason the defect is dangerous. A weak system staffed by weak people fails early, visibly, and cheaply. A weak system staffed by strong people fails late — when someone leaves, when a project scales, when two key people are on another job at once, or when something finally goes wrong and you reach for a record that was never created.

Everyone walked past the gap for years because the gap was full of people.

The apparent cause, and the real one

Pull the NC report on a finding like this and the stated cause will usually be some version of: records were not consistently completed or filed.

That's true. It's also nearly useless, because it points the corrective action at the wrong thing — a reminder, a toolbox talk, a stern email about filing discipline. Six months later the same finding comes back and everyone is baffled.

The real root cause is structural, and it's this:

The process was designed around performing technical activities, not around demonstrating the control cycle.

Read the procedure of any organisation that gets this finding and you'll see it. The document is rich on what to do — inspect this, review that, check the other. It is thin to the point of silence on how the completion of that work becomes visible, assignable, traceable and closable by someone who wasn't there.

Underneath sits an unstated assumption, and it's the one that really did the damage: that competent people will naturally maintain control. They won't. Not because they're careless — because maintaining a demonstrable trail is a different task from doing the work well, and nobody ever asked them to do it, resourced it, or made it unavoidable.

So compliance ends up resting on individual working practice rather than organisational process. Which is another way of saying it isn't a system at all. It's a set of habits that happen to be good ones.

What actually fixes it

Not more forms. Forms are the thing everyone reaches for and they don't touch the root cause.

What works is making the control cycle unavoidable rather than optional:

Define the minimum. Every project gets a defined minimum quality content — not left to the PM's judgement about what this particular job needs. Judgement is where variation enters.

Make the plan project-specific. A generic quality plan cloned across projects is a document nobody reads, because it isn't about their project. Project-specific quality plans and ITPs are read because they're relevant.

Structure the tracking. Inspections, nonconformances and corrective actions in a tracked register with an owner and a due date — not in email, not in meeting minutes, not in someone's memory. If it lives in an inbox, it isn't tracked.

Assign closure verification to a person. Explicitly. And ideally not to the person who did the work. "Closed" with no verifier is a claim, not a control.

Route quality into reporting and management review. If open quality items never surface above project level, management has no visibility, and Clause 9.3 has a hole in it too. Open items should be uncomfortable to leave open.

Control the evidence. Document control isn't bureaucratic theatre. It's the difference between having a record and being able to find it eighteen months later when it matters.

Audit implementation, not existence. This is the one most internal audit programmes get wrong. Checking that a procedure and a template exist is not auditing. It's inventory. Audit the trail — pick a project, pick a requirement, walk the eight links, and see where it breaks. Do to yourselves what the external auditor will do to you.

The thread that connects everything

If you've read what I've written about FIDIC notices and contemporary records, you may notice this is the same argument wearing different clothes.

A delay claim dies because the records that would have proved it were never created — not because the entitlement wasn't real, but because nobody knew, on an ordinary Tuesday in March, that Tuesday would matter.

A quality system fails an audit because the trail that would have demonstrated control was never created — not because the control wasn't happening, but because nobody knew, at the time, that anyone would ever need to reconstruct it.

Same failure. The record you need on the bad day has to be created on the ordinary day, by someone who has no idea the bad day is coming.

That's the whole discipline, honestly. Everything else is detail.

A test you can run this week

Pick one project. Pick one quality requirement — any one. Now hand it to someone with no involvement in that project and ask them to reconstruct, from objective evidence alone and without asking anyone a single question, what was required, what was verified, against what criteria, by whom, what was found, what was done about it, who confirmed closure, and whether management ever saw it.

If they can, your system is real.

If they need to ask someone — and they will — then what you have isn't a quality management system. It's a group of good people, and a document that describes what they'd be doing if they had time.

The audit finding will be minor. What it tells you is not.