Brilliant at the Basics Has a Scoping Problem

---

Transcript

The DoD’s CMMC Cost Problem

Jacob: All right, folks. It’s October 2026, and 95 days ago the DoD suspended CMMC Phase 2 and began a 60-day review of the program. In the meantime, the department gave us its Brilliant at the Basics campaign, 20 cybersecurity practices designed to strip away administrative complexity and compliance overhead, which sounds wonderful. The problem isn’t necessarily the practices themselves. It’s how they’ll be scoped, because terms like enterprise assets, sensitive systems, and critical data are open to interpretation. For defense contractors, these aren’t academic distinctions. Determining exactly which systems, people, technologies, and service providers must comply can be the difference between spending tens of thousands of dollars and achieving a compliant status at all. That’s what we’re going to talk about today.

Jason, the department wants contractors to focus on fundamental security practices. Don’t we all? But it hasn’t explained where those practices will apply or how. There’s no separate scoping guidance, and no specific scoping guidance within any of the Brilliant at the Basics practices, which creates more questions than answers.

Jason: Well, Jacob, there’s no specific scoping guidance for the FAR CUI rule either, or for regulations in any other area. Why would there be specific scoping for these principles for organizations in the defense industrial base? Why are we narrowing the scope? Which is funny, because everybody wants the scope narrowed to shave cost, but all the regulations that are forthcoming don’t care about your scope.

Jacob: It’s a real tension, so we’ll have to see how they settle it.

What Brilliant at the Basics Actually Means

Jacob: Before we get into it, we know Brilliant at the Basics isn’t a set of contractual requirements. You don’t have to comply with it today. But it’s the only signal the DoD has given anybody in the almost 100 days since it started reviewing the program, so it’s worth analyzing what they might care about, what they don’t, and what might be coming. Outside of this fairly detailed document, we haven’t been given any answers about how they’ll increase resiliency while also decreasing cost and burden.

Jason: The only answer I’ve heard came from a listening session months ago now, which feels like ages ago, where these were described as core information security strategies that need to be implemented everywhere.

Jacob: Well, let’s talk about the limits of the term “everywhere.”

The Scoping Problem Across 10 Practices

Jacob: Here’s a quick survey of the 10 IT practices. The first big theme is recurring scoping ambiguity.

Practice 1: Phishing-resistant MFA. Check our previous episode for a detailed look at this practice. What we didn’t discuss there is that there’s no mention of scoping at all. When it says things like “significantly reduce the risk of unauthorized access to sensitive systems,” what is a sensitive system? How do I designate one? Is it based on the data the system holds, or on a specific kind of data? Will existing scoping guidance from current regulations be sufficient, or will they change it? Is everything sensitive, and therefore nothing sensitive? We don’t know.

Jason: The biggest question I have is who determines whether it’s sensitive. Is it my discretion as an organization, going through a normal information security strategy and deciding which assets are high-impact and high-value to my business? Or is it the data coming down from the DoD, or the Department of War, that tells me to treat a system as sensitive because it touches that data? Nothing here is focused strictly on CUI.

Jacob: Exactly.

Practice 2: Comprehensive asset inventory management. This underpins configuration management, access control, detection, incident response, everything, so it’s very important and I have no issue with it. But beyond the fact that it’s a big increase over current requirements, and we’ll compare and contrast these with current requirements in future episodes, the language is very loose with implied scoping terms: “establish and maintain a dynamically updated inventory of enterprise assets including hardware, software, identities, and data across your estate,” and “an effective inventory provides a highly contextualized understanding of every asset.” What is an estate? What does “enterprise” mean? What does “every asset” mean? Every CUI asset? Every asset in my entire organization? Where do I draw the line? Because that costs real money.

Jason: When we talk about an estate, Jason’s estate is everything Jason owns. So everything your organization owns, loosely interpreted, means everything. The stark difference from what organizations currently have to do is the dynamic updating. The inventory needs to be updated in real time as changes are made, which points toward readily available metrics that need to be reported.

Jacob: And that’s a theme we’ll take up in future episodes. These are all expansions of existing requirements. There’s no way to read them as a reduction, or even as maintaining current requirements. Honestly, I’ve never heard the term “estate” in any cyber requirement. Let us know in the comments if you’ve ever heard “cyber estate” before.

Jason: I’m definitely going to start using it a lot more now.

