StealthTech
Assessors have seen the same PowerPoint a hundred times. It has a slide on phishing, a slide on password hygiene, a slide with a stock photo of a hooded figure typing in the dark, and a signature log proving every employee clicked through it once last October. It satisfies almost nobody, and increasingly, it satisfies almost no C3PAO either. AT.L2 is one of the shortest domains in the CMMC Level 2 requirement set — three practices, not thirty — and yet it’s one of the domains where contractors most consistently show up with paperwork that looks compliant and isn’t.
The gap isn’t effort. Most organizations we assess have genuinely tried to build a training program. The gap is that AT.L2 was never designed to be satisfied by a single annual event. It’s built around three distinct obligations, each targeting a different failure mode, and an assessor working from NIST SP 800-171A is going to test for all three independently. Treating them as one line item is where readiness assessments go sideways.
The Three Practices Hiding Inside One Domain
AT.L2 breaks down into 3.2.1, 3.2.2, and 3.2.3, and each one asks a different question. 3.2.1 asks whether managers, system administrators, and users know the security risks tied to their specific activities. 3.2.2 asks whether people in specific roles — the ones with elevated privileges, the ones who touch CUI directly, the ones who administer the systems that store it — have been trained on the duties and responsibilities that come with that role. 3.2.3 asks something entirely different: whether personnel have been trained to recognize and report indicators of insider threat.
Notice what’s missing from that list: nothing in AT.L2 requires an annual all-hands training event. That’s an implementation choice contractors have defaulted to because it’s administratively simple, not because the requirement demands it. An assessor evaluating 3.2.1 wants to see that awareness content is tied to actual risk exposure. An assessor evaluating 3.2.2 wants evidence that a system administrator’s training looks different from a general user’s training. An assessor evaluating 3.2.3 wants something most companies don’t have at all: content that specifically addresses insider threat indicators, not just external phishing threats.
Why the Slideshow Model Fails 3.2.1 Specifically
3.2.1 requires that personnel be made aware of security risks associated with their activities and of applicable policies, standards, and procedures related to their organizational role. The word “activities” is doing real work in that sentence. It’s not asking whether someone sat through a generic security awareness module — it’s asking whether the content reflects what that person actually does.
A generic slideshow covering phishing and password hygiene addresses maybe a third of the actual risk surface for most roles. An engineer working in a CAD environment that touches export-controlled drawings has a completely different risk profile than an accounts payable clerk processing vendor invoices. A field technician logging into a client’s network from a laptop has different exposure than an office-based project manager. When everyone gets the same eleven-minute video regardless of role, the organization technically has “training,” but it doesn’t have awareness tied to activities — and that distinction is exactly where assessors probe during interviews. They’ll ask an employee to describe what they were taught about the specific systems they use. If the answer is a shrug and a reference to “the annual thing,” the practice doesn’t hold up regardless of what the completion log shows.
This is also where the connection to your broader technical environment matters. Training content should reflect how your organization actually handles managed IT services and where CUI physically and logically lives, not a stock curriculum licensed from a vendor who’s never seen your network diagram.
Role-Based Training Is a Distinct Practice, Not an Add-On
3.2.2 gets treated as an afterthought more often than any other practice in this domain, largely because it sounds like an extension of 3.2.1 rather than a separate obligation. It isn’t. 3.2.2 requires that personnel with assigned security roles and responsibilities — think system administrators, help desk staff with privileged access, anyone managing identity and access controls — receive training specific to those responsibilities before they’re granted the associated access, and periodically afterward.
The failure pattern here is almost always the same: a company has excellent general awareness training and zero role-based content. The system administrator who manages Active Directory group policy has sat through the same video as the receptionist. An assessor asking for evidence of 3.2.2 will specifically request training records tied to privileged roles, and if the only artifact produced is the general awareness completion log, the practice gets marked not met, even though the organization believes it has “trained everyone.”
Building this correctly usually means mapping roles to responsibilities first. Who has domain admin rights? Who configures firewall rules? Who manages your cybersecurity tooling day to day? Who has the authority to approve access requests? Each of those roles needs training content that speaks to the specific duties tied to the access they hold — not a longer version of the general module, but different content entirely. For organizations working with an external provider or an external service provider that touches security functions on their behalf, this same expectation extends to that provider’s personnel, which is a detail that gets missed constantly during scoping conversations.
Insider Threat Awareness: The Practice Almost Nobody Builds Correctly
3.2.3 is the practice most readiness assessments flag as a gap, and it’s not close. Organizations build phishing simulations, they build password policy training, they sometimes build role-based content for administrators — and then they stop, because insider threat awareness doesn’t map cleanly onto any existing security awareness product most companies already own.
The requirement is specific: personnel need to be trained to recognize and report potential indicators of insider threat. That’s fundamentally different from external threat awareness. It’s asking employees to notice behavioral and technical warning signs — a colleague suddenly accessing files unrelated to their job function, someone attempting to exfiltrate data through personal cloud storage, a disgruntled employee downloading large volumes of data shortly before a resignation — and to know there’s a defined channel for reporting that concern without fear of retaliation for a false alarm.
Insider threat content also needs to connect to your actual technical controls, not exist as an abstract concept. If your organization has audit logging in place under AU.L2 or has built out incident response procedures, employees should understand — at a basic level — that unusual activity gets logged and reviewed, and that reporting a concern feeds into a real process rather than disappearing into a suggestion box. CISA’s guidance on nation-state cyber actors is a useful reference point here too, since insider threat and external compromise increasingly intersect — a compromised credential used by an outside actor can look identical, from a behavioral standpoint, to a legitimate insider going rogue.
Where Evidence Actually Lives — and Where It Doesn’t
Assessors don’t take your word for AT.L2 compliance, and they don’t accept a training vendor’s dashboard screenshot as sufficient evidence on its own. They’re looking for a policy that defines the training program’s scope and frequency, records that tie specific individuals to specific completed content, role mappings that justify why certain people received role-based or privileged-access training, and — this is the piece most contractors miss — some mechanism showing the insider threat reporting channel is real and known to staff, not just written down in a policy nobody’s read.
A few specific evidence gaps show up repeatedly in readiness work:
- Training completion records that show a date and a name but no reference to which content module was completed, making it impossible to verify role-appropriate assignment
- No documented process for training new hires before they’re granted system access, which directly undermines 3.2.2’s “before access is granted” language
- Insider threat training that consists of a single slide inside the general awareness deck rather than standalone content addressing detection and reporting
- No refresher cadence defined anywhere — a program that ran once, three years ago, with no scheduled recurrence
- Contractors relying on their co-managed IT partner to “handle security awareness” without a written agreement specifying who owns curriculum content, tracking, and reporting
Each of these is fixable, but they’re fixable only if someone identifies them before the assessor does. This is exactly the kind of gap analysis that shows up in a proper CMMC compliance readiness engagement, where documentation gets checked against actual practice rather than assumed to match.
Frequency and Refresh: What “Periodic” Actually Means in Practice
AT.L2 doesn’t specify an exact cadence for refresher training, which leads a lot of organizations to default to annual and call it done. That’s defensible as a baseline, but it’s not automatically sufficient, particularly for role-based training under 3.2.2. If your threat landscape shifts, if your organization adopts new tools, or if a new attack vector becomes prominent in your industry, a once-a-year refresh cycle can leave a meaningful gap between when a risk emerges and when your workforce is trained to recognize it.
Practically, this means separating your refresh cadence by content type rather than applying one calendar to everything. General awareness content can reasonably run on an annual cycle with periodic reinforcement — a short reminder after a real phishing attempt targets the organization, for instance. Role-based training for privileged users should be reviewed whenever responsibilities change materially, not just on a fixed calendar. Insider threat content benefits from being reinforced any time there’s organizational change likely to increase risk — layoffs, restructuring, or the offboarding of an employee with elevated access, which ties directly into the access revocation timing issues we’ve written about around employee offboarding under CMMC.
New Hires and Contractors: The Timing Problem
One detail in 3.2.2 gets overlooked constantly: training tied to a role needs to happen before that person is granted the associated access, not sometime during their first quarter once HR gets around to scheduling it. We routinely find new hires who received system access on day one and completed security awareness training six weeks later, once the next scheduled session rolled around. That sequencing failure is a straightforward audit finding, and it’s entirely avoidable with a defined onboarding checklist that gates access provisioning behind training completion.
The same logic applies to contractors and subcontractor personnel who touch your environment, whether they’re on-site or remote. If a contractor is granted network access as part of a project, and that access falls within your CMMC assessment scope, their training obligations don’t disappear because they’re not a W-2 employee. This is a particularly common blind spot for manufacturing and engineering firms working with rotating subcontractor teams on production floors, where access is often provisioned quickly to keep a project moving and training gets treated as a paperwork formality to clean up later.
Building a Program That Survives Contact With an Assessor
The organizations that pass AT.L2 cleanly tend to share a structural approach rather than better slides. They start with a role inventory — every position mapped to the level of system access and CUI exposure it carries — and build training tiers from that inventory rather than starting with a training vendor’s off-the-shelf module and trying to force their organization into it. General awareness covers everyone. Role-based content covers administrators, privileged users, and anyone managing security functions. Insider threat content stands on its own, with a clearly communicated reporting path that ties into whatever monitoring or zero trust architecture the organization has deployed.
Documentation needs to track all three layers independently — not one combined completion percentage, but records that let an assessor trace a specific person’s role, the specific content assigned to that role, and the date it was completed relative to when access was granted. That level of granularity is what separates a program that reads well on paper from one that actually demonstrates the practice was implemented as intended. Organizations that have gone through a full vCIO-level planning process tend to build this structure naturally, because role-based access planning and training tiers end up being two sides of the same conversation.
Conclusion
AT.L2 looks like the easiest domain in the CMMC Level 2 requirement set right up until an assessor starts asking pointed, role-specific questions in employee interviews. Three practices, three distinct obligations, and a single annual slideshow satisfies none of them completely. Getting this right means treating general awareness, role-based training, and insider threat reporting as three separate program components with their own content, their own cadence, and their own evidence trail — built around how your organization actually operates, not around a generic template. Contractors serving the defense industrial base out of Boston, Tampa, and Sarasota are increasingly finding that assessors expect this level of specificity, and building it retroactively under assessment pressure is far harder than building it correctly the first time.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
