This post explains how to build an evidence-ready, role-based training plan to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AT.L2-3.2.2, including templates, a compliance checklist, implementation steps for a small business, and concrete evidence items that auditors accept.
What AT.L2-3.2.2 requires and key objectives
AT.L2-3.2.2 requires that managers, system administrators, and users of organizational information systems be trained to perform their assigned information-security related duties; the primary objectives are to (1) ensure personnel understand CUI handling and protection responsibilities, (2) demonstrate role-based competence, and (3) maintain verifiable training evidence (attendance, completion artifacts, assessments) that auditors can review during a compliance assessment.
Practical implementation steps (Compliance Framework specific)
Start by scoping the "Compliance Framework" boundary: identify systems that process CUI and the personnel roles that interact with those systems. Create a role inventory mapping job titles to responsibilities (e.g., "System Administrator — user provisioning, patching, audit log review"; "Project Engineer — CUI handling, secure data transfer"). For each role, define minimum training modules (topics, duration, delivery format) and the evidence type that will be used as proof (LMS completion record, signed acknowledgment, quiz result, MFA enrollment logs). Store these mappings in a single canonical Training Matrix document and version it in your configuration-management system (Git, SharePoint with version history, or your LMS).
Template fields and examples
Use a simple, auditable Training Plan template that contains the following fields: Plan Name, Version, Effective Date, Scope (systems/processes), Role, Training Module (title & objective), Delivery Method (eLearning/Instructor-led), Frequency (onboarding/annual/triggered), Assessment Type & Passing Criteria, Evidence Artifact Type (PDF cert, CSV LMS export, signed form), Retention Period, and Responsible Owner. Example: For a 25-person defense subcontractor, a "CUI Handling — Engineers" module might be 30 minutes eLearning + 5-question quiz (80% pass), attendance recorded in LMS with CSV export, and quarterly phishing simulation results linked to the user record.
Evidence types and technical details for collectors
Design evidence collection so that artifacts are tamper-evident and can be correlated to user accounts: use LMS systems that export CSV/JSON with timestamps and user IDs, issue PDF certificates with embedded unique IDs and SHA-256 hashes, and maintain signed training acknowledgments in an HR or document management system with audit trails. For technical roles, attach logs that show configuration changes or access patterns (e.g., sudo logs, MFA enrollment logs) to demonstrate operational competence. Keep retention aligned to contract and regulatory requirements (commonly three to six years) and protect the evidence store with access controls and integrity controls (WORM storage, cryptographic hashing, or immutable object storage buckets).
Small-business real-world scenario
Consider a small IT services firm with 18 employees bidding for a DoD subcontract: implement a minimal plan by (1) creating a one-page Training Matrix listing 6 role-module pairings, (2) purchasing an affordable LMS (supports SCORM/xAPI) to deliver modules and export completion reports, (3) scheduling a 45-minute onboarding session for new hires and annual 20-minute refreshers, and (4) running quarterly 1-day phishing simulations and recording results. Evidence package for an audit: Training Matrix v1.2, LMS export CSV for the past 12 months, three sample PDF certificates, phishing simulation report, and signed training-policy acknowledgment for each employee. These are lightweight but sufficient when linked clearly to the control requirements.
Checklist: quick verification before assessment
Use this checklist to verify readiness: 1) Training Matrix exists and is versioned; 2) Role-to-module mapping documented; 3) Delivery method and frequency defined; 4) LMS or other mechanism produces timestamped completion artifacts; 5) Assessments with pass criteria are enabled; 6) Signed acknowledgments or certificates stored and protected; 7) Evidence retention policy documented; 8) Responsible owners assigned; 9) Periodic testing (phishing or tabletop) scheduled; 10) Linkage between training artifacts and HR/user identities validated. If any item is not checked, add remediation tasks with target dates.
Risks of not implementing AT.L2-3.2.2 correctly
Failing to implement this control increases operational and contractual risk: untrained personnel mishandle CUI (improper file transfers, unsecured local storage), higher likelihood of successful phishing or social-engineering attacks, and failed assessments that can lead to lost contracts or required corrective action plans. From an audit perspective, missing evidence (no timestamps, unverifiable attendance) often results in a finding even if informal training occurred—auditors want verifiable, repeatable artifacts, not anecdotes.
In summary, an evidence-ready training plan for AT.L2-3.2.2 is built from a scoped Training Matrix, role-based modules with assessment criteria, tamper-evident evidence storage, and a simple compliance checklist; small businesses can meet requirements affordably by choosing an LMS with exportable artifacts, maintaining versioned documents, and linking training evidence to HR records and system logs to demonstrate real competence and accountability.