Practice 3: Strategic technical debt reduction. It says to minimize your attack surface by “aggressively identifying, modernizing, consolidating, and retiring unused legacy infrastructure, redundant data stores, unsupported software, and unnecessary interfaces.” All sounds great, besides the puzzling use of adjectives like “aggressively.” What is the attack surface? Is it limited to a certain kind of covered system, or everything within my estate? Is this limited to systems handling department information like CUI, or does the DoD expect a modernization effort across a contractor’s entire enterprise, which would be a significant increase in cost and expectation over what contractors have had for a long time?

Jason: I’ve heard a lot of feedback to the CIO’s office during the pause about OT, legacy systems that can’t be locked down the way they need to be and may still transmit data. Whether they do is another discussion. I think this points toward getting away from things we can’t secure and modernizing to things whose security is at least up to par for today’s threats. I don’t know if it will turn out the way they intended, because it sounds extremely costly and confusing.

Jacob: That gets back to a point we’ve made throughout the pause: much of what the department signals through Brilliant at the Basics would absolutely provide better security and resiliency, but at a sometimes significant cost, and we haven’t seen them resolve that tension. I don’t see any clue that they’ll rely on scoping to reduce cost, which is what the CMMC regulation did.

Jason: The name is a little deceiving. It’s called technical debt reduction, but it requires a significant investment up front, and you see the results later. It’s a long-term play.

Practice 4: Flexible technology stack. There’s no specific scoping guidance, just a lot of buzzwords and adjectives. We’ll save it for a deeper episode because it’s very nebulous.

Practice 5: Logical segmentation to limit adversary lateral movement. Very important for interrupting the adversary’s kill chain. It says to “implement software-defined segmentation to divide your environment into secure, isolated logical zones, because flat networks pose a risk to sensitive data,” and that restricting lateral pathways “limits and isolates sensitive department data.” Okay, here are some clues. Is segmentation expected throughout my estate, or only where necessary to protect department information? How do I draw logical zones? This implies I’d do it according to data flow, which should sound familiar to people who know their current requirements. But it doesn’t say so, and it doesn’t mention CUI, only “sensitive department data.” That’s in contrast to some of the earlier practices, which don’t use data as a scoping mechanism at all.

Jason: Now it’s starting to make a little more sense. There’s no specific scoping attached because the goal is to eliminate lateral movement. The best way into a sensitive area is to get into an unprotected, nonsensitive area of the network and work your way in by any means necessary. So the scope is your entire system, but you segment data so you know where it resides and extra protections are applied there.

Jacob: Can I have, as part of my estate, a CUI-isolated zone, a proprietary-data zone, and another isolated zone? Do I have to prevent lateral movement between zones that don’t involve any department data? Earlier practices said every asset across my enterprise. Is that every isolated zone as well? We don’t know.

Jason: It’s your estate, Jacob. You can have whatever you want. I agree it’s still open-ended, but I think the premise is to segment so lateral movement doesn’t happen anywhere.

Practice 6: Risk-based vulnerability management. No specific scoping guidance. Which assets must participate? Every asset across the enterprise, or only assets within department-sensitive-data isolated zones? We don’t know.

Practice 7: Integrate security early in the development life cycle. It says to integrate secure coding standards and automated vulnerability scanning into the earliest phases of your engineering life cycle. Are we talking about a software engineering life cycle, which would apply only to certain contractors, as software security requirements do today? Or a system development life cycle, the deep current underlying NIST’s philosophy of how you select, implement, and scope security requirements? Does this include products unrelated to DoD contracts? Today, DoD requirements are driven by CUI data and the corresponding scoping guidance. So is this another version of technical debt reduction, covering the entire life cycle of every system across my estate?

Jason: I think option C is correct, Jacob. All development life cycles need security integrated up front. That’s not just because Brilliant at the Basics says so. ISACA and the learning materials for any advanced cybersecurity management course say that in the early planning phases of the development life cycle, security should be integrated and a plan should be in place.

Jacob: That’s a lot of “shoulds.” I don’t disagree, but when it comes down to brass tacks, we’re talking about contract requirements that create covered systems. You can wave your hands and say the enterprise, the estate, every asset, all systems ought to participate. But unless you create a connective tissue through scoping requirements that makes this apply to everything, there’s no bridge into that realm. So is the DoD signaling these are good ideas, or a direction it wants to move in by expanding requirements and applicability? Do they know what they’re signaling?

