Training Records and Competency Tracking for QC Labs

Training records and competency tracking are the backbone of a defensible QC program — yet most labs treat them as an afterthought until an auditor walks in. This post argues that competency documentation is not a paperwork exercise but an operational control, and shows you how to build a system that proves it.

The Competency Gap Most Labs Refuse to Admit

Here is an uncomfortable truth: the analyst who ran your OOS result last Tuesday may have never had their competency formally verified for that method. They attended a training session when they were hired, signed a form, and were handed a pipette. That is not competency verification — that is orientation.

The distinction matters because regulators and accreditation bodies treat them very differently. ISO 17025:2017 clause 6.4 and FDA 21 CFR Part 211.68 both require labs to demonstrate that personnel are competent, not merely trained. Attendance at a session proves exposure. A signed training record proves someone was in the room. Neither proves the analyst can perform the method correctly under real conditions.

The gap between "trained" and "competent" is where errors live.

Why Spreadsheets Are Actively Dangerous Here

Many small and mid-size labs track training in a shared Excel workbook or, worse, a binder of printed sign-in sheets. This approach has three specific failure modes that go beyond the obvious version-control headaches.

First, there is no enforcement layer. A spreadsheet cannot prevent an analyst from running a test whose qualification has expired. A paper binder cannot flag that a new SOP revision was issued three months ago and five analysts have not yet been trained on it. The system is passive — it records what happened, but it cannot prevent what should not happen.

Second, traceability breaks under scrutiny. When an auditor asks to see all training records for the analyst who generated a disputed COA, pulling that data from a spreadsheet means manual searching across multiple tabs, possibly multiple files, with no guarantee the record is complete or unaltered. In a 483 observation or an ISO nonconformance, that search happens in real time while the auditor watches.

Third, the records are not linked to results. A training record sitting in a separate binder has no relationship to the sample data it is supposed to support. You cannot answer the question "was this analyst qualified to run this test on this date" in under two minutes. In an OOS investigation, that question is not academic — it is a required root-cause consideration.

What a Defensible Competency Program Actually Requires

Building a real competency system means answering four questions for every analyst-method combination:

1. Was the analyst trained? Documented, dated, with the specific SOP revision number.
2. Was competency assessed? Blind samples, witnessed proficiency tests, or parallel testing with a qualified analyst — not just reading comprehension.
3. Is the qualification current? Most accreditation bodies require periodic reassessment, typically annual. Your system needs to enforce this proactively, not retroactively.
4. Is the qualification scoped correctly? An analyst qualified on Method A Rev 3 is not automatically qualified on Method A Rev 4 if the revision changed a critical step. Revision-level tracking is not optional.

Designing the Competency Assessment Itself

The form of the assessment should match the risk of the method. For a gravimetric moisture determination, a witnessed run with a documented result within acceptable limits may be sufficient. For a high-complexity assay — HPLC potency testing, for example — the assessment should include multiple independent runs, blind samples at the specification limit, and a documented evaluation by a qualified supervisor.

The specific criteria for passing the assessment belong in the SOP or a companion qualification procedure, not in someone's head. If the pass/fail criteria are not written down before the assessment, the assessment is not defensible.

The Requalification Trigger List

A common mistake is treating requalification as calendar-based only. Requalification should also be triggered by:

• Any SOP revision that changes a procedure step, acceptance criterion, or instrument configuration
• An analyst returning from an extended absence (most labs define this as 30–90 days)
• A pattern of OOS results or failed proficiency checks linked to a specific analyst
• A new instrument of the same type (a new HPLC is not the same as the old HPLC)

If your training system does not capture these event-based triggers, your calendar-based requalification is giving you false assurance.

The Audit Trail That Auditors Actually Want to See

When an ISO 17025 assessor or an FDA investigator asks for training records, they are not looking for a stack of paper. They are constructing a chain of evidence. The chain runs from the sample result back through the analyst, through the analyst's qualifications, through the SOP revision in effect on the date of analysis, through the assessment criteria, to the person who evaluated and approved the qualification.

Every link in that chain needs to be intact and timestamped. If any link is missing — the assessor's signature, the SOP revision number, the date of qualification — the chain breaks, and the result becomes harder to defend.

This is why a living, electronic system with a genuine audit trail is not a luxury for small labs. It is the only architecture that can produce this chain of evidence quickly and reliably. A system like Aliquora, for example, links analyst qualification records directly to sample events, so the chain of evidence is built automatically rather than reconstructed manually after the fact.

