Name: CMMC Scoping Pitfalls: The Hidden Issues That Derail CMMC Readiness
Uploaded: 2026-01-28T18:30:59.108Z
Duration: 1 h 1 min 24 s
Description: CMMC Scoping Pitfalls: The Hidden Issues That Derail CMMC Readiness

Transcript for "CMMC Scoping Pitfalls: The Hidden Issues That Derail CMMC Readiness": Good morning, good afternoon, or good evening, depending on where you hail from. Looking forward to the conversation today. I think we have a great session about CMMC scoping, pitfalls. I'm here with Eric Winkler, one of my partners in the ecosystem from ControlCase, and I'll let Eric introduce himself here in a second to give the the formalities about what ControlCase is and and where they are in the ecosystem versus CyberSheath. But I think we bring a great topic of conversation today, something that's often overlooked when it comes to performing CMMC assessments, planning your CMMC journey. Scoping is is critical. So we wanna jump into some of the hidden issues that derail CMMC readiness, and they can derail readiness significantly because it's easy to focus on the control requirements that that are written in front of you, but there's not a strong kind of process or workflow to ensure you have quality scoping. CMMC scoping guideline helps. But in the end, you need to know the assets, the people, the processes that all relate to CMMC systems, those that process CUI. I know there's a lot of information out there in the ecosystem today, but we appreciate your time in joining us and allowing us the opportunity to share our perspective as a service provider in the space and a c three p o and advisory consultant firm on Eric's side. Next slide, please. So our agenda, we'll get into about us, what the difference is between service provider and control case as a c three k o and advisory firm. Then we'll get into why scoping should come first as it relates to your CMMC journey. We always say assess first, but the first step in assessing is understanding what you're assessing. So scoping is is critical. We'll give some examples of getting through an assessment without doing scoping and and having some issues arise when you when you go through that process and don't fully understand your scope. We'll go from definition to reality, giving the giving you the practical perspective, the hidden cost of getting scoping wrong, building defensible scope, meaning that you can't just hand wave your through your scope. You should at least be in a position to defend that scope and the factors of defining boundaries, not just on paper, but through tangible and defensible means. We'll define what good looks like in practice, and then we'll talk about from insights into action. Next slide. So I'll I'll start with my own kind of introduction first. Casey Lang, SVP of Compliance Services. Been within working within this space for about twenty years now. Previously worked at BAE Systems, built a program on everything that predicated CMMC back in 2008 when it was a voluntary, voluntary program on the initial set of requirements extracted from NIST 08/1953 at the time, but it was all back to the original mission of the DOD. Hey, defense contractors. You own a lot of our data. Let's, let's have this voluntary program, start to protect this data, find out if we have the bad guys, the nation state threat actors siphoning information. So we went through everything from the incident response process to developing the program on the on the principle and the initial requirements. But that said, join CyberSheets, and help build this program as a service provider our clients get to a compliant state. Eric, my colleague in the in the ecosystem from controls from ControlCase. Eric, I'll let you give your perspective on what ControlCase is, how you guys operate, and your position in the in the CMMC realm. Okay. Thank thank you, Casey. Hi, everyone. My name is Eric Winkler, and I head up the federal, team here at ControlCase. I've been with ControlCase for now, ControlCase now eighteen years. ControlCase was you know, our focus is providing IT audit and certification services, to all of our customers. And and our intent is to make, you know, audit and compliance as easy as possible for our customers. Our our real focus, more recently has been on the federal space, and and we're and and accredited. I'm sorry. An authorized c three PAO and and able to provide CMMC certifications to to our clients. So we we we can provide support on on the readiness side, but our primary focus is is really on the IT certification side. And and wanna give you some some background on how you can prepare for your for your your own CMMC certification. And and, hopefully, this this presentation will help help guide you down the path to a successful CMMC certification. Thanks, Casey. Yeah. Thanks, Eric. And and just to drill into the the readiness side versus this the c three p o or the certification side. On the certification side, you do both certifications, but you guys exceed just CMMC as well. Other things in the federal space fall within your lane. Right? Like, I think FedRAMP authorization, That guys are that is correct. yeah. Yeah. We are we are a FedRAMP accredited, three PAO. So we do we do provide, FedRAMP certifications as well as, FedRAMP, equivalencies required by the day to day for for certain cloud services. Yep. And just to, I know we've presented on this topic before, but the distinction between c three PAO and readiness work, meaning, there's kind of this line in the ecosystem between, like, if you guys are operating in a readiness capacity, capacity, you can't certify your own work. But where we where CyberSheath falls on the service provider side, we're also in the readiness business. Right? So we serve we're a service provider that kind of operates with our clients, in a functional capacity, IT services, security services, compliance services, your readiness services are you're there to help prepare. But, ultimately, you guys want to, or or operate in the certification space outside of readiness when it comes to getting your clients over the finish line and holding the certificate that you validated their requirements. That that is correct. Yeah. Our our bigger our primary focus is the IT audit space and and certification. So that and and we wanna make that process as streamlined as possible for our customers. So that's that's really our focus rather than readiness. Yep. Makes. sense. Makes sense. Alright. So I know you and I both have opinions on why scoping matters, why it's critically important. We've probably both seen it in the field where scoping has gone wrong or or hasn't gone at all. But give me share share some perspective from your side on what what happens when scoping goes wrong. Like, what does scoping going wrong actually look like? So from a a CMMC certification perspective as a c three PAO, If the if the scoping is is not sufficient, you know, the obviously, we we we follow the the the CMMC assessment process for all of our clients. There's a phase one phase as part of the certification assessment. And then to get out of the out of phase one, you have to show that you actually have the availability of all the documentation we need to perform the the CMMC certification assessment. If, the scoping documentation is not complete or there's missing documentation, you would not get out of phase one, and you would not be able to proceed with your CMMC certification. So it it can have a big impact on your schedule. So if you have you you're planning yeah. would you consider, like, the inputs and outputs of a scoping process? So for for those kind of defense contractors that might be going it alone and and trying to figure out what scoping means, like, I I always see it as, like, gotta get the right people in the room. You gotta identify the right assets, and the assets are commonly seen as systems, system components, but also include people part of the process, as well. But, like, how would you how would you suggest to the audience, like, hey. What do we what do we do? Like, what does scoping even mean? Yeah. Obviously, you wanna you wanna have the the people that understand, how you how you use IT technology and what IT technology, applications, everything that you're using to support your business, you wanna have those people involved in the process. And then understand how, CUI data is being used within those systems, what people and processes are using CUI data, where that where that data may be stored, processed, or transmitted, and and be able to document all of the assets that would be in scope. So all the people assets, all the hardware assets, all the software assets, be able to document all of that as part of your scoping exercise. I wanna highlight something that you you maybe said lightly, but just wanna emphasize it. So, you mentioned or at least you alluded to it's not just an IT problem. You have to get the right people in the room. IT is is part of the certainly part of the the compliance journey, a big part. 60% of the controls or more are IT in nature. But to understand CUI, the regulated dataset, it is a data centric framework, CMMC. The people who know the data the best are the people who actually work with the data. So a lot of times when it comes to knowing what platforms need to comply or which ones, serve as a CUI asset in the CMMC scoping guide versus the other asset categories, Some you you gotta get the people who are engaging with it sometimes precontract, and I think of, like, business development people, contracts people that might receive CUI specification before you are contractually engaged. And then from there, it's it's the program staff, like, the people that use the IT resources, but the ones that know, like, I'm building the defense widget. So, therefore, I receive the CUI or I make the CUI in accordance with the requirements or I build a a a thing based on something marked CUI. They're the ones handling it. Right? Like, I I always emphasis emphasize this point because sometimes this CMMC problem just lands on the IT person. Like, hey. This looks like IT. Go figure it out. But that IT person needs to realize they need to engage with the folks who actually understand the CUI on a day to day basis. Is is that, does that resonate with what you're seeing out there? That is that is correct. Yeah. Yeah. And I've seen, you know, having participated in a in a number of of scoping exercises and or seeing the results, know, you're involving, people, again, like you said, from your could be from your sales team that are dealing with RFPs. Right? Government RFPs, you could be dealing with people in the finance department, contracts. Right? The contracts people, they may deal with FCI data, CUI data as well. So it's important to have everybody everybody involved in the scoping process. Yeah. Yeah. Absolutely. And I I always walk it through, as, like, a start to finish process. Mhmm. Like, okay. Inbound, pre contract, platforms involved, where does what transfers it, what's involved? Project people, same questions. How do you receive it? How does it move? Where does it land? And then, like, ultimately, where does it go? Mhmm. And sometimes we find out, like, when you're engaged boots on the ground with the people who handle it, like, sometimes they're printing it and sticking it on the side of a pallet in an envelope, and those are the things that you need to get to and account for. So it's there are platform risks. If you don't identify all the platforms, there's certainly risk there, but there's also handling risks as well. So, scoping doing scope correctly should account for all those things. So if you have a massively complex environment, at least sample enough to have confidence. But, otherwise, I would say, understand those data flows and everything that it that's impacted by them. Alright. Let's jump on to the next slide. Alright. So the current get readiness gap. Contractors believe they are CMMC ready, but if they haven't scoped their environment appropriately, what does that look like from a practical stance on on your side, Eric? I see it all the time. Like, the big example that I've always give, that I always give and I I have in the past is, hey. I went through this assessment. I talked to my Windows administrator. My Windows administrator said, hey. Everything's great, like active directory, authenticated users, individually named users, all the right things. And then you get to the end of the assessment, and it's like, you find out that an engineer comes forward and says, well, I I have a a team and we're on Linux workstations. Like, that's a big, that's a big miss when it comes to scoping. But but talk to me about that example and maybe others like it where it's like, uh-oh. I thought my score was good, but suddenly it's not. Yeah. I I mean, a lot of a lot of what we've seen there is, you know, obviously, most organizations, at least at a minimum, have a a network diagram. Right? They know exactly what systems that they have, in their enterprise. So you wanna make sure that, you know, when you're when you're scoping and and doing readiness, that you make sure that you cover, at a minimum, you know, address all of the assets in your enterprise that you feel will be in scope for CMMC. You wanna make you wanna make sure you don't miss any. So when you establish, you know, your CMMC boundary, if you will, make sure all of those assets are are documented, and are, obviously labeled as, security protection assets, CUI assets, as defined by by the CMMC final rule, make sure those asset categories are correctly assigned. And I think that's the biggest, you know, the biggest starting point is is to start with start with your current state. Make sure that you include everything in the current state and evaluate at the asset level everything in the current state so that you don't miss anything, when you're putting those into into into scope for for your organization for CMMC. Talk to me about the impact of that example that I just gave. So, like, yep, client self assessed. They they they forgot about Linux, and Linux happens to be, it is a CUI asset in in this in this use case that I'm that I'm putting out there, and it's self managed by the engineering team. It's a little wild wild west. Like, the potential impact for that and how it cascades through the framework and the scoring, how you've gone from bad score to low score, like, Yeah. it's pretty sick. yeah. Yeah. So so, obviously, the the first the first part where you'll you'll run into noncompliance is with the SSP itself. So there's an entire requirement within the CMMC to have a complete SSP. If a CUI asset is not represented in the system security plan, the SSP, that control there would be marked as not met. So you're already are obviously already failing compliance with CMMC at that point. And then it just goes from there. Right? So you don't you don't you don't meet the access control, requirements for because you've left out Linux, and it's a c h CUI asset. You don't have the the appropriate, controls in place for for audit logging, and then it just goes on from there. So easily, you know, missing a platform could easily have you, missing more than 50% of of the the controls within the CMMC, a 110 controls, having those just be not met for leaving out a CUI asset. Yeah. Yeah. Absolutely. And that's and that's been our perspective as well. In in doing initial assessments for our clients, it's like, hey. If if you didn't account for Linux and it is truly Wild Wild West, like, it's everything from the SSP inaccurate upfront. There's no point value to the SSP requirement, but it's foundational. Mhmm. It's pretty much you know, don't like, no green light when it comes to an assessment if your SSP and your scoping and your boundaries are incorrect. But everything else from there through access management, auditing, like you mentioned, even some of the documentation, Centimeters stuff, like, if Linux is wild, wild west, do you have a build standard? Is it defined? Nonessential functionality. Like, all of those things Yeah. Configuration not. typically. happening when we when we come across those types of issues. Mhmm. So that said, fixing scope early prevents that costly rework later. You might think you're at a great score today on a Windows environment, but if you have those blind spots, you're looking at probably negative scoring in how these in how a platform miss can cascade throughout, throughout a framework. Just a quick note from the Merrill report that CyberSheath does on the bottom. 69% of respondents of that, that outreach are reporting as compliant based on their self assessment, but only three in 10 have completed medium or high high assessment audits either through DIBCAK or for or through a c three p o, which means the onus for scoping right now because you are expected to self attest and self assess is on the defense contractors to do the right thing, understand themselves and their environments through scoping, and then ultimately account for that in the implementation of their requirements. Alright. Let's move on to the next slide. Alright. So moving on from definition to reality. What scope means in CMMC? Talk talk to me about the the CMMC scoping guideline, for level two. You can get into level one if you want. But level two is is obviously the priority right now because. it aligns with supply protection, which has been in place for a long time. But there's categories within there. I often refer to the CMMC scoping guideline as a as a gift to the defense industrial base because it done didn't exist before CMMC. Yeah. The the guideline there. But talk to me about it, what it is, and and what the categories are. So obviously, the the the purpose of the of the guidance within within the CMMC final rule for scoping is to make sure that you categorize, first off, all of the they they have they have different categories of assets. So you have the, the first the main one is the the CUI assets. So those are the the systems or and or software that processes, stores, or transmit CUI. The secondary second second category are and and, obviously, with identifying an asset as CUI asset, those assets will have to be compliant with the 110 level, CMMC controls. So that keep that in mind when you're designating assets. That that kinda drives what what controls they have to be compliant with. The second asset category is security protection asset. That's the the obviously, the next biggest category, and that that will apply to a lot most of the assets that that provide security, to your, either your enclave or your enterprise that's in scope for CMMC, things like antivirus, patching, log log monitoring or log, you know, handling of of log information, audit logs. So a lot of those those types of assets will be identified as security protection assets. Lastly, you you could have out of scope assets. So any asset that doesn't fall into a CUI category or a security protection asset category could be an out of scope asset. You can also have those designated. And then you can have specialized the the other category is specialized assets. So, you may have custom tooling or custom systems, that that may process CUI, but they they they cannot support the controls to you know, that are required, to meet the, to meet the CUI protections. So you can designate those as the specialized assets. So those could be, like, an Internet of Things or or those types of of assets. The important thing is to understand when you're when you're following the scoping guidelines that you assign an asset category to all of your assets. So you don't you don't wanna have any assets listed that don't have that specification of of what they are and how they're intended to be used in your environment. Fantastic. Talk to me about so CUI assets, Mhmm. clear as day. You have to meet the the NIST eight hundred one seventy one, CMMC level two requirements. But specialized assets being things like OT, embedded operating systems, test equipment, manufacturing equipment. You know, the reason why I call the the scoping guideline a gift is because it it gives some flexibility in in what you do with those things. where in the past four, it was like, I think I can put this on a separate network and limit the connectivity and hope that DIPCAT left me alone, but this helps crystallize that a bit. Give me the perspective of c three PayO. Like, when I come across a specialized asset or even a security protection asset, like, how far do I do I take it when I when I come across assets defined as specialized or security protection assets? And then from the preparation side and your readiness capacity, like, how do you prepare, when it comes to figuring out what to do with those? So from a C-3PO perspective, from the specialized assets perspective, we look at, you know, how are you reducing the risks of, you know, of to that CUI data. So what steps are you taking to make sure that CUI data is not, lost, you know, from that device or compromised to that device? So we look at the, compensating controls and other things that you have in place. Have you done a a risk assessment to to assess the risk to CUI, being used in that specialized asset? And we just evaluate that to make sure it meets, you know, the intent of what what is required for a specialized asset. As far as security protection assets, we we generally, will ask questions about how, you know, some of the function that are used with that asset to ensure that, you know, it's truly a security protection asset and has no has no contact or interaction with CUI data. So we'll validate that, as a c three PAO. But but for the most part, when we look at the asset list and we look at the scoping documentation that you provided, we'll know exactly, you know, where where certain areas we may wanna query on the security protection assets to make sure they are are truly defined correctly in the scope. So I I. think what I'm hearing is, like, identify them in the asset list. critical. Have an approach defined at least. And then a little bit of auditor discretion as to, like, hey. You said you took this action. Let's say isolate in a logical network segment. Can you at least show me that that isolation works so I can have confidence? And that's probably where it where it lands. Correct. That is correct. Yeah. We'll validate that that the risks have been addressed. Yep. Perfect. Alright. Next slide. So why scoping is often misunderstood? Things that we see on the cyber c when we're trying to lead the compliance journey, jumping into tools and policies first without having those conversations around data, given that it's a data centric framework. Lack of clear CUI data flow mapping. A lot of people struggle with this. I will say it's an industry issue, the the lack of clarity around what CUI is. So you do have to make some assumptions that sounds kind of bad, but, like, do I need to know that that, like, a computer in the environment exchanges CUI with another computer in the environment? No. I think you can take some broad stroke like, yep. We're receiving, CUI by email. We receive it by hand carry thumb drives. We receive it through, I don't know, DOD Safe or prime contractor portal, and then it exists in an enterprise environment if we're talking about an enterprise environment. So understanding those flows is critical in the in scope platforms that we talked about earlier. Leveraging the CMMC scoping guide in your favor, but not overusing it. Talk to me about what overuse might be, Eric, from from your perspective. I've seen clients be like, yep. Security protection asset. Security protection asset. But, you have to do a little bit more than just naming it, as we were alluding to earlier. Correct. Yeah. You wanna you wanna do a sanity check on any and how you how you categorize the asset, wanna do a sanity check on each one of those. First of all, to make sure you don't you know, obviously, you don't wanna label everything as CUI asset. That's that's too much. But you don't wanna under under under report CUI assets, as well. So you do a sanity check to make sure if if something comes into contact, hey. You know, this is we have this security protection asset that's maybe handling our, you know, our user accounts for for the application. It's a database. Does this database come into contact with CUI data? If you get the if the answer is definitely no and and you can confirm that there's no CUI data ever entering the database, then you can probably rest assured that that that database used for for user access management, you know, is is gonna be a security protection asset. So those types of of internal discussions with your technology people, just as one, you know, quick sanity check on on the asset categorization. Fantastic. Just gonna throw an example out there because I've I've heard this a couple of times. Like, my SIM, my my, security information event management platform, like, that's that's capturing CUI. Right? Like, it's not always the case, and it's probably not often the case. Mhmm. But could it happen? What would be circumstances where a SIM might become a a CUI asset? Yeah. I I mean, if it it's if it's capturing, you know, activity, if it's logging activities that that are part of, you know, the services that you're delivering under a contract, you know, that that information or those details could be considered CUI in some cases. So you just gotta understand where, you know, what the data sources are for the SIM and Yep. and understand what what from those data sources, if there's CUI data in those data sources, then it is possible that the SIM could become a CUI asset. So just understanding and that kinda goes back to the the data the data flow mapping. Yeah. Yeah. Absolutely. That'll. Like, if you you. Yeah. I imagine, like, a business application where, like, if you were truly entering CUI details into a business application and the logging for that was integrated with a SIM. and it was captured clear text, like, would obviously be oh, maybe not a problem, but certainly needs to be accounted for and brings your SIM into scope. But in most cases, SIM from a security standpoint is capturing event log data from Windows platforms, but you have to be aware of those fringe situations that could pull your security protection assets into scope. I know the example that you and I were batting back and forth earlier was like a a packet capture platform. Mhmm. They used to be called Witness. I don't know what they call it today. But if you're breaking encryption, capturing packet data, and you move CUI data around, like, something like that could easily become a a a CUI asset versus. a security protection asset. Oh, yeah. Very well. Very yeah. That that definitely could could occur very easily. Yep. Yep. So, understanding those flows is key. And then ultimately, in the end, treating scoping more than just a one time task. I know when it comes to the services that we provide from a compliance services standpoint, You mean the process for us is assess, put a put a client in remediation phase, get them over the finish line from a from a certification standpoint, but that's not the end. On a monthly basis, when we run out of remediation things to talk about or asking, do you have business changes, acquisitions, divestitures that cause chaos and and tend to mess up your boundaries, new technologies, new security controls that we need to account for in documentation, new COI handling use cases, your hand carrying thumb drives now and you weren't before. Like, those are all things that impact scope, boundaries, data flows, and and need to be accounted for on the regular. So, from our side and I'm sure your side as well, Eric, Mhmm. scope is not just one and done. It's managing your scope. Yep. Yeah. And definitely recommend managing it. Obviously, my recommendation is to do it at least monthly so you so you stay on top of it. I know I know most organization have have change. You know, they have change management processes in place, understanding what's happening on the change management base can can assist you in in keeping your scope up to date. Yep. Absolutely. Alright. Next slide. So hidden costs of getting scoping wrong. I know we talked about the point impact and how, like, a platform miss can perpetuate and and cascade through the framework, and you can end up from a one ten score to a negative score pretty quickly. But undefined or over overgrown boundaries, really, your boundaries should be defined through the lens of of how the data moves. So that's certainly a a core aspect of the scoping exercise. Follow the data. That's gonna tell you what, computing assets, what systems, what people touch CUI, and the processes associated with it. So understanding those is key. Mhmm. Including too many systems just to be safe leads to, like and I've heard this before. Let me know if you've heard things like it, Eric. But, like, we just treat everything as CUI. A blanket statement like that means that every email, every bit of information that you put in an in a in a Word document or notepad should be marked as CUI if you're treating it as CUI. It's kind of this blanket statement that doesn't take into account, like, no. You actually have a regulated dataset to protect, and sending memes to your friend over email is not CUI. You see that on your side? Yeah. Yeah. And and and when you when you're you gotta remember every time when you're designating something as CUI, you're you're basically confirming, that that asset is compliant to a 110 all a 110 CMMC controls. So the more obviously, the more controls that you have to be in compliance with, the the greater chance there is there is a noncompliant objective that that makes the that control, not compliant and not met, and could impact the the the overall compliance of your environment. So you you really wanna make sure that you don't overstep the, you know, the CUI designation of a CUI asset. So, clearly, if it's a CUI asset, it it must be processing, storing, or transmitting CUI data. Yep. And anything. outside. of that, it's it's not a CUI asset. Yep. And I think there's a may maybe nuance or, when people say, like, oh, everything's CUI. I I think what they often mean is we are taking an enterprise approach. Mhmm. That doesn't mean, like, label every bit of information CUI. If it's not, that just means, your boundary is the enterprise, understand the flow is related to the enterprise, and understand the in scope platforms related to the enterprise. Mhmm. Because your options are always enterprise enterprise, enclave, or sometimes I think it's program or project specific in SPRS, how they label it. But the most common two are enclave and enterprise. Correct. Alright. Next, next slide. So missed CUI locations, we alluded to this a little bit. Unmapped data repositories. If you're asking the right questions to the right people, you should understand where it comes from, where it lands, and and where it persists. Email, shared drives, collaboration tools, those all all need to be taken into account. Remember, you have the obligation to control the flow of CUI in some way, so you have you have to tell a story around what flow control looks like. I've seen cloud services that exist on end user devices as broadly available, to to staff that are not compliant, not FedRAMP authorized in in alignment with the DFARS requirements and no attempt to even control. But, like, you're on an end user device in an enterprise environment and you have noncompliant cloud services available, you have to do something. Right, Eric? You. at least have to train users to not use those tools and have some defensible positioning. Yeah. You do. Yeah. It it's all about, obviously, training. Right? So you wanna provide training to your employees on on how they how to how they should be working with with the tools that they have, and what the impact is. Obviously, understanding the impact and of handling of CUI is is a big part of the awareness and training within CMMC. So, Yep. that will address those, you know, those concerns. The other thing about, another thing I've seen with with missed CUI locations is, you know, understanding again, it goes back to understanding your business processes, where CUI is involved in the business processes. If you have, somebody who's going on to a construction site and they have a tablet then they have detailed, you know, diagrams and things on it that are are are considered CUI data because maybe they're they're building a facility. You gotta understand, you know, that that endpoint obviously, becomes a CUI asset. So you gotta understand. And then the other area that we see it too is in in paper. Right? You could have, CUI data could be just, you know, printouts, of of of documentation that you that you're using to to deliver the services, that you're contracted to deliver. So keep that in mind. You you could have office spaces that that come into scope as a CUI location, and you don't you certainly don't wanna miss those, in your scoping exercises. Absolutely. Mhmm. And then we kind of alluded to Shadow IT. I gave kind of the the engineering self managed type type of use case in my in my Linux, my my Linux example. So I don't think we need to step too. deep into that. But, ultimately, the the results of of scoping should mitigate, hidden noncompliant risk. So, go through that, institutionalize that process of engaging with your staff, understanding how CUIs handle the in scope platforms. That's really key. Alright. Next slide. CUI misclassification. We talked about this a little bit already, but overlabeling data is obviously, can have impact because you shouldn't be putting CUI labels on things that are not CUI. So that peanut butter spread, everything's CUI, really means enterprise approach, but don't label things that are not CUI unless you have guidance that says that the thing is CUI. Under labeling CUI, if you have instructions to label CUI and you have instructions to continue and perpetuate the labeling of this the CUI from derivative material, you need to follow that. You know, the requirements say label your CUI media. So where the CUI exists, if you're printing it, if you're putting it on a thumb drive, if you have anything that's really detachable or or nonfixed, it should have CUI labeling, and you should follow your, your marking guidelines. If you don't have those guidelines, seek them out. Talk to your contracting official. Get some, get some guidance related to how you should be labeling things that are CUI. The common thing that comes up is, hey. I I have this CUI thing, but if I take this piece out of the CUI document, it's no longer CUI anymore. Right? Well, there's no portion marking requirement for CUI, so you should seek guidance from your customer, around, can I take this out of the CUI document? Is it no longer CUI? Because, ultimately, the data is the cut the end customers. So that's that's not even the prime. That's the end end customers. Somebody on that end, from a data ownership standpoint, should be making the decision if derivative material perpetuates the classification. You can't make that decision yourself. Misunderstanding contract requirements. I think you probably see this in the industry as well, but there's not a lot of clear guidance around what CUI is. Mhmm. I said the word and which sounds bad. But give me your perspective about, like, the issue that that that perpetuates when it comes to the DFAR seventy twelve clause handed down historically and not a lot of guidelines around what CUI is. What's your perspective, Eric? Yeah. I mean, I think I think the you kinda touched on it a little bit is is is making sure that you have, you know, procedure in place of how you're gonna handle CUI, how you're gonna label CUI, and have that documented. And make sure that it aligns with what the contract requires as well. So understanding you know, obviously, talk to your your contracting officer and make sure that you you know, if you have questions, those those questions are answered, and there's no misunderstanding between you and your customer on the on the classification and handling of CUI. Yep. You got it. Alright. Next slide. So overlooking high risk assets, admin systems, privileged accounts, identity access management tools, backup systems, disaster recovery raises a yellow flag for me because sometimes you have a backup utility on end user device. It doesn't come up in scoping, but then you find out you had a cloud service attached to that backup system that now stores CUI certainly impacts the scoping conversation and the DFARS requirements for FedRAMP, but do you see that on the field on your side? Yeah. I I mean, that'll that'll often come up as you know, especially if it's a as an afterthought in scoping. You want you don't wanna have to add that into you know, obviously, document in your asset inventory and then add it to your SSP at the last minute. So, you you wanna make sure that it's it's covered at the beginning. You understand, that you're also managing those systems the in the same way that you're managing the core assets, so that there's no, there's a a continuity between, you know, all of the how how you're implementing those controls across, like, you know, across whether it's your enterprise or your enclave, environment. Yeah. And I'd say, also be aware of software in your environment in general. Mhmm. So a lot of where on an end user device, is cloud connected today. Microsoft three sixty five, it's compliant. It's it's FedRAMP authorized and all that. But it is first software on your system, but connected to cloud services that brings the FedRAMP requirements into play. But you should pay attention to any software that you put on your end user devices. And does it transfer or transmit information to other, cloud services associated with that software? Because, again, back to the backup example, if you have a backup client running on an end user device and it's moving the data to some cloud service, then you have FedRAMP requirements, related to the storage of CUI outside of the asset that you manage. So definitely something to pay attention to when it comes to establishing your scope, but also understanding as your scope changes, as you introduce new utilities, all things that need to be accounted for in your compliance situation. Yep. Yep. And it could be I've seen things, especially in, like, document management packages out there. There's document management software packages out there that will in, you know, will inadvertently back up stuff or, by default, back up things to to cloud locations. Absolutely. So you need to be aware of all those. Alright. Next slide. Ignoring external dependencies, a little bit of a regurgitation from the last slide. So cloud service providers are obviously key. That could. be software with cloud components. But if it's an institutional practice to use, I don't know, box.com for the transmission of of CUI, then those services need to meet the DFARS requirements for FedRAMP. And that means that when you go through a c three p o engagement, the c three p o auditor is gonna ask for things like responsibility matrix matrices. Talk to me about that process, Eric, on your side. I I know it's collected. You guys use those to inform how you assess, but give me the c three, p o perspective on that. Yeah. So so what we what we what we look for is, obviously, you have a you have a third party, you know, external service provider. They provide you with a a a customer responsibility matrix that tells you what, you know, what specific CMMC controls that you're responsible for and which controls they manage on your behalf. You wanna make clear make it very clear within your system security plan, at each control and within each objective, exactly what, you know, you are you're if you're responsible for that control, that you, as the as the, OSC, are actually performing these activities to meet that control objective. If it's inherited, you wanna define that, hey. Our external service provider provides, you know, this, this functionality or these services to meet the objective of the control. If it's clearly defined in the SSP, we look for that first, and then we'll we'll we'll we'll validate against the the customer responsibility matrix that you've documented for that external service provider. As long as the two match up, as long as everything matches up, there there's no issue from the CTO perspective. Makes sense. Yeah. Yeah. We just wanna make sure that it's there's a clear and documented process that's being followed. And and part of that is documenting the SSP at you know, down to the control objective level responsibility and then having the CRM to back up and show that that that is indeed the case. Makes sense. Tell me about managed service providers in this space. You know, we know now based on the rule making, ESPs, external service providers, don't need to be CMMC certified, but, probably helps if it is. CyberSheath is level two certified because our customer base is as well. So, but talk to me about, pitfalls related to managed services service providers, why they should be included in scope, what, how a service provider that's certified is helpful to the assessment process. Yeah. So so if so if you are using a managed service provider, say, they're they're providing security services to you, their MSSP, If if they basically, any of those services then would be would be assessed during your your c three p a audit, regard with respect to the impact or or which controls those services apply to. So if it's if they're providing an SIEM service, then, obviously, the the audit logging, you know, the controls about audit, logging would be evaluated for that service. If that organization is already CMMC certified, so they can provide, they're able to provide some level of of confirmation that how they're meeting those controls that they're responsible for, having their CMMC certification helps to easily it helps the, basically, the c three p o to easily evaluate those controls and and get the understanding and confirmation that those controls are are being met by the MSP. Yeah. And I'll I can give CyberSheets that is as an example doing. IT security services. Like, the IT team engages with client environment. So, if we weren't certified, the CTO goes, we'll pull on that thread. Like, oh, CyberSheath has staff engaging with this environment? Okay. How what are they using? Are they on a CyberSheath asset? Yes. They are. Okay. Well, then that CyberSheath asset may or may not be in scope depending on the discretion of the auditor, but then it's like, are the CyberSheets staff trained on CUI protection? So that threat can be pulled by the auditor unless it's like, hey. CyberSheets been certified at the enterprise level, so we're we're eating our own dog food when. it comes to supporting clients. Yep. But if you're not if you don't have a serve service provider that's certified, that thread can be pulled. The nature of the engagement needs to be well understood. And if there is a lot of direct interfacing or operational support, then that thread usually gets pulled pretty in a lot of depth. Okay. Well, let's move along to the next slide because I know we got about fourteen minutes left and a handful of slides to go. But building defensible scope, how assessors review your scope, evidence of documented scoping decisions. I think what I've heard so far from you, Eric, is the evidence really should start with the system security plan, boundary definitions, data flow definitions, some process on around institutionalizing how you maintain your scope. Data flow diagrams are more than just network diagrams. So you can have a net great network diagram, and I've seen them in in system security plans. But if they don't tell the story of how data moves across that network, then we're we're missing a key component given given this is a data centric framework. Yeah. Correct? Yeah. Correct. And and don't don't feel bad if you have to generate many, many data flow diagrams based on the same network diagram. I I I I I never mind seeing more, you know, more detail rather than less. Right? So if you have 15 separate data flow diagrams to make sure that you cover all all of your your CUI data flows, that's perfectly acceptable. And it paints a clear picture that you that you definitely understand the data flow and you've justified how you've how you've set up your boundary. Absolutely. Alright. Let's, anything else on this one that we wanna cover? Asset inventories, we covered how. it aligns with the scope scoping categories. CMMC scoping guideline gives you those four categories to work with and what that means from both a preparation side and and a CMMC c three zero assessment readiness side. Justification for inclusions and exclusions, this is just leveraging the scoping guide in your favor and. making sure that you're not exceeding the boundaries of the definitions. Yep. You do doing those sanity checks to make sure you've. done it correctly. Yeah. You can't hand wave yourself and just say, Mhmm. hey. This looks specialized. It should actually meet the definition of specialized assets, to fall into that category, and your positioning should be well documented and defensible. And then consistent consistency across your SSP and policies is key. Correct. It all needs to tie together. Scope, in scope assets, implemented controls, all backed up with evidence that can show what you're doing. Evidence collection should be an institutionalized process if you wanna have high confidence in what you're doing. But from a c three p o standpoint, you're gonna have to stage evidence anyways because you you have an evidence package that you need to attest to and associate with your assessment. Right? Mhmm. That is correct. Alright. Alright. Great. Well, let's move along. Rightsizing your CUI boundary, start with your confirmed CUI locations, and I I gave you a sense of how how we typically handle it at CyberSheath. Like, follow follow the path, and it's not just an IT path. Precontract, during, contracted engagements with the DOD, and then where does the data land? What are the in scope platforms? What are the in scope, staff and persons touching that information? And then, ultimately, where does it go? Also, consider you have a DFARS requirement to flow down the requirements where you have third parties, like, subcontract relationships. So understanding that flow is important to get to that as well where it's I have an obligation. If I share this information to a subcontractor, that subcontractor also needs to be obligated to implement the controls just like you. So institutionalizing that to meet those requirements is critical. But avoid, in the end, any default, everything in is in scope decisions because that's different than just than than an enterprise scope and solve solving for CMMC in an m through an enterprise lens. Everything can't be CUI. The things that are CUI are what the government says is CUI. So just avoid overclassifying and then and ultimately overcomplicating your compliance journey. Yeah. Alright. Next slide. So practical scoping techniques. I walked through my structured review. From your side, Eric, sounds like you need you you are obligated as a c three p o to at least validate the scoping, understand the the assets and how things meet the asset categories, and then spot checking or sanity checking what they actually document as their approach to mitigate risk for non CUI assets. Do. I have that about right? That is correct. I mean, you like, we we go back to the scoping documentation. So we look at the asset inventory. We look at the the SSP and and, obviously, the data flow. So if if I look at a data flow and I I I see all the CUI assets are in the data flow and the data flows through them, it's processed by them, that that validation is very easy. If I have to start asking questions and things that are vague, that's where, you know, that's where things may you need that's that's where you may have some some struggles. So you wanna make sure that's why the the importance of the documentation, in your scoping documentation is so critical. Yep. And then other things that we've that we've covered in this presentation, interview system owners and process. leads. That means not just the IT people, but the people who actually, handle the CUI know it best. Validate your findings related to scoping, not with not just with technical scans. That could be part of it. But if you are defining approach, a a risk mitigation approach as network isolation or something else, make sure that your position positioning is documented and defensible. Defensible means you can show that the risk mitigation things that you've put in place are verifiable, that evidence can be gathered. Things like Eric and and myself would look for to say, This this pass this passes the SNF test. They're doing what they say they're doing. Yep. And then document assumptions and decisions. Like, you can document that it is an assumption that this piece of manufacturing equipment falls within the asset the specialized asset category for this reason. So just tracing back to the the gift that is the CMMC scoping guideline and avoiding questions around, like, why do you think this is a specialized asset? Understand it yourself before you go and take it in front of a c three p o for a certification attempt is is certainly gonna be be key, and it demonstrates maturity if you've thoughtfully documented ahead of time. Alright. Next slide. So kind of a mid wrap up slide around aligning scope with the CMMC two point o expectations, but we talked about starting great starting point. Follow the official CMMC scoping guide on guidance. Maintaining traceability between COI and assets, that's all back to that process. Understand how it flows, who touches it, and what's what's related to it. Keep your scoping documentation current. So institutionalize the process. It shouldn't be one and done. You don't wanna have, you don't wanna leave your scope alone if you've gone through three mergers, acquisitions. You divested a company. That causes a lot of chaos and complexity that you need to account for often modifying your boundaries. So make it a practice to maintain your scope and maintain your SSP to be accurate, and then prepare assessor ready ready evidence. So document your approach, but also know that, if you don't do if you don't do what you say you're going to do, then an auditor can step into that. Example I'll give, if your approach to mitigating risk is idle isolating with a network segment, Make sure that network segment is actually controlling flow, that you have a firewall in between or ACLs in between that actually do the flow control. Sometimes VLANs are just VLANs by name, and they aren't doing flow control, and that's not really separation at all. So just be aware. I'm sure you see things like that too as, as well, Eric. But, VLANs do not automatically mean segmentation. Yeah. Flow control is what means segmentation. Correct. And you wanna validate that that flow control is working because the the assessor may ask you to show proof that it's working. So. Yeah. And not always. They should, yeah. but not always. So, best to be prepared than. leaving it up to chance. Just in case. Yep. Alright. Next slide. So just what good scoping looks like in practice. This happens in in in a lot of occasions with CyberSheath clients and and navigating change. And, again, we ask these questions around organizational changes, technology changes, CUI use case and handling changes. Some clients go down this path of, yep. I think I need an Enclave, and I think that works for me. And then they realize they're trying to operate in the Enclave. They find out other people are touching CUI. They they they find out that things are changing in how they interface. We have several examples and and use cases and case studies around the change that happens when the business changes. We've had some go from a what was an organizational approach in a very small CUI footprint to and and trying to not use GCC High services to suddenly the army raising their hand and saying, hey. We wanna directly collaborate. You need, Microsoft three sixty five GCC High to accomplish this. And then a change in situation goes from an enterprise solve solution to an enclave solution because they needed the cloud services to support it or vice versa. Start off with a with an enclave and realize you have to operate in this enclave, this VDI experience, but we need to hand carry media. We need to print media. The enclave can, in some ways, break down if you have to handle tangible media. But this stuff happens quite a bit as companies grow and expand in the defense industrial base. Just be aware that as these changes happen, account for them, manage scoping because managing scoping is the key to, one, setting yourself up for certification success, but also being well prepared and mature in case you have a DCMA DIBCAC audit that is going to be less of a planned activity and more of a show up at the door, let's see what you're doing, type of situation. Yep. Next slide. Alright. So key takeaways. Eric, would love your perspective on on key takeaways, next steps for our viewers. Yeah. As we mentioned earlier, obviously, you definitely wanna start by going over your your your asset inventory. Right? What's the what are what are what are the what are the CUI assets that I have? Making sure that you clearly, that the accuracy of the categorizations that you're making in your asset inventory. You also wanna validate your obviously, the the the system and asset mapping and and also how you've documented them in your data flow diagrams, your boundary diagram that goes in the SSP. You wanna validate the accuracy of of where of where they are in in the, enterprise or enclave, however you've designed your your architecture. And then, obviously, you wanna make sure that you have the appropriate scoping. Right? Have you made all have you have you chosen the the correct decisions, to include, certain assets in scope, physical locations in scope, make sure those decisions are are accurate. And then the last thing and probably the biggest one is is engage all the stakeholders early. So the the more people you have involved at the beginning of your scoping journey, the more accurate the the final product will be and the easier it will be to get through through your CMMC, certification. Absolutely. Alright. Well, great. Mhmm. This leaves us with about a minute and a half to answer questions. I'm gonna try to go through them pretty quick since we. are short on time. Our first question was, what does it mean to be in scope? Anything that touches CUI from Paul Van Dyke. Paul, I suggest reviewing the CMMC level two scoping guideline because that defines the asset categories. CUI assets are those that store, process, transmit CUI and need to meet all NIST eight hundred one seventy one requirements. Specialized assets are those that can store process transmit CUI but offer some flexibility, meaning that document your compensating controls and how you mitigate the risk for these those that meet the specialized asset category. So doesn't need to meet need to meet all the requirements, but you do need to at least mitigate the risks related to the requirements that can't be met for things like manufacturing equipment. The other two asset categories are out of scope. You've you've isolated them enough to be out of the equation. And then security protection assets, which are the tools that provide security control function, those are also supposed to meet NIST eight hundred one seventy one, but within reason. Right? Like, your antivirus software doesn't actually engage with CUI. It's not storing CUI. So, like, do the staff on the end of that service, like, need to not have CUI training? So but reasonably document what NIST eight hundred one seventy one requirements are meant when it comes to those tools and their applicability. As it relates to the rest of the another one from Paul, do we include network switches locally if everything is located in the cloud and people access CUI over work, personnel, hotel networks, especially the ones that have no knowledge of any network equipment. It depends. You have the ability to leverage physical security in your favor, so I would account for them as an asset Where things when it comes to networking equipment, where where control begins begins to be applied is remote access services. So if you have VPN off off of a firewall, it needs FIPS validation. So those should be accounted for from a data flow standpoint. Switching and networking should at least exist as assets in the environment. They don't store CUI, but they do process, so account for that in how you narrate your controls. David Blackburn, is it not incorrect to label data as CUI if it might not be CUI? Your contracts should give you clear guidance as to what CUI is. And if they don't, I would suggest getting that clarity. Otherwise, your sources are marked material, and I would say you are marking in a court carrying on that classification if you are deriving things from the marked material. But in the end, source of truth is gonna be your your contracting official or the contract itself. And that takes us to the top of the hour. I know I have have a handful of questions that I haven't got to, but really appreciate everybody's time. I know, again, there's a lot of information out there in the in the CMMC echo chamber. So glad you chose us, for a source of information. And if you have any follow-up questions, you can certainly reach out to me or or Eric. Yeah. Either. or they here to help. And LinkedIn is always a a source to get us both directly. Eric, appreciate your time. Any final final comments before we wrap up? No, I appreciate everybody's attendance. And, hopefully, we were able to shed some light on on the best approach to use for for scoping, scoping your environment and and your whether it's enterprise, Enclave, or or some hybrid, getting getting ready for for your CMMC certification and compliance. Terrific. Alright, Alright. Eric. Appreciate your time, Thank appreciate. everybody who joined us. Thanks, Thanks, everyone. everybody. Bye.