Training and Awareness Essentials for NIST SP800-171 Controls

Eric Marquette

Welcome back to CMMC Unlocked. I'm Eric Marquette, joined by Paul Netopski and Roz the Rulemaker. Today we're diving into the essentials of awareness and training for NIST SP800-171—specifically how these map to CUI risk, your organization's security policies, security roles, training, and insider threats. Paul, let's kick this off with 3.2.1—identifying and communicating those CUI-specific security risks.

Paul Netopski

Absolutely, Eric. Control 3.2.1 sits at the core of a healthy cybersecurity posture. When we talk about CUI—Controlled Unclassified Information—the risks aren't just theoretical. It's about making sure managers, sysadmins, users, everyone, can actually identify where security risks pop up within their everyday activities. That’s not just a one-off briefing or a PowerPoint—they need ongoing, regular exposure to these risk conversations. I always recommend the CDSE "Introduction to Cybersecurity" eLearning module as the foundation—it covers not only the basics but the evolving threat landscape as it applies to CUI contexts. Risk briefings should be tailored and recurring, not just annual checkboxes.

Eric Marquette

Yeah, and you know, I saw this firsthand with a small contractor I worked with—kind of like a three-dozen-person shop. They weren’t super high-tech, but after they went through a CUI risk awareness session, someone on the team actually flagged an email that was trying to phish for account credentials tied to a project with CUI. Pre-training, they would’ve opened it—guaranteed. By building that regular muscle of risk awareness, they dodged what could’ve been a massive incident. So, just putting it out there, this isn’t abstract—it really changes behavior.

Roz the Rulemaker

Eric, that story illustrates the point—it’s not enough to declare that “risks have been identified.” It’s about communicating those risks in a way that’s actionable for every team member. That’s why NIST’s language here is so explicit about making sure everyone, regardless of role, actually understands what risk means in the context of CUI. Not just knowing it exists, but being able to spot it and do something. So, you can't just send one email with a risk matrix—there’s gotta be a channel for continuous updates and scenario-based awareness.

Roz the Rulemaker

Let’s flow from risk awareness to something just as critical—awareness of the policies, the standards, and the procedures that support your security program. That’s NIST control 3.2.2, which, at first glance, looks a lot like a documentation exercise. But really, it's about the human piece: does your workforce actually know what’s in these policies, or is policy just a “see appendix” clause? Having stacks of policy binders—or more likely thousands of pages in a digital file—doesn’t cut it if people can’t operationalize what those policies mean for their day-to-day actions. I’ll point folks to CDSE’s “Security Policies and Procedures” course, which I think does a decent job distilling the essentials.

Paul Netopski

Roz, I agree. Look, on an assessment, one of the first things we try to determine is whether the organization is just filing paperwork, or if there’s an embedded understanding throughout the org. The goal isn’t just for managers, sysadmins, and users to recognize their policies exist, but for them to realize that these security requirements are tied to their daily tasks. And sometimes, even just asking a user about a policy, you know, you’ll get “uhh...that’s in IT’s job description, right?” That’s a flag. Good programs create feedback loops—policy reminders, scenario drills, informal roundtables. The organizations that do this best treat policy awareness as a living process.

Eric Marquette

Yeah, and to your point Roz, I think the question that keeps coming up is how you make sure people get it—not just see it, but really internalize it. I’ve seen places where new hire orientations walk people through basics, but three months later? Totally forgotten. It relies a lot on managers keeping these policy requirements visible, like part of regular security "standups" or whatever you wanna call them. It’s not perfect, but beats the old “check-the-box-and-move-on” approach.

Roz the Rulemaker

Exactly, Eric. Documentation is necessary, but unless those policies permeate operational culture—and that means periodic reviews, refresher sessions, and, yes, the occasional quiz or quick scenario drill—you’re not going to see much improvement. Keep policies relevant, accessible, and actionable. Don’t let them collect digital dust.

Paul Netopski

This leads us directly into 3.2.3 and 3.2.4: making sure security roles and responsibilities are defined and assigned. And I want to emphasize the distinction here—it’s not enough to say “security is everyone’s job.” That line only gets you so far. Your documentation should clearly state who the responsible parties are for each information security-related duty, and it should map to their job descriptions or contracts if you really want to ensure accountability. CDSE offers a “Roles and Responsibilities in Information Security” module that lines up with this requirement pretty well—worth a look if you’re unsure where to start.

Eric Marquette

Paul, it’s funny you mention that clarity—because I remember working with a team prepping for their CMMC assessment, and the main reason they passed with flying colors was because their role descriptions were crystal clear. For example, their sysadmin knew exactly what logs he was responsible for, the audit team had a procedure for evidence collection, and the managers weren’t left guessing either. It seems obvious, but spelling out those boundaries and making it official—on paper—meant that when the assessors came in, nobody was shrugging or second-guessing their duties. So, defining and then training to those responsibilities was a game changer for them.