A Concrete Example: Where the System Fails Without This

Consider a real scenario pattern that plays out regularly in pharmaceutical contract testing labs.

Clearwater Analytical (a mid-size contract lab, 22 analysts) received an FDA warning letter after an inspection. Among the observations: an analyst had performed dissolution testing on a finished dosage product during a period when her qualification record showed she had only been assessed on raw material identity methods. The training coordinator had entered the wrong method code in the spreadsheet when the analyst was hired. No one caught it because nothing in the workflow checked analyst qualifications against the test being assigned.

The result was not wrong — dissolution passed specification — but the record was indefensible. The batch had already been released. The lab had to perform a retrospective review of every result that analyst had generated over eight months, assess whether reanalysis was required, and issue a CAPA that included implementing a qualification-gating mechanism.

The cost of that CAPA — in time, in client notification, in remediation — was orders of magnitude larger than the cost of building qualification checking into the original workflow. The error was not analytical. It was administrative. And administrative errors in QC records have the same regulatory consequence as analytical ones.

Building the System: Minimum Viable Requirements

If you are starting from scratch or overhauling a broken system, here is a prioritized build list:

Non-negotiable:

• A unique record for each analyst-method-revision combination
• A date of qualification and a date of required reassessment
• The name and signature of the evaluating supervisor
• Linkage between the qualification record and the SOP revision it covers
• A mechanism that prevents or flags assignment of a test to an unqualified analyst

Strongly recommended:

• Automated alerts when qualifications are approaching expiration (30 days is a common threshold)
• A requalification trigger tied to SOP revision control
• Role-based read access so analysts can see their own records but cannot edit them
• Periodic management review of qualification status across the entire analyst roster

Nice to have once the foundation is stable:

• Competency trending (tracking assessment scores over time to identify analysts who are consistently at the margin)
• Integration with scheduling so that unqualified analysts cannot be assigned to a test in the LIMS workflow

The Counter-Argument Worth Taking Seriously

Some experienced QA managers push back on formalizing competency tracking at this level, particularly in small labs. Their argument: excessive documentation overhead drives good analysts out of the industry and creates a compliance theater that distracts from actual science.

This is not entirely wrong. A poorly designed competency system — one that requires analysts to requalify every time someone adds a sentence to an SOP, or that generates so many alerts that everyone ignores them — is worse than a simple system, because it provides false assurance and erodes analyst trust in QA leadership.

The answer is not less rigor. It is smarter scoping. Not every SOP revision requires requalification — only those that change a step the analyst actually performs or a criterion they must apply. Distinguishing between administrative revisions (updated approval signatures, formatting changes) and technical revisions (changed reagent concentration, new acceptance criteria) is part of your SOP revision procedure, and it should drive the requalification trigger.

The goal is a system that is proportionate to risk, not one that is performative.

Frequently Asked Questions

What is the difference between training records and competency records?

A training record documents that an analyst received instruction — a class, a reading assignment, a demonstration. A competency record documents that the analyst demonstrated the ability to perform the task correctly, typically through a witnessed assessment or proficiency test. Regulators and accreditation bodies require both, and they are not interchangeable.

How often do analyst competencies need to be reassessed?

ISO 17025 does not specify a fixed interval but requires regular monitoring of analyst performance. Most labs set annual reassessment as a baseline, with additional requalification triggered by SOP revisions, extended absences, or patterns of analytical error. FDA regulations similarly require periodic evaluation; many labs interpret this as annual for GMP testing.

Can training records be kept electronically?

Yes, and for most labs they should be. Electronic records must meet the requirements of 21 CFR Part 11 (for FDA-regulated labs) or equivalent controls — meaning audit trails, access controls, and protection against alteration. A shared, unlocked spreadsheet does not meet these requirements even if it is stored on a server.

What happens if an analyst runs a test they are not qualified for?

The result is not automatically invalid, but it is immediately suspect and requires investigation. Depending on the regulatory context, you may need to perform retrospective review of all results that analyst generated, notify affected clients, and assess whether reanalysis is required. The CAPA to prevent recurrence is typically significant.

Does every SOP revision require analyst requalification?

No. Labs should classify SOP revisions as administrative or technical. Administrative revisions — formatting, signature updates, contact information — typically do not require requalification. Technical revisions that change a performed procedure step, an instrument setting, or an acceptance criterion do require requalification for the affected method. This classification should be documented in the revision itself.