CMMC Scoping guides

Eric Marquette

Welcome back to CMMC Unlocked! Eric here, and I’m buzzing to get into today’s deep dive. We’re finally cracking open the CMMC Level 2 Scoping Guide, version 2.13, which just dropped this September. For folks tuning in and staring at that daunting PDF, don’t fret—we’re going to cut through the jargon, share takeaways, and line up some practical steps for defense contractors and compliance teams. Ruby, I know you took a first pass at this—what jumped out to you?

Ruby Sturt

Well, blimey, Eric, where do you start? I mean, the guide spells out right in the intro that it doesn’t have the force of law—it’s more “clarity to the public,” not new obligations. But the devil’s in the detail, as always. They’re super specific about this being all about organizations seeking either a Level 2 self-assessment or going for a certification with a C3PAO. If you’re in that “organization seeking assessment” camp, you’re the main audience here. No Level 1 or 3 specifics, yeah? That’s all in separate documents.

Paul Netopski

That’s right, Ruby. And the key nuance is in how Level 2 is scoped. The security requirements for a self-assessment versus a certification assessment are identical, but only a C3PAO can actually issue that certification. So, organizations seeking just a self-assessment—those are OSAs. Organizations seeking certification—OSCs—are basically a subset of that group, and this guide targets both. I found that distinction important: you’re all doing assessments, but only some assessments lead to a cert at the end.

Roz the Rulemaker

If I may add, folks, the guidance specifically ties back to section 170.19 of title 32 in the Code of Federal Regulations. It’s less about generating new mandates and more about helping people interpret requirements already embedded in law and policy—making everything just a bit more digestible during what is often a fairly intimidating process. DoD’s clarification here aligns with good regulatory practice: transparency and guidance, not hidden gotchas.

Eric Marquette

So, let’s move from the “why” to the “what”—identifying what’s actually in your CMMC Level 2 assessment scope. The scoping process, if you’re reading the reg, is all about categorizing your assets. The guide calls out five main categories for Level 2, but not all of them end up in the actual scope—there’s a sort of funnel here, yeah? Paul, could you walk us through the headlines for each asset type?

Paul Netopski

Absolutely, Eric. Here’s the quick breakdown from the guide: CUI Assets—these process, store, or transmit Controlled Unclassified Information. Security Protection Assets—they provide security functions to protect CUI, think firewalls, SIEMs, consultants providing cyber services. Contractor Risk Managed Assets—assets that could handle CUI but aren’t intended to, thanks to security controls and procedures. Specialized Assets—this is where you have things like IoT or IIoT devices, OT systems, government furnished equipment, restricted info systems, and test equipment. And lastly, Out-of-Scope Assets—these can’t process, store, or transmit CUI and offer no security protections to CUI assets. They’re essentially air-gapped, either physically or logically.

Ruby Sturt

Yeah, and what cracked me up is how precise they get—even stuff like a VDI client that just passes keyboard/mouse actions, but never sees CUI, can land as out-of-scope. But “out-of-scope” isn’t a free ticket: you still have to justify why it can’t touch CUI. That’s a potential audit point, especially if someone thinks you’re being cheeky with your boundaries.

Roz the Rulemaker

Just to underline what Ruby’s saying, documentation is essential. Each in-scope asset category must be listed in the asset inventory and shown in your network diagram. For in-scope categories, you’ll have to account for them in the System Security Plan to some degree—and the level of documentation and the assessment requirements for each category are distinctly spelled out in the table. Out-of-scope assets, conversely, require you to be ready to defend their exclusion, but you don’t have to track them the same way.

Eric Marquette

And we’ve seen this trip up clients before—your network diagram is only helpful if it actually maps to reality. After all, ambiguity can give an assessor a field day.

Paul Netopski

Let’s dig in. So, CUI Assets—you process, store, or transmit CUI, you’re in the scope, and you get hit with the full set of Level 2 security requirements, period. Your asset inventory must reflect these, your SSP should document their treatment, and you need a network diagram that shows how they fit in. No exceptions, and you will be assessed against every single requirement.

Ruby Sturt

And I’ll just jump in—Security Protection Assets don’t necessarily process CUI directly, right? But they’re still key because they help protect the cradle-to-grave journey of CUI. Think about your firewalls, your managed service providers, your cloud-based security platforms. These assets are only assessed against requirements relevant to what they do. So, if you’ve got a cloud SIEM that doesn’t touch CUI but helps monitor your environment, you still list it, document it, but you only get evaluated on the SIEM-relevant controls—it’s not “all or nothing.”

Roz the Rulemaker

That’s correct, Ruby. It’s a point of proportionality: assessment is based on function, not just the existence of an asset. The guide’s language is quite exact here. Paul—Contractor Risk Managed Assets, though, are where folks often get tripped up: these could process CUI but, by written policy and process, they’re not supposed to. They’re not physically separated—so, they share network links or even computing resources with CUI Assets. The requirements focus on whether your documentation and SSP are sufficient. If there’s any question, the assessor can run “limited checks” to identify gaps—but they can’t turn your one-week assessment into a six-week deep dive just over these assets.

Paul Netopski

