Name: CMMC Scoping: Demystifying the First Step to CMMC Certification
Uploaded: 2025-10-09T17:16:03.275Z
Duration: 31 min 4 s
Description: CMMC Scoping: Demystifying the First Step to CMMC Certification

Transcript for "CMMC Scoping: Demystifying the First Step to CMMC Certification": Alright. Well, without further ado, everyone, thank you for joining me, and welcome to the first part of our four part CMMC webinar series where we'll be going over the all important topic of CMMC scope. My name is Marc Rubbinaccio. I've been here at Secureframe for about four and a half years now, and I have over ten years of experience in cybersecurity compliance. At Secureframe, I was responsible for our level two CMMC certification where we passed with a score of one ten out of one ten. And I also lead our product direction for supporting our CMMC and federal customers. Through this series, I I really hope I can provide the community with some actionable insights and guidance, specifically based on what I learned through our process and then also working with our c through d o and RPO partners. Before we begin, I just wanna preface by saying, like, we're not covering the absolute basics here. Like, what is CMMC? What are the timelines? All that stuff. If you'd like to know more information about those absolute basics, feel free to reach out to me after the webinar and we can schedule some time and I'll send you some more information on that. So let's get started. Alright. What is CMMC scoping and why is it so important? Understanding your scope is the key to beginning your journey towards CMMC compliance and is really a prerequisite. Before you actually begin implementing controls and writing policies, it's critical to understand what systems, people, processes you actually need to be included. Overall, it's identifying your assets, which includes data and the systems that touch that data. People, vendors, service providers, all of those things that can impact the security of that data and provide a security function that supports the protection of that data. Scoping will set up the boundaries of what's needed to be included in the control implementation when it comes to your CMMC compliance. Scoping is important because it allows you to carve out systems and processes that may not be needed to be included, But more importantly, it's the framework for determining exactly what does need to be included in your preparation towards CMMC. So we won't be diving too deep on the differences between the CMMC levels. So definitely let me know if you have questions about the specific CMMC levels. But it is important to cover when talking about data. The first question you need to ask yourself is what type of data are you handling? If you're handling CUI or controlled unclassified information, then you know you need to meet CMMC level two or three depending on solicitation. What we are gonna talk about a lot today are assets. So let's break that down a bit. Assets can be infrastructure such as networks, servers, workstations, databases. An asset could also be the applications your services are running on which process the data that you need to protect. Assets could be the logging and monitoring tools, vulnerability scanning services, or the security operation center MSP that you rely on to monitor your environment for instance. Generally, an asset could be a system, device, application, service, component, any of those things as long as it's within your environment. Now breaking down the levels a little bit. Level one only cares about FCI or federal contract information and specifically those assets and systems that store, process, or transmit FCI. Level two is where assets become more complex. Breaking them down into multiple categories, which we'll cover in a bit. And level three is more strict, merging what's called CRMA into the definition of a CUI asset, which we'll also break down a bit later as well. So here are the different asset categories that I just hinted about. I'm specifying level two because in level one and level three, some of these asset categories either don't exist or they're completely merged together. These categories all need to be handled differently in relation to your CMMC assessment, which is where it gets complex but necessary to understand the nuances. CUI assets are simply the assets that store, process, and transmit controlled unclassified information. These assets require the highest level of protection and must be assessed against all of the NIST eight hundred one hundred and seventy one requirements. When considering the applicability of a requirement against your environment, all of these assets must be included in that discussion. Security protection assets are those which provide security functions or capabilities within your assessment boundary. We'll dive into detail on the next slides, but for now these assets are assessed against the 871 requirements, which are relevant only to the capabilities that those assets provide. So for example, if you have a SIM service, you would be verifying it meets the requirements against generating and retaining audit logs, analyzing those logs, alerting, etcetera. Any requirements that would apply to the function of that SPA. Contractor risk managed assets are assets within the boundary that could process store transmit CUI, but do not. It must be documented in policy, asset inventory, even risk assessed to determine exactly what these assets are meant to do and how there are security controls to ensure that CUI is not stored, processed, or transmitted on these devices. They will not get assessed against the eight hundred one seventy one requirements if properly documented. The auditor could do a spot check if those documentations do have gaps. Specialized assets have a few different categories which we'll skim later, but ultimately wrap up into systems in which you do not have much control over. Either they are preconfigured by the government themselves or they are necessary IoT devices within your boundary that perform a limited function. As long as you're maintaining these devices based on the vendor specifications and then documenting all of that properly within policy and asset inventory, these will not be tested against the eight hundred one seventy one controls. And out of scope assets, pretty self explanatory. These devices are physically or logically isolated from your boundary. And we'll cover why this is important on this slide. Okay. So at this point, you should have a understanding of the different asset categories and how they're they're quite different. So let's dive into how to discover these assets and then determine what should be in scope starting with CUI assets. The easiest way to determine what are CUI assets is by following the data. How is CUI initially ingested? Is it ingested via email, file transfer? Is this file transfer through a server that's hosted by you, or is it hosted by a third party? And then as you follow that data, where exactly is the data processed and then stored? Is it stored in a file system, database, or a bunch of employee laptops? Are you then printing this data? And if so, how is it deleted? These questions are meant to get you to follow that data, and you can pretty accurately then determine that any asset which is a part of this process is likely considered a CUI asset. Next is determining your SPAs or security protection assets. Like I mentioned before, these assets are those which provide security services. Examples could be technology, such as your hosted or managed infrastructure, like firewalls and VPNs. They could be service providers such as those providing penetration testing services, or MSPs, which are managing your incident response processes, and then any facilities that are considered in scope. Could be your office building or your data center. And we previously discussed, like, the nuances of the contractor risk managed assets. These can be found out by determining which assets exist in the boundary yet are not exactly part of that CUI flow or do not provide any security functions. Examples could be other file systems and databases that store corporate or customer data and devices such as workstations or phones that connect to email and systems that don't process UI. And then lastly, specialized assets are the ones we talked about a bit where you might not have that much control over. Here are the different categories and the examples. Assets that are directly provided by the government require specific software configurations, maybe those can't be changed, or operational technology and IoT devices that are required for operations and within the boundary, but don't really meet the definition of of the other asset categories. Now let's talk about out of scope systems. These are systems considered out of scope are those that are physically or logically isolated from your assessment boundary or do not provide any services that support your in scope systems or environment. These systems also fall into they they do not fall into any other of the categories that we talked about. An important consideration is whether or not to build this isolation into your environment. If you have assets that sit in your assessment boundary, they could be considered in scope for review. So it helps to really carve out only the systems you need to support the CUI environment. An example of segmentation could be the use of a virtual desktop environment. Using a VDI when accessing your CUI instead of directly accessing CUI via workstations. This allows you to build security controls around that VDI instead of having to manage those controls against your entire fleet of workstations within your environment. Another option could be using an enclave solution, which is another word for an isolated managed system that handles the transmission and storage of CUI. So this data never has to enter your commercial environment, and you would only need to focus your efforts on this enclave. This is typically the cheapest and most effective way to meet CMMC requirements if feasible. K. Now that we've covered all the asset types, different scopes, how to properly scope your environment, let's talk about some mistakes that that could occur and and how to avoid them. So we we talked about using an enclave or isolating commercial systems. If you're scoping in too much, you will only be spending more money and time on achieving CMMC. It's important to verify if segmentation and isolation is an option for your non CMMC systems. Under scoping and misclassifying is a surefire way to not make it through the first phase of an assessment. If you're classifying systems as out of scope, but they're really an SPA, you will not be implementing the right controls and this will be called out during the audit. Scoping accurately is critical to preparing in the most efficient and affordable way. Poor documentation could also be an issue. Documentation is one of the most important aspects of CMMC. CRMA and specialized assets need full supporting documentation to ensure you're handling these assets correctly and to provide the auditor assurance that you're doing so. Without this, these assets could be tested against the eight hundred one seventy one requirements, which would impact your ability to achieve CMMC. External service providers could very well be in scope also depending on the services that they are providing. And if they're cloud service providers that process, transmit, store CUI, it's critical to verify that they're FedRAMP Moderate authorized or they've been attested against the three PAO against FedRAMP Moderate Equivalency. Lastly is to continue monitoring your environment for scope changes and ensure this stays documented throughout the year. Continuous monitoring of your environment is important to make sure that systems and services do not creep into or out of scope without your proper documentation and assessment against the control objectives, keeping you CMMC compliant throughout the year. So how can Secureframe simplify this process? So Secureframe, we are a continuous monitoring GRC platform with features that help organizations prepare for CMMC and also allow MSPs to support their customers CMMC journey in the most efficient way possible. Organizations use our features and functions such as SSP workflow, risk register, policies, and integrations to focus on the specific tasks that are required for CMMC compliance without the need to read NIST eight hundred one seventy one from top to bottom. We also have RPO and c three PAO partners that we work with to ensure you have the right people in your corner every step of the way. So that was CMMC part one scope. Please feel free to join me in our next series, part two, where we'll go over readiness, we'll go over how to perform a proper gap assessment, developing your SSP and documentation, and then ensuring all of your controls are properly in place. I I know this one was pretty quick. I think, we covered the overview of what is important for scoping. We covered what is an asset, what asset categories could the they fall into, which asset categories are applicable for each level of CMMC compliance. Even though I chatted about it for about fifteen minutes, they go into a lot more detail, these asset categories. And sometimes, it's hard to distinguish one asset category between another. I know for our CMMC assessment, that was one thing that we really ran into an issue with. When we thought we understood what asset categories some of our systems and services were, after we got information from an RPO, they would tell us that maybe we were wrong. We needed to rescope these assets into different categories, and that affected our way to to kind of move forward in preparation. We thought we were meeting the right controls for these assets, but in reality, we weren't. So there is a lot of documentation online related to scoping your CMMC assessment and your assets properly. There's a scoping guide for each level specifically, a level one, level two, level three scoping guide, and then there's also, the final ruling which has a lot of information related to scoping as well. If you'd like any of these references, you can you can Google them or you can reach out to me directly and I'll I'll send you the link to all of the information. Another thing that really helped us as we were scoping our environment was getting more than one opinion. Reaching out, we had we had one partner through the readiness process, but I also had some friends in the industry as well. And anytime we kind of conflicted with our partner, I would reach out to some of my CMMC buddies and just get a second opinion in regards to the scope. It's it kind of clearly defined in the rule, but it's still up for interpretation. So I would highly recommend before anybody really jumps into CMMC readiness is to read through that scoping guidance. Really make sure you understand it. Work with a partner when it comes to, taking a look at your assets and determining exactly what category they should fit in. And I know we talked about documentation. Incredibly important. Making sure that all of your assets are inventoried, making sure that the documentation supports exactly what those assets are used for and why is is gonna be incredibly helpful when it comes to determining what category those assets fit. So, if anybody has any questions, feel free to shoot them in the chat. It looks like I have one question here. What are the most common misconceptions organizations have when beginning their CMMC? That's a really good question. I think there are, plenty of misconceptions, but one of them being that, it's it's going to be simple or it's gonna be very similar to maybe an assessment that they've gone through in the past, like SOC two or ISO 27,001 or PCI DSS or any of these other regulatory frameworks. CMMC is incredibly unique in the way that you need to handle the assets and the scoping and the determination of of what is considered CUI, what's considered an SPA, what's considered a CRMA. All these things are incredibly unique to CMMC and require some specialized knowledge to really understand. If you've done something like soft two or ISO 27,001 before, you understand the concepts of, you know, documentation, risk management, vulnerability management. A lot of these controls do map over to NIST eight hundred one seventy one, but the biggest difference is understanding exactly what those controls apply to. It's gonna be quite different for CMMC versus something like PCI or ISO 27,001. So even if you do have experience with some of those other frameworks, I would highly recommend reaching out to an RPO or somebody with experience to kind of under to go through your environment specifically and determine exactly what the differences are in relation to your SOC two, scope versus your CMMC scope. Another thing with CMMC is it's specifically related to the data that you're handling. Right? CUI or FCI. And that's where, like, enclaves and and that that sort of technology really comes in, and it could be a a huge benefit. If you do not already have a a, like, an environment that you need to be CMMC compliant, let's say you're just receiving CUI via email and you're printing that data or whatever the case may be, you could likely, instead of doing it the way that you're doing it now, look into an enclave enclave or a technology solution to carve out all the commercial environment and then really just, like, use a managed service to handle your CUI. That way, you're not trying to get your entire environment, NIST eight hundred one seventy one compliant. Dan, I'll go ahead and I'll send you all the information in relation to, the, the scoping information, level one, two, and three. Okay. It looks like we've got a few more questions. What is CUI? Controlled unclassified information. That's correct. So basically, if you're not sure what is CUI and what is not CUI, it's it's likely gonna be labeled as CUI. So if you are a contractor or subcontractor, you're working with an organization that is likely sending you what is what is labeled CUI. If you're not sure exactly what that is, I would reach out to, your point of contact and then just verify exactly what information you're processing or handling, is considered CUI. That way you are handling it properly. That's the the first thing that you should do. Determine what is the data you need to protect. Is it only FCI? Is it CUI? If you're not sure what is CUI, then I'll be reaching out to your your primes, or, you know, whoever is kind of, weighing down the the requirements for CMMC. Slides, we will send those out. Let me see. We'll we'll send all the links and everything, the registration. I'd love for everybody to join me for the, for the next call as well. If we use a if we use a no FedRAMP Cloud tool, which does not hold or process CY but is accessed within. It's a that's a a great question, and very nuanced and something that I I would not give you a yes or no on the call today. It's really important to understand how your cloud services interact with your CUI environment. If you look at the scoping guide, it's gonna be any service that processes, stores, transmits CUI is considered a CUI asset. Those cloud services need to be FedRAMP moderate authorized or, FedRAMP moderate equivalent. We can talk about your specific scope in a little bit more detail. If you wanna reach out to us via email, I'd be happy to have that conversation. Hard to determine exactly based on, the single, statement you provided in the chat. Cool. Any other questions, comments? We have we still have five minutes left. Matt, that's a very good question. Is FedRAMP 20 x moderate ATO recognized as equivalents? That's something I, do not know a 100% for sure. The one thing that I do kind of understand is FedRAMP is looking to, looking to use FedRAMP 20 x moderate to, kind of be at the same level as FedRAMP moderate as it is today. And I believe there were talks of FedRAMP moderate eventually getting phased out, like, in the future. All of this is based on chats that I've heard, nothing really on paper. So, I wouldn't take my word for it. I would, I would keep up with, with Pete and the the FedRAMP twenty x team on how things are going, with that process. I'm I'm a and, like, you know, the CMMC, FedRAMP moderate equivalency, like, that's specifically, like, a cyber a b thing. So, like, whether or not they will consider 20 x to be equivalent, I think is up to them. So I'm I'm not positive on that one. That's something I'd like to to know as well. CyberV yet no clue. Yeah. I'm not surprised. Federal Aviation twenty eighth monitor is the only starting pilot. The road map doesn't have it being formalized until middle of next year. That is true as well, Andrew. And who knows with, like, the shutdowns and stuff, like, if that's even gonna be more delayed. Hopefully not. It would be great to see, the pilot get kicked off and, we learn a lot about that because, FedRAMP is really I I I love what they're doing, you know, embracing automation, embracing technology, something that I think other industries and and regulation should be doing as well. It's great that they're leading the charge on that, so really wanna see, what happens there. What practical steps should organizations take before starting formal scoping to avoid costly mistakes? Yeah. Yeah. That's a really good question. I think the most important thing is really, determining, you know, what first, what is the the data you're looking to protect And then understanding the flow of that data, what systems, services, external service providers, all impact that flow of that data. Documenting all that information, creating, like, a detailed asset inventory, determining exactly what those assets do. I think documenting your entire environment and whether you think those systems are out of scope, in scope doesn't matter. I would have all of that information documented and then reach out to an expert. Reach out to an RPO that that understands CMMC. That way you have even if, you know, even if you're a CMMC expert, it's important to to get a second opinion, third opinion on some of this stuff. You're gonna save a lot of time and money if you go into the audit really confident that you've scoped everything out properly. One thing that, you know, I have a I have a lot of compliance experience. I used to be a PCI QSA for years, and CMMC was something that I thought I could just, you know, read the scoping guidance, understand it, and I'd be good to go. But when it came to our scoping, we also ran into a lot of hurdles where, I was overconfident. And it was really important for us to bring in partners that have worked with other organizations and understood the nuances of the scoping to really make sure, we had everything ready to go before our audit. So that's that's kinda what I would recommend. What strategies can organizations use to minimize scope without compromising compliance? We chatted a little bit about, enclaves and segmentation. Something that you'll read a lot that it's it's not required. You don't need to segment or isolate, things, but, those are are different ways that you could kind of, carve out some of those systems and services that are that are not required for CY protection or CMMC. And, that could, that could be a way to kind of minimize scope without compromising compliance. We're out of time. It's been great chatting with everybody. I know I kind of ran through it on this part one. Part two, there's gonna be more content. So really hope you all will join us. If you have any other questions, feel free to shoot me an email. In the meantime, register for the next one and we'll talk in two weeks. Thanks, everybody.