Register / MIQ-ART-008

Competence vs. Training Records: What Clause 7.2 Really Requires

A signed sign-in sheet proves someone sat in a room. ISO 9001 asks for something else entirely: evidence of competence. Where training matrices go wrong, and what auditors actually probe for under clause 7.2.

Document No.
MIQ-ART-008
Revision
A
Effective Date
Jul 06, 2026
Category
Competence
Prepared By
My ISO Consultants

Somewhere in almost every QMS we audit, there is a training matrix: a grid of names and procedures with dates in the cells, maintained with genuine diligence by someone in HR or quality. And in a large fraction of those audits, the matrix is simultaneously complete and useless, because it answers a question ISO 9001 never asked.

The standard doesn’t require trained people. It requires competent ones. The difference decides audit findings, and more importantly, it decides whether your quality problems trace back to people who were shown a procedure once and never actually absorbed it.

What clause 7.2 says, in order

The clause has four steps, and the sequence matters:

  1. Determine the necessary competence for people doing work that affects quality performance.
  2. Ensure they’re competent, on the basis of education, training, or experience.
  3. Where applicable, take actions to acquire competence that’s missing, and evaluate the effectiveness of those actions.
  4. Retain documented information as evidence of competence.

Look at where training appears: step three, as one of several remedies for a gap. Training is a corrective action for missing competence, not the requirement itself. And like every corrective action in the standard, it comes with an effectiveness check. A sign-in sheet records that the action occurred; it says nothing about whether it worked. That’s the gap auditors walk through.

The audit sequence that exposes it

Any experienced auditor runs the same play, and it’s worth running on yourself first. Pick a person doing quality-critical work, a final inspector, say, and ask three questions in order:

“What competence does this role require?” Not which procedures they’ve read: what they need to be able to do. Interpret GD&T callouts, operate the CMM, make accept/reject decisions at the boundary. If the role’s requirements were never defined, step one failed, and everything downstream is decoration.

“How did you establish this person has it?” “They attended training on WI-105” is an answer about step three. The clause asks about step two. Acceptable answers look different: a qualification test with a scored result, a first-article approval authority granted after supervised builds, documented experience reviewed against the role requirement, an annual eye-exam and re-certification for visual inspectors.

“When the requirement changed, what happened?” Revision C of the work instruction added a new torque spec. Who decided whether that revision required re-training, re-qualification, or nothing? In matrix-driven systems, the honest answer is that the matrix owner noticed, eventually, sometimes.

The matrix survives question one and dies on questions two and three.

What evidence of competence looks like

You have wide latitude here, and lightweight beats elaborate. What works in practice:

  • Role-based competence definitions, a paragraph per role, not per person: the demonstrable skills, any required qualifications, and how competence is verified.
  • Verification with a result, not just an occurrence: a passed practical evaluation, an approved first article, sign-off by someone already qualified, a probation review against the defined requirements.
  • Effectiveness checks on training that respond to reality. The cleanest evidence isn’t a form; it’s a loop. If an operator’s process starts generating NCRs three weeks after training, and your system connects those NCRs back to a re-evaluation of that training’s effectiveness, you’re doing what step three actually asks. If NCRs and training records live in different spreadsheets owned by different departments, that loop cannot close, structurally.
  • Re-qualification triggers: document revisions above a threshold, a lapse in performing the task, an escaped defect attributable to judgment.

The revision-control problem hiding inside 7.2

Here’s the part that makes competence a document control problem, and the reason spreadsheet matrices decay: the matrix cell says “trained on WI-105,” but WI-105 is now at revision E and the date in the cell predates revision C. Is that person current? The spreadsheet has no idea, because it stores a date, not a relationship.

A system that treats competence records as linked to specific revisions of controlled documents can answer the question the matrix can’t: show me everyone whose qualification predates the current revision of any document their role depends on. That’s a report, not an investigation. It’s also, not coincidentally, the exact question an auditor asks after finding a recently revised work instruction: who was informed, and how do you know they’re still competent to it?

The takeaway

Retire the mindset that training records are the deliverable. Define what each quality-affecting role must be able to do, verify it with something that has a pass/fail, connect the verification to the current revision of the documents it depends on, and let your nonconformance data challenge your training effectiveness. Do that and the audit conversation gets short. Keep polishing the matrix and you’re maintaining, with great care, evidence for a requirement that was retired in 2015.

MIQ-ART-008 · Rev A · 4 min read · Uncontrolled when printed← Back to the Register

Reading About It Is the Slow Way.

Request early access and a consultant will walk you through the system live, on your processes, not canned demo data.

Request Early Access