Practice 8: Secure AI adoption and data protection. There’s data protection in the name, so that’s a good sign. It says to explicitly prohibit the input of “sensitive department data,” not CUI, into public commercial AI systems. What qualifies? Is it CUI? All forms of CUI, or only certain forms? Is it FCI? Something else? Is it data that will show up on a standardized form coming soon? We don’t know. Because we can’t see what they mean by “sensitive data,” it begs the question: where’s the corresponding guidance explaining what the data is, how scoping works, and what these terms mean?

Jason: And the opening paragraph of Brilliant at the Basics says the goal is to reduce administrative burden by reducing the level of detail that explains what these terms mean. By not including burdensome scoping guidance, we now have a bunch of questions up for interpretation. That always works out well.

Backup Requirements and Expanding Costs

Jacob: Practice 9: Resilient backup and disaster recovery architecture. It says to protect critical data from adversarial destruction and ransomware by establishing a secure, immutable backup architecture, and to maintain redundant copies of “all intellectual property, proprietary data, and department records” in a logically vaulted or offline environment. Is the DoD proposing to protect all proprietary business information regardless of its relationship to a contract or covered system? That would be a massive increase in scope, applicability, cost, and burden. There’s nothing wrong with wanting resilient, immutable backups, but that’s not a current requirement. And where do you limit what gets backed up? The amount of data increases cost, and so does how long you keep it. Are they signaling that everything is in scope, or only certain kinds of data? This doesn’t explain it.

Jason: It doesn’t, and it makes the cost go up if you have to back up everything. But one of the biggest problems people run into with scoping is identifying what’s CUI, migrating it, and the exercises to crawl for that data and bring it over. That sometimes amplifies costs. So maybe we’re trading one for the other, with a better purpose. Instead of scoping through my whole environment to narrow down to CUI and dragging it into an enclave, I just protect everything like I should have been doing anyway.

Jacob: It’s true that properly marking and identifying CUI is a difficult problem, so it’s easier for the department to say “scope everything as part of your security program.” That’s an easier answer, but a more expensive one. If they’re signaling that they’re okay with you spending more money because it makes life easier for them, they should say so.

Practice 10: Continuous technical workforce readiness. There’s no specific scoping. Which personnel, which roles, which technical functions are covered, and what are their requirements? It doesn’t say. Again, it implies we need additional details and administrative burden to explain what these things mean and where they apply.

Jason: Somebody should really tell them that the audience they were trying to help was small and medium-sized businesses. What kind of technical workforce does a small or medium-sized business have? This is another “keep your MSP on deck” situation. All of this implies questions that require answers, which require text to explain, which increases the administrative burden.

Jacob: Way back in 2021, in my history of CMMC video, I talked about this exact issue. I called it the paradox of burden. When you remove the details to focus on outcomes, you assume a pre-existing level of maturity. When that maturity doesn’t exist, you create a big gap between where people are and what the requirements say, and you fill that gap with information. But filling it with information raises the burden, because there’s a bunch of material to read, understand, and apply. They’re repeating the same pattern NIST ran into 10 or 15 years ago.

Jason: So what you’re telling me is that these 10 suggestions are subject to interpretation.

Jacob: Very much so, because there’s no explanation of what any of these terms mean.

How NIST SP 800-171 Defines Scope

Jacob: Let’s compare the scoping guidance we have now with Brilliant at the Basics. Contrary to popular belief, the federal government has spent years developing rules to determine the scope of contractor cybersecurity requirements. Existing requirements distinguish between assets that handle controlled unclassified information, assets that protect it, and assets that are out of scope entirely. Brilliant at the Basics doesn’t establish comparable boundaries.

Take NIST SP 800-171, which has been the requirement for a decade. Scoping is based on systems that process, store, or transmit CUI, or provide security protection for those systems. NIST says organizations can establish separate CUI security domains to limit the scope of security requirements, and therefore reduce cost. They specifically say you can scope in order to reduce cost. That’s a fundamental distinction between the CUI environment and the broader estate. It’s why those scoping lines are in the middle of page two of the publication, before you get into any requirements. They tell you straight up: scope this, limit it to the sensitive data, reduce your cost, overhead, and burden. We don’t get that with Brilliant at the Basics.

