Security awareness training is the practice that every organization thinks they already have covered. And a lot of them do, partially. They run annual phishing simulations. They bought a training platform. Everybody clicks through some modules in January and forgets about it by February.
The problem is that the assessor isn’t just checking whether training happened. They’re checking whether the training actually covers what your people need to know about your security program and the risks specific to their role in it. This practice covers the general awareness track for everyone. AT.L2-3.2.2 adds job-specific training for people with actual security duties.
What the assessor is actually evaluating
The NIST requirement says to ensure that managers, systems administrators, and users are aware of security risks associated with their activities and the applicable policies, standards, and procedures. There are a few things packed into that sentence.
Does training happen, and is it tracked? This is the baseline. The assessor will ask to see completion records. Who completed training, what they completed, and when. If you use a training platform (KnowBe4, Proofpoint, Arctic Wolf, whatever you have), the completion dashboard is your evidence. If you run training in-house, you need sign-in sheets or some other record that people actually attended.
Training should happen for new hires during onboarding and on a recurring basis for everyone else. Annual is the standard most organizations follow. The assessor will check for gaps: if three people were hired in June and didn’t complete training until December, that’s going to get a question.
Does training cover your actual policies and procedures? This is where most organizations fall short. Generic cybersecurity awareness training (phishing, password hygiene, social engineering) is a starting point, but it’s not sufficient by itself. The assessor will ask what your training covers. If the answer is “phishing simulations and a 20-minute video about password security” and nothing about your organization’s specific policies, CUI handling procedures, or acceptable use requirements, that’s a gap.
Your people should know that CUI exists in your environment, what it is in general terms, what the rules are around handling it, and where to find the policies that govern their behavior. For CUI-specific training, the assessor is looking for the DoD-produced CUI training module from CDSE (the Center for Development of Security Excellence). This is the standard. Don’t create your own CUI training and don’t pull something off YouTube. The DoD publishes it, and using their module is what the assessor expects. Your training platform should either host the SCORM package directly or link to the CDSE module with an attestation that employees completed it.
Your training also needs to cover insider threat awareness. This is a separate topic from general phishing and social engineering training. It covers recognizing indicators of insider threat, reporting procedures, and the organization’s responsibilities under the National Insider Threat Policy.
Is the training relevant to what people actually do? The requirement specifically calls out managers, systems administrators, and users. A one-size-fits-all training module doesn’t fully address this. Your IT admin who manages the firewall has different security risks than the project manager who accesses CUI on a shared drive. The training doesn’t have to be completely different for every role, but it should acknowledge that different roles carry different risks.
In practice, role-based training means separate training campaigns in your LMS for different groups. IT staff get training on admin privilege management and configuration responsibilities. HR and finance might get targeted training on social engineering and data handling. Executives get training on business email compromise and their role in incident response decisions. Developers, if you have them, get secure coding training. These don’t have to be massive standalone programs. A separate campaign with a few targeted modules assigned to the right group is sufficient.
What a realistic SSP definition looks like
[Organization Name] provides security awareness training to all personnel with access to organizational systems. Training is provided during onboarding for new hires (completed within [timeframe, e.g., two weeks of start date]) and at least annually for all existing personnel. Training completion is tracked in [platform] and records are retained for [period].
Training content covers: recognition and reporting of security threats (phishing, social engineering, malware), organizational security policies and acceptable use requirements, password and authentication requirements, incident reporting procedures, and physical security responsibilities. All personnel complete the DoD-produced CUI awareness training module (CDSE) covering CUI identification, handling, and marking requirements. All personnel also complete insider threat awareness training covering indicator recognition and reporting procedures.
Role-based training campaigns are assigned to personnel based on their responsibilities. Personnel with system administration or elevated access receive additional training covering: access management and least privilege principles, audit log review responsibilities, configuration management procedures, and their specific role in the incident response plan. Additional role-based campaigns are assigned to HR, finance, executive, and development personnel as applicable.
Personnel who do not complete assigned training within the defined period are subject to [documented follow-up process, e.g., automated reminders, manager notification, access restriction]. The non-completion escalation process is documented in [policy reference].
Training content is reviewed and updated at least annually or when significant changes occur to the security program, threat environment, or organizational policies. [MSSP name / internal role] supports training content development and provides supplemental awareness materials including phishing simulations, threat briefings, and policy reminders.
A few things to notice:
It lists what training actually covers. The assessor doesn’t want to guess. Spell out the topics. If your training covers CUI handling, say so. If it covers your incident reporting procedures, say so.
It addresses different roles. General awareness for everyone, additional training for system administrators. This maps directly to what the requirement asks for.
It commits to a schedule. Onboarding plus annual. These are verifiable commitments. The assessor will check whether they’re actually happening.
It names where records live. “Training completion is tracked in [platform].” When the assessor asks to see records, you can point them right to it.
How to present your evidence
When the assessor gets to AT.L2-3.2.1, have these ready:
Training completion records. A dashboard or report showing everyone who completed training, the date they completed it, and what they completed. If you use a training platform, this is usually one click. If you do it manually, have the spreadsheet or sign-in sheets organized and ready.
The training content itself. Or at minimum, a detailed outline of what the training covers. The assessor may ask to see specific modules or topics. If your training platform shows the curriculum, pull it up. If you built training in-house, have the slides or materials available.
New hire training evidence. Show that new employees complete training during onboarding. A record of a recent hire completing training within their first week or two is good evidence.
Phishing simulation results. These are more than supplemental. Phishing simulations show that your training program uses data to continuously improve. The flow matters: simulations find gaps (who clicks), targeted training gets assigned to the people who clicked, and the next simulation measures whether it worked. If your MSSP runs phishing campaigns, pull up the results. Click rates, reporting rates, trends over time, and evidence that people who failed a simulation received follow-up training.
Evidence of role-based training campaigns. Show the separate campaigns in your LMS. IT staff assigned admin-specific modules. HR assigned social engineering modules. The assessor wants to see that different roles get different training, not that everyone gets the same generic course.
DoD CUI training and insider threat training completion. Show that every employee completed the CDSE DoD CUI awareness module and the insider threat awareness training. These are specific requirements. The assessor will look for them by name.
Non-completion process documentation. Your written process for what happens when someone doesn’t complete training on time. Automated reminders, manager notification, escalation, consequences. The assessor may ask what happens to stragglers. Having a documented answer matters.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No DoD CUI training module. The assessor asks about CUI awareness training and you show a generic module your training platform included about "handling sensitive data." That's not the same thing. The assessor is looking for the DoD-produced CUI training from CDSE specifically. If your people haven't completed it, that's a finding. Don't make your own CUI training. Don't substitute something off the internet. Use the DoD module.
Generic training with no organizational context. The training covers phishing and passwords but nothing about your company's actual security policies, CUI handling, or incident reporting procedures. The assessor asks "does your training cover CUI handling?" and the answer is no. That's a gap.
No completion tracking. Training happens but there's no record of who completed it. "Everybody did it" without evidence is the same as nobody did it, from the assessor's perspective.
Gaps in new hire training. People start and don't complete training for months. Or the onboarding process doesn't include security awareness at all. The assessor will look at hire dates versus training completion dates.
No differentiation for privileged users. System administrators get the same 20-minute module as everyone else, with nothing additional about their specific responsibilities. The requirement calls out managers and system administrators specifically. Their risks are different, and the training should reflect that.
Training that hasn't been updated. The same modules running for three years with no updates. Policies have changed, threats have evolved, but the training still references procedures from two years ago. The assessor may ask when content was last reviewed.
No process for non-completion. Three people haven't finished their training and nobody can explain what happens next. You need a written, repeatable process: automated reminders, manager escalation, consequences for continued non-completion. The assessor will ask what happens when someone doesn't finish on time. "We remind them" isn't a process. A documented escalation procedure with defined steps is.
Missing insider threat awareness training. General security awareness covers phishing and social engineering. Insider threat awareness is a separate requirement covering recognition of insider threat indicators and reporting procedures. If your training program doesn't include it, that's a gap the assessor will find.
100% completion on all training campaigns. The DoD CDSE CUI module completed by everyone. Insider threat awareness completed by everyone. Role-based campaigns showing that IT, HR, finance, and execs get targeted training. Phishing simulation data showing gaps are identified and addressed with follow-up training. A documented non-completion process that's actually been used. And someone who can pull up the dashboard, walk through each campaign, and explain what's assigned to whom without fumbling through it.
If you use an MSP/MSSP
Security awareness training is primarily the contractor’s responsibility, but your MSSP can do a lot of the heavy lifting depending on the relationship.
Training platform management. Many MSSPs deploy and manage the training platform as part of their security program. They configure the campaigns, assign the modules, track completion, and generate reports. When evaluating a training platform (or what your MSSP has deployed), look for: AD sync so user lists stay current automatically, automatic reminders for incomplete training, role-based campaign support so different groups get different training, and the ability to host or link the CDSE DoD CUI training module (either the SCORM package imported into the LMS, or a URL to the training with an attestation workflow). If your MSSP manages the platform, they should be ready to pull up the dashboard and walk the assessor through the completion data.
Phishing simulations as a gap-improvement cycle. This is where phishing sims go from “supplemental” to important. The assessor wants to see that your training program uses data to find and fix gaps. The cycle: phishing simulations identify who clicks, targeted training gets assigned to those people to address the specific gap, and the next round of simulations measures whether it worked. Your MSSP should be able to show the campaign results, explain what happens when someone fails (actual follow-up training, not a “gotcha” email), and demonstrate that click rates improve over time. That’s evidence of a training program that learns and adapts.
Content development support. Your MSSP may help develop or customize training content to include your specific policies and procedures. If they manage your compliance program, they probably already know what needs to be covered and can make sure the training aligns with your SSP. They can also help ensure the DoD CUI module and insider threat training are properly integrated into the LMS.
What’s still on you: Getting 100% completion. The MSSP can deploy it, track it, and send reminders, but someone on your side needs to follow up with the people who don’t finish. 100% is the expectation, not 95%. The only acceptable exceptions are documented situations (someone on extended leave, for example) with the exception and timeline captured in policy. The assessor won’t accept “our MSSP deployed it but half the team didn’t do it.” Completion is completion.
This page covers AT.L2-3.2.1 from NIST SP 800-171 Rev 2 (3.2.1). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.