Building a Security Training Program That Satisfies CMMC and Actually Changes Behavior

The Training Problem

Security awareness training is one of the most underestimated requirements in CMMC Level 2. Organizations buy a platform, assign annual training modules, collect completion certificates, and assume the box is checked. Then an assessor asks: "Walk me through how your training program addresses CUI handling specific to your environment." And the conversation stalls.

CMMC doesn't just require that training exists. It requires that training is relevant to the organization's specific security responsibilities, that it covers role-based requirements, and that the organization can demonstrate the training actually influences behavior. That's a higher bar than most off-the-shelf platforms deliver on their own.

What NIST SP 800-171 Actually Requires

The relevant controls sit in the Awareness and Training (AT) family:

AT.L2-3.2.1: Ensure that managers, systems administrators, and users of organizational systems are made aware of the security risks associated with their activities and of the applicable policies, standards, and procedures related to the security of those systems.

AT.L2-3.2.2: Ensure that personnel are trained to carry out their assigned information security-related duties and responsibilities.

The first control is about awareness: everyone in the organization needs to understand security risks relevant to their role. The second is about competency: people with specific security responsibilities need to be trained to perform those responsibilities effectively.

An annual awareness video covers part of AT.L2-3.2.1. It doesn't touch AT.L2-3.2.2 at all.

Building a Program That Works

Layer 1: General awareness (all personnel)

This is the foundation. Every person in the organization who uses a computer or handles information needs baseline security awareness. The content should cover: what CUI is and why it matters, how to identify CUI in your environment (not in the abstract, but specifically: what markings to look for, which projects involve CUI, which systems contain it), acceptable use of organizational systems, phishing recognition and reporting procedures, incident reporting (who to contact, how to report, what constitutes an incident), and physical security basics (clean desk, screen lock, visitor procedures).

The key differentiator: this training must be specific to your organization. A generic module about "protecting sensitive information" doesn't demonstrate to an assessor that your people understand your CUI environment. Reference your actual policies, your actual systems, your actual procedures.

Layer 2: Role-based training (CUI handlers, IT staff, managers)

This addresses AT.L2-3.2.2. People with specific security responsibilities need training that goes deeper than awareness.

For CUI handlers (engineers, program managers, contracts staff): how CUI is marked and tracked in your environment, authorized methods for sharing CUI internally and externally, what to do when CUI is found outside approved systems, and destruction procedures.

For IT administrators: configuration management and change control procedures, audit log review responsibilities, incident response procedures and their specific role in them, account management and access review procedures.

For managers: their responsibility for ensuring their teams comply with security policies, how to handle policy violations, their role in access authorization and periodic review.

Layer 3: Ongoing reinforcement

Annual training is the minimum. Ongoing reinforcement is what actually changes behavior. Phishing simulations on a regular cadence (monthly or quarterly), with results tracked and repeated training for users who fail. Brief security reminders tied to real events (a new phishing technique, a policy update, a near-miss incident). Tabletop exercises for incident response teams, at least annually. New hire training within the first week, not the first month.

What Assessors Look For

The evidence chain for training is straightforward but detailed:

Training plan. A documented plan that describes what training is delivered, to whom, how often, and how completion is tracked. This doesn't need to be elaborate. A one-page document that maps training requirements to roles and defines the delivery schedule is sufficient.

Training materials. The actual content delivered. Assessors may review slide decks, course modules, or training outlines to verify the content covers the required topics and is specific to the organization.

Completion records. Evidence that training was delivered and completed. This means sign-in sheets, LMS completion reports, or equivalent records. Every person in scope must have a completion record. Gaps in completion records are findings.

Phishing simulation results. If the organization runs phishing simulations (and it should), assessors want to see the results, the trend over time, and the remedial actions taken for users who repeatedly fail.

Training updates. Evidence that training content is reviewed and updated when policies change, when new threats emerge, or when the environment changes. Training materials from two years ago that reference deprecated systems or outdated procedures will raise concerns.

The Practical Takeaway

Don't outsource your entire training program to a third-party platform and assume it's done. Use the platform for delivery and tracking, but build the content around your organization's specific CUI environment, policies, and procedures. Layer general awareness with role-based training. Reinforce with simulations and ongoing touchpoints. Document everything. The goal is not to check the training box. It's to build an organization where people handle CUI correctly because they understand why it matters and how to do it, not because they clicked through a module once a year.