Jason: I think it’s because the people who put Brilliant at the Basics out believe intrusions come from areas we aren’t concentrating on in CMMC implementation. I still see to this day a hardened enclave that operates as the DoD business, and then a commercial environment that’s absolute chaos, like Mr. Bean bouncing off the walls. And part of me naively wants to think the DoD saw the writing on the wall and decided scope-specific might not be the future, because it creates a bigger burden for its customer base.

Jacob: Here’s the problem. These are non-federal systems. The department and the government have no jurisdiction over a system they don’t own. The only reason they can specify requirements for a system you own and operate is that their data is on it. Once their data is no longer on your system, it’s yours alone. It might sit next to theirs, but there’s no connective tissue that lets them make your stuff covered without something like the data. So if they’re signaling that data may not be the right focus for requirements, that opens a huge can of worms. Without the data flowing onto systems that don’t belong to you, how do you extend requirements onto them?

Jason: Maybe it’s like the daycare. For the past decade we’ve been asking whether the daycare is good enough to have kids come to it, and now they’re asking something broader about the whole operation. Pick your metaphor, but it’s still a very open question.

Why CMMC Scoping Can Reduce Costs

Jacob: To close the loop on NIST: for 10 years its guidance was very open-ended and not very helpful. In 2024, the final CMMC rule increased the administrative burden of understanding all the scoping guidance, but it gave us the single most useful scoping guidance for carving up data flows and deciding where controls apply, in order to reduce cost and burden. Stick with me, everybody. The irony is that the increased administrative burden that came with CMMC scoping guidance, and that alone, was the single most useful thing in the last decade of defense cybersecurity requirements for reducing cost and burden.

In 32 CFR § 170.19, paragraph (c)(1), Table 3, titled “CMMC Level 2 Asset Categories and Associated Requirements,” you’ll find different asset categories with different documentation, assessment, and security requirements: CUI assets, security protection assets, contractor risk-managed assets, which let you determine your own risk tolerance for an asset within your CUI boundary, which is crazy talk, specialized assets, and out-of-scope assets. Table 4 in the same section covers applicable requirements for external service providers based on the type of data flow they handle. All of this is specified in the regulation. It’s what lets you, if you choose to embrace it, reduce your scope, cost, burden, applicability, and overhead, which Brilliant at the Basics says are the goals.

Will the DoD Change CMMC Scoping?

Jacob: The department is still reviewing the CMMC program as of this conversation. Does that include the scoping guidance, one of the fundamental cores of the CMMC regulation? Scoping is the biggest driver of cost reduction. But if the current scoping guidance falls under “administrative complexity and compliance overhead,” will they issue more granular scoping guidance, with more administrative burden to understand, or go the other direction and leave terms like “estate” up to contractor interpretation, leaving contractors to bridge the gap between Brilliant at the Basics and what the CMMC regulation specifies? How do I square security protection assets and out-of-scope assets with “every asset within my estate”? There’s no guidance, so it’s up to my opinion. Ultimately, if the department believes existing compliance requirements are too complicated and expensive, will it preserve the CMMC scoping rules designed to help contractors manage costs, or replace them with broader expectations that could make compliance more expensive than before the review? Based on what’s written in Brilliant at the Basics, we don’t know.

Jason: Jacob, it’s funny you say that. The intention of these scoping exercises was to limit cost, but when you read the feedback to the pause and attended some of the listening sessions and town halls, some people cited this exercise as one of the burdensome things. The unknown, the extra help and consultation to figure out whether something is CUI, whether to scope it in or out. That’s not the scoping exercise itself but identifying the data at the source. And that’s if the approach even revolves around data, because some of Brilliant at the Basics and what we’ve heard from the DoD over the last 100 days suggests data isn’t how we should orient anyway.

Jacob: Like I said, we don’t want to speculate too much. All we can do is look at what the department has put out, and they’ve been talking about Brilliant at the Basics for the entire month of October and throughout the suspension. What do you think in the comments? Is the lack of scoping description in Brilliant at the Basics a better solution than CMMC’s scoping guidance? Is there a middle ground between entirely unscoped requirements and very detailed, granular scoping guidance? Is there a way to reduce administrative burden and cost while keeping granular scoping? I don’t know the answer, and I’m not sure anybody does. If you do, let us know in the comments, and pretty soon we’ll all find out together. Like and subscribe, because we need to go through all of these practices. They might signal what the DoD wants in future requirements, and they’re all a pretty big expansion over your existing requirements. Those will be fun conversations. We’ll see you next week.

Jason: See you next week.