Exactly. You want your documentation air-tight here. If your policies, technical controls, and boundaries are clear, the assessor should see these assets as adequately risk-managed. If not, that’s when spot checks happen. Specialized Assets, meanwhile, include OT systems, IoT and IIoT, test gear, GFE, all that. For these, you’re showing they’re administered properly under your organization’s information security policies and included in scope, but they aren’t assessed against the entire set of Level 2 controls—an assessor reviews your treatment of them, not the full suite of technical requirements.

Eric Marquette

It’s a good segue from our last episode about operational resilience—remember, if you’re leveraging a test bench or smart building apparatus in your CUI workflow, that stuff can’t just be ignored. Even if everyone says, “Oh, it’s never online,” the fact that it can process data means it’s a candidate for at least doc review.

Roz the Rulemaker

Let’s talk about boundary definition and separation. The guide echoes NIST SP 800-171 Rev 2: separation can be logical or physical—think VLANs, firewalls, or, for physical, systems with absolutely no network tie-ins, like a classic “sneaker-net” with USBs. This matters most for out-of-scope assets—if they’re isolated, you might be able to exclude them. But, be cautious: any architectural change, like a network expansion or merger, likely means you need to redo your scoping and perhaps the assessment. Minor operational tweaks won’t trigger reassessment, but boundary changes? That’s a big deal.

Paul Netopski

That’s right, Roz. And it’s worth pointing out—when you use enclaves, say a group of systems just for CUI processing, requirements only flow to what’s in that boundary. You aren’t being held hostage to enterprise controls unless you try to “inherit” a requirement—then it actually has to be implemented enterprise-wide, or you have to make it work within the enclave without breaking anything. There’s flexibility, but you have to prove every claim you make.

Ruby Sturt

And the guide spells out you don’t need to reassess just because you shuffled a few servers or upgraded a firewall. If your architecture stays the same and your SSP is updated, you’re good with annual affirmations. Which is honestly a relief for anyone who hates bureaucratic overhead—who doesn’t, right?

Eric Marquette

Absolutely. And—quick parallel to our series on continuous compliance—keeping your inventories, policies, and architecture docs up-to-date isn’t just for the assessment, it makes the annual affirmation something you can actually get through with your sanity intact.

Paul Netopski

Another thing—external service providers, especially cloud ones, get a lot of attention in this guide. If your ESP stores or processes CUI, they’re in your scope, and if they’re a cloud provider, they’ve got to meet FedRAMP requirements per DFARS. But, if your ESP doesn’t deal with CUI, it’s more about how the service impacts your security environment. Not every SaaS vendor is automatically in scope—HR and accounting SaaS, for example, usually don’t factor in unless they’re protecting or handling CUI or security data.

Roz the Rulemaker

Exactly, and the documentation the guide calls for includes your Service Security Plan, the service provider’s service description, and what’s called a Customer Responsibility Matrix—spelling out who does what with respect to CUI protections and security objectives. The guide is pretty explicit about only drawing ESPs into scope if their services actually impact your CUI environment or protections.

Ruby Sturt

And with Security Protection Data—this is stuff like logs, vulnerability scans, policy configs—wherever they live, they’re in scope. Got a SIEM in the cloud? That SIEM platform and, crucially, its log storage (hot or cold), become part of your boundary. So don’t forget those corners when you’re drawing your network diagrams or listing responsible parties.

Eric Marquette

There’s actually a bit of overlap here with our episode on documenting for continuous compliance. You’ve got to ensure that not only the platforms but the data itself—config files, log archives—are shown as part of your assessed environment, because assessors are likely to spot-check to confirm.

Eric Marquette

Alright, team, time to put a bow on this. The Level 2 Scoping Guide is a dense read, but the purpose is fairly clear: document diligently, draw your assessment boundary based on what truly touches or protects CUI, and don’t fudge categories. Know your assets, get your policies lined up, and be ready to both defend your choices and show them on paper and in your SSP.

Roz the Rulemaker

Yes, and for everyone listening, remember—rigorous asset management and clarity in your boundaries not only help with compliance but also enhance your operational resilience. Regulators are focused on transparency, so honest, thorough documentation is your friend here. Any last quick thoughts, Paul?

Paul Netopski

CMMC scoping isn’t about making mountains out of molehills. Define your asset categories precisely, use separation smartly, lock down your documentation, and—above all—keep your network diagrams, SSP, and asset inventory current. That’s your playbook, folks.

Ruby Sturt

If your eyes are glazing over after all this, just know, scoping is where you set yourself up to win or lose your assessment. Don’t let that first pre-assessment conversation be where the surprises come out. Manage your scope early and well, and the rest of CMMC is a lot less painful.

Eric Marquette

Well said! Thanks for joining us for this round—the CMMC Level 2 Scoping Guide is now a little less mysterious, I hope. We’ve got more practical takes coming up, so subscribe or drop us a comment if there’s a particular CMMC puzzle you want solved next. Signing off—cheers, Roz, Ruby, Paul!

Roz the Rulemaker

Always a pleasure, Eric. Thanks everyone, and best of luck to our listeners on their compliance journeys.

Paul Netopski

Stay secure, folks. See you next time!

Ruby Sturt

Catch ya next episode—don’t let compliance catch you napping!