Training CYA: when "complete all assigned modules" blocks engineers from a PLM they actually need

There's a specific kind of frustration that only really hits you at 2pm on a Tuesday: you're closing out a DHF change, you click into the PLM, and a modal pops up saying your training record is expired. Not for the document control training, not for the change control workflow — for the forklift safety video. Eighteen minutes of "do not operate while fatigued" before you can approve a software requirements spec.

We've all seen this. It's the training-CYA reflex: when an auditor asks "how do you ensure competency?", the easiest answer becomes "everyone takes everything." That's defensible on paper. In practice, it means the embedded firmware engineer can't route a document because they haven't sat through the laser safety refresher they will never, ever need.

What the standard actually asks

ISO 13485:2016, clause 6.2, is pretty clear: competence has to be appropriate to the activities a person performs. The standard doesn't say "expose everyone to every conceivable hazard." It says you have to:

• Define the competence required for each role
• Provide training or take other actions to achieve that competence
• Evaluate that the actions were effective
• Maintain records of competence

That's a role-based loop. The "training matrix" most of us inherited is role-based in theory, but in a lot of companies it's collapsed into a flat list of courses everyone needs — because the LMS doesn't support role inheritance cleanly, or because someone decided over-assigning is "safer."

The PLM lockout is where it bites

The pattern I've seen across a few QMS implementations: the PLM or eQMS gates user access on a training-completeness flag. Doesn't matter that your role only touches the PLM for risk-management records and document approvals — if your training record shows three overdue items, you're blocked.

In our Class II setup, the worst offender was a generic "facility safety" course that included forklifts, eyewash stations, and lockout/tagout. About 45 minutes. Required annually. For everyone with a building badge, which is everyone with a PLM account. The IT manager and I lost half a day the first time it rolled out because the LMS auto-enrolled and the PLM didn't have a grace period.

The half-day loss isn't the real cost. The real cost is that engineers start treating the PLM like hostile territory. They delay change orders. They batch approvals for the end of the week when they remember to clear the queue. Or worse — they find workarounds. Paper sign-offs that get entered later. Sticky notes on a researcher's monitor. The training meant to reduce risk creates a shadow process where risk actually accumulates.

What a defensible role-based training matrix looks like

Here's what's worked for us, after a few iterations and one mildly unpleasant audit observation:

• Role definitions tied to activities — explicit, with the activities each role performs mapped to required competencies. Not job titles; activities.
• Tiered training assignments — core compliance (document control, change control, the QMS overview) for anyone touching the system. Role-specific (risk management per ISO 14971, software lifecycle per IEC 62304, design controls) for the people who actually do that work.
• Justified exclusion — documented rationale when a person in a role is excluded from a course. "Embedded software engineer does not perform electrical safety testing on mains-powered devices" is a sentence an auditor can read.
• Effectiveness checks — not just "did they complete the module" but something that demonstrates they can apply it. A quiz, a shadowed activity, a review of their first deliverable.
• Re-cert cadence that matches risk — high-impact roles recert annually. Read-only roles every two years. Auditors accept this when it's documented and reasoned.

The trick is that this requires the LMS and the eQMS to actually talk. The training record has to know the user's role and what the role requires. A flag on the record header that says "role: software engineer, PLM access: change control only" is not enough — the system needs the mapping behind it.

The audit-defensibility test I run now

Before I sign off on any training assignment, I ask one question: if this person never needed this training, would the audit finding still be defensible without it?

If the answer is no, the assignment is too broad. If the answer is yes — there's a real risk they're exposed to and we need to address it — then the assignment has a reason and I can write it down.

Forklift safety for a remote PLM user with no shop floor access? That's an audit answer, not an audit risk. The "defense" is the defense, not the behavior change.

What I'm trying now

We're moving toward a model where PLM access is keyed off competence records the LMS publishes as data, not flat completions. The eQMS reads something like "has completed change-control training within the last 12 months and has a signed-off role for document approval" and grants access based on that. Generic facility modules stay required for building access — badge in, badge out — but they stop gating the QMS.

It's early. The audit response hasn't been tested yet. But the goal is simple: the PLM should not be where a software engineer discovers their forklift video is overdue. That's a facilities problem, surfaced through facilities channels.

Anyone else running into this? Specifically curious if anyone's eQMS actually exposes a competency-based access API rather than a course-completion API — Greenlight Guru, Qualio, the qmsWrapper side, whatever. The difference matters because the first lets you write role rules, and the second just gives you a boolean you can only honor or ignore.

Disclosure: I work on qmsWrapper.