Training Records and Compliance: What Has to Be Kept

Training records are treated as reporting until the moment they are evidence. Then the question is not how many people completed a course but whether you can demonstrate that a specific technician was qualified to perform a specific operation on a specific date.

Most systems answer the first question well and the second badly.

Requirements differ by market, by manufacturer programme and by the type of qualification. Nothing here substitutes for your own obligations.

When records become evidence

A manufacturer audit of warranty claims, checking that the technician was certified for the operation claimed. See warranty administration.

A franchise standards review.

A safety incident, where the question is whether the person was qualified and when they were trained.

A regulatory inspection, where a qualification is a legal requirement — high-voltage work, refrigerant handling.

A liability claim following a repair.

In each case the record has to support a statement about a person, a capability and a date.

What a defensible record contains

Who — identified unambiguously, not by a name that appears three times in the network.

What — the specific course or qualification, with its version. A completion against a course whose content has since changed needs to say which version was completed. See updating courseware.

When — completion date, and where relevant the assessment date separately.

Result — pass, score, or assessed competent, with the criteria used.

Validity — expiry date where one applies, and current status.

Assessor — for anything assessed by a person rather than by a system.

Evidence — for practical assessment, whatever was recorded. A checklist, photographs, an instructor sign-off.

And an audit trail on any subsequent amendment.

Where records fail

Version not recorded. "Completed the course" when the course has been revised three times, including once to correct a procedure.

Expiry not tracked. The certification lapsed and nobody knew. This is the most common finding and it is entirely preventable with notification before rather than after.

Identity ambiguity. A technician who worked at three dealers in the network with three accounts. Their record is in pieces and none of them is complete.

Practical assessment not recorded at all, because the assessment happened at a vehicle and the system only records browser sessions. See standards.

Records lost at a system change. Content is portable; records frequently are not. See choosing an LMS.

Retention too short, so records are gone before the period during which they might be needed has ended.

Retention too long, which is its own exposure — these are personal data.

And amendments with no trail, so a corrected record cannot be distinguished from an altered one.

Retention: the decision nobody makes

Set a period per record type, from the applicable requirements.

Consider more than one clock. A safety qualification may need retention for a period after it expires; a record relating to a repair may need to survive as long as any liability period on that repair.

Implement it in the system, not only in the policy. The common failure is a correct policy that was never configured, and the system default — usually indefinite — is what actually applies.

And handle the leaver. A technician who leaves still generated records that may be needed. Deleting them on departure and keeping them forever are both wrong, and the middle position is a decision to make deliberately.

Personal data obligations

Training records are personal data, with the obligations that implies in most markets.

Purpose. Collected for training administration and compliance. Using them for something else — a performance process, a redundancy selection — is a decision to anticipate rather than discover.

Access. Who in the network can see an individual's record. In a franchise structure the answer is not obvious: the manufacturer, the dealer group, the dealer, the individual's manager.

The technician's own access. They should be able to see and obtain their record, and increasingly to take it with them.

Cross-border. A network spanning markets moves personal data between them, which has its own requirements.

Take advice for each market, and configure the system to match rather than relying on a policy document.

Making it work operationally

One identity per person across the network, which is the foundation everything else rests on and the hardest thing to retrofit.

Record practical assessment, in a form that aggregates. This is the case xAPI exists for.

Notify before expiry, to the technician and to the dealer, with enough lead time to arrange renewal.

Report expiring qualifications by dealer, so a workshop can plan rather than discover.

Version everything.

Test the export. Take a full record set out of the system and check it contains what an audit would need. Do this before you need it.

And check a real case. Pick a warranty claim from six months ago and try to produce the evidence that the technician was qualified for that operation on that date. Whatever that exercise reveals is what to fix.

The short version

Records become evidence at the worst moment, and the question is about a person, a capability and a date.

Record the version, the expiry, the assessor and the evidence — not just the completion.

Track expiry with notification before, which is the most common and most preventable failure.

One identity per person across the network, or records fragment as people move.

And test it against a real case before an auditor does.

For established records-management principles, consult U.S. National Archives records-management guidance.