Training Records Prove Attendance, Not Competence
Every certified organization can produce training records. Signed rosters, completion certificates, a matrix showing green across the required modules. The records are usually in good order, because they are easy to keep in good order.
Ask the same organization who is qualified to perform a specific piece of work — not who has been trained on it, who is qualified to do it — and the answer gets slower.
That pause is the whole problem. The record and the claim are different objects, and most systems only hold the first one.
What the record actually proves
A training record is evidence of delivery. It documents that an event occurred, that a named person was present, and that a date can be attached to both.
Competence is evidence of receipt. It is a claim that the person can perform the work to the required outcome.
Nothing about the first establishes the second. A person can attend the session, sign the sheet, and leave without the capability the session was meant to build. This is not a hypothetical failure mode. It is the ordinary result of a delivery method chosen for administrative convenience — a fifteen-minute walkthrough of a slide deck, a read-and-acknowledge on a revised procedure, a recorded module completed at 4:50 on a Friday.
Completion is the cheapest evidence an organization can collect, and it is the one almost everyone collects. It satisfies the auditor asking whether training was provided. It does not answer the question underneath, which is whether anyone can now do the work. The ISO training requirements across the modern standards are consistent on this point: competence has to be defined, achieved, and verified. Three obligations. Attendance covers none of them.
The deviation nobody had verified anyone to authorize
A nonconformity review at a medical device manufacturer. A deviation request had been approved on an inaccurate basis, and the review was working backwards to find out who had authorized it and on what grounds.
The signature traced to a specific individual. His training record was complete — every module the role called for, documented and current.
He did not adequately understand the regulatory implications of the manufacturing process deviation he had authorized.
Nothing about that situation was hidden. The record was accurate as far as it went. It recorded what it was designed to record, which was attendance. The organization had then treated attendance as sufficient basis for granting a decision authority with regulatory consequence attached to it.
That is a system design failure, not an individual one. And it does not stay inside the deviation process — the same structure runs through nonconformity handling, the corrective action process, and calibration and verification. Each of these depends on judgment applied against criteria, and each of them routinely runs on people whose only evidence of qualification is a completed course.
Competence is not only about judgment
There is a tempting version of this argument that says competence matters most where judgment is required. It is tempting because it is half true and it sounds sophisticated.
It is also wrong, and worth correcting before it becomes the takeaway.
Competence is required wherever the work has to come out right. An operator running a validated process to specification, an inspector applying a defined method, a technician performing a calibration to a documented procedure — none of that is judgment-heavy, and all of it fails when competence was assumed rather than established. Assuming competence in routine work is how organizations end up with variation they cannot explain.
What judgment-bearing roles change is the cost of being wrong. When someone is authorized to accept, release, disposition, or deviate, an unverified assumption becomes a decision with consequences that leave the building. In a regulated environment those consequences are regulatory ones, which is why a medical device QMS treats authority assignment as a controlled matter rather than an administrative one. Judgment roles are the sharpest illustration of the problem. They are not its boundary.
Two failure modes at the point of authority
When the gap surfaces, it traces to one of two places. They look alike from the outside and they take different fixes.
The first is that the competence program itself is ineffective. The people approved to authorize were never developed across the full scope of evaluation and judgment criteria the decision requires. They were trained on the procedure and never on the reasoning the procedure assumes. They know the form. They do not know what makes an answer on that form correct.
The second is that the people granting the authority never verified competence before granting it. In this version the competence program may be adequate. Nobody checked its output before handing over the decision.
The second failure is the more common one, and the more uncomfortable, because it makes authority the object rather than training. The question stops being who has been trained and becomes who decided this person could hold this decision, and what did they look at first.
Why authority lands where it does
Three patterns account for most of it.
Seniority. The authority attaches to the senior person on the assumption that competence came along with tenure. Sometimes it did. Nobody confirmed it.
Convenience. The authority goes to whoever is available when the decision has to be made — the most appropriate person on shift, which is not the same as a qualified person. Deviations, by nature, do not arrive at convenient hours.
Unassessed risk. The management system never evaluated what a deviation can actually cost. This one sits underneath the other two. Where the risk of a bad deviation has never been scoped, the authority to approve one does not feel consequential, so nothing in the organization pushes back when it lands on the nearest available signature.
The third pattern is the one to fix first, because the other two are downstream of it. An organization that has genuinely assessed deviation risk does not casually assign the authority. The care follows the understanding.
What verification actually looks like
The fix is not a better training record. It is a sequence, and the order matters more than any single element in it.
Define the criteria before defining the training. The deviation procedure — or the nonconformity procedure that contains it — has to state what gets evaluated and what the acceptance criteria for authorization are, including the regulatory considerations that apply. In practice those criteria often differ by product or by regulatory clearance pathway, which means the procedure has to carry that variation explicitly rather than leaving it to the judgment of whoever holds the pen. This is what a serious reading of required procedures produces: not a document that exists, but one that tells a competent person what a correct decision looks like.
Design the training against those criteria. Once the criteria exist, training has something to deliver. Comprehensive events built to develop the reasoning, not a walkthrough of the form. Where the criteria are specialized — regulatory implications of a process deviation being the obvious case — that warrants dedicated training specific to the procedure and the regulatory criteria, separate from general process training.
Verify that competence exists. Verification is a separate act from delivery, and it needs its own evidence: testing against the criteria, structured observation of the person applying them, review of past performance on comparable decisions. Any of these produce a defensible answer. Attendance produces none.
Establish performance criteria for the role and the process. Verification at the point of authorization is a snapshot. Performance criteria keep the claim live — they define what good execution of the role looks like on an ongoing basis and give the organization something to evaluate against when decisions are reviewed. This is the point where competence stops being an implementation exercise and becomes part of how the quality management system is actually run.
Run that sequence and the organization gains something it did not have before: an answer to who is qualified that survives being asked twice.
The diagnostic
One process, one afternoon.
Pick a decision in your operation that carries real consequence — a disposition, a release, an authorization, an acceptance.
Identify who currently holds the authority to make it. Not the role on the org chart. The people who actually sign.
For each of them, find the evidence that they are competent to make it. Not that they were trained. That someone established they can apply the criteria correctly.
If the only evidence is a completion record, you have found the gap.
Then ask the second question: who granted that authority, and what did they review before granting it?
If the answer to the second question is that nobody remembers, that is the more useful finding of the two. The competence program can be strengthened. An authority-granting process that never had a verification step in it has to be built. Where this needs an outside read — someone without a stake in the existing answer — an internal audit scoped at competence and authority rather than at document control will surface it quickly, and it is a large part of what ISO 13485 consulting work involves in regulated manufacturing. For organizations outside the device space, the same review runs through an ISO 9001 consultant engagement without much modification, because the structure of the failure does not change with the standard.
Your training records will tell you who attended. That is all they were built to tell you.
The organization still has to be able to say who is qualified — and be able to show what that judgment was based on.