Roz the Rulemaker

That’s a great example, Eric. I see a lot of organizations where the intent is there—they want clear roles—but the execution's a little fuzzy. Or people think, “Well, it’s obvious what the security officer does…” but then half the team thinks access reviews are somebody else’s task. Mapping out responsibilities, assigning them, and documenting that assignment isn't just for passing an audit—it's for survival. Because if something goes wrong, you want no ambiguity over who should act and how. That’s both a compliance and a risk management issue.

Paul Netopski

Yeah Roz, and there’s an assessment angle here too. Auditors will ask to see evidence not just of role definitions but if they’ve been communicated to the relevant people. If you can’t demonstrate that handoff—giving folks the right training for their roles—you’ll get a finding. So, it needs to be part of onboarding, annual reviews, the whole lifecycle.

Roz the Rulemaker

So, let’s talk about what happens after roles are assigned—making sure personnel are actually trained for those duties, which is 3.2.5. Organizations sometimes think “cybersecurity training” is a one-size-fits-all exercise, but if your training doesn’t align to the nuanced roles you just defined, you’re missing the mark. This is where aligning offerings like the CDSE’s “Cyber Awareness Challenge” with an ongoing professional development plan for your IT and security folks is critical. Training should actually support someone’s job function, not just check a compliance box.

Paul Netopski

And Roz, effectiveness of that training doesn’t come from a pretty certificate or a completion percentage. The core of NIST’s focus here is about measuring whether folks can actually perform their responsibilities in practice, not theory. Scenario-based drills, tabletop exercises, and periodic practical assessments are how you close that loop. If you want to know training works, observe people handling a simulated phishing attack or an unauthorized access scenario, not just acing quiz questions. You get that capability gap pretty quickly.

Eric Marquette

Right—and I mean, not to sound like a broken record about this, but in Episode Eight we talked about immersive cyber range training at Bridgewater State. That experiential angle—putting people in a lifelike situation where they have to react on the fly—completely changes how they internalize security principles. You see who knows their stuff and where the cracks are in your training plan. That kind of direct observation gives you insight you just don't get from static training.

Roz the Rulemaker

It’s all about outcomes—if you’re not seeing improved readiness or fewer mistakes in your daily operations, your training probably needs an update. And the best organizations evaluate—even quantify—training impact as part of their annual security review, feeding lessons learned back into program improvements. Treat it as an ongoing cycle, not a one-and-done effort.

Paul Netopski

As we wrap up, let’s hit on 3.2.6: awareness and reporting of insider threats. This control is often overlooked, but it’s critical, especially for organizations handling CUI. The requirement isn’t just to identify potential insider threat indicators, but to make sure everyone knows the reporting process, all the way from identification to escalation paths. The CDSE “Insider Threat Awareness” course does a solid job of explaining this, and I think regular refresher labs, not just annual click-throughs, are key to building a sustainable culture here.

Roz the Rulemaker

Absolutely, Paul. I had a client a few years back, midsized services shop, who built in a requirement for yearly insider threat training, targeted not just at IT but admin staff too. About six months after launch, someone in accounting flagged some unusual access timing, which turned out to be the canary in the coal mine for a possible data exfiltration event. Early detection there—probably because the training made them confident enough to say something—stopped the damage before it started. That’s the optimal outcome: not just knowing what insider threats are, but empowering people to actually act when they see them.

Eric Marquette

Couldn’t agree more, Roz. And the thread tying all these controls together, from CUI risk awareness through to insider threats, is that real security—like, actual protection of data—depends on shifting from passively knowing to actively doing. Building on previous episodes where we’ve talked about the importance of updated incident response, active roles, and regular documentation reviews—it all comes back to the people piece. The stronger your culture of awareness and accountability, the more likely you are to prevent or catch issues early.

Paul Netopski

That’s a perfect spot to wrap for today. We covered everything from risk briefings to the nuts-and-bolts of insider threat programs, all mapped to what NIST and CMMC expect. As always, keep training, keep documenting, and don’t let awareness slip into the background.

Roz the Rulemaker

I’ll echo that. Remember—compliance is a living, breathing process, not just annual PDF paperwork. Thanks for tuning in, and we’ll see you next time with fresh insights from the evolving world of cybersecurity compliance.

Eric Marquette

Thanks Roz, thanks Paul. Appreciate everyone joining us—don't forget to check out past episodes if you want more real-world stories. We'll be back soon with another CMMC Unlocked deep dive. Take care, everyone.