How to Create a System Security Plan for CMMC Level 2

[00:00:01] Hello Climbers and welcome to Season 3 of Climbing Mount CMMC. Hello Climbers and welcome back to another episode of Climbing Mount CMMC. My name is Kaylee Floyd and this I have with me today is not Bobby Guerra, it actually is Adam Evans. Adam, thank you for joining me today.

[00:00:27] I am very excited because Adam is somebody that knows a lot about system security plans and that is what we are going to talk about today. So Bobby also knows about it too but he's out of town so we get to do this one by ourselves. So what can I say? So that means that this one is going to be two and a half hour long episodes so be prepared. I'm just kidding. No, actually it's probably going to be shorter without Bobby honestly, right? Yes, but can we have, you know, Mom, can we have Bobby?

[00:00:57] No, we have off-brand Bobby. No, we have off-brand Bobby. Don't worry. No, we are today we're going to be talking about system security plans and we like to talk about the implementation. Not just exactly what a system security plan is but how do you get started with creating one? If you don't know what it is, we're going to share with you guys today what a system security plan is, what is needed inside of it when it comes to CMMC level 2 compliance

[00:01:24] and we're going to talk about some of the things that we learned when creating ours, when creating templates for clients and whatnot. So we're excited. We're going to get into it today. Let's start by talking about what the heck is a system security plan. So Adam, you want to go ahead and tell the folks that might not know in the back what a system security plan is? Yeah. So in short, a system security plan is kind of a summary of your organization's security posture for a specific set of systems

[00:01:51] and how it aligns to a given security standard. In the context of CMMC, that is a description of your CMMC environment with the applicable security controls from NIST 800-171 and how you meet those controls and objectives. You could do a system security plan for something like the CIS controls or PCI DSS or any other framework that comes to mind. And depending on your organization, if you're a really large organization,

[00:02:21] you might have multiple system security plans. Maybe one, thinking of MSPs and whatnot, maybe you have one for a CMMC enclave. Maybe you have another one for your environment that doesn't support CMMC customers but support other ones. And maybe you have an internal one for your internal systems like your HR, finance, etc. But that will vary based on the company. The main thing with CMMC is you need to have a system security plan. If you do not have a system security plan, you will not be assessed. Your assessors will ask for your system security plan.

[00:02:50] You'll say, I don't have one, and they'll go, great conversation. We're done here. Bye-bye. Come back when you have one. Yes, that's exactly right. And so, yeah, that's a great explanation of it. And, you know, just like Adam said, NIST 800-171, we are going to be going over a SSP should directly talk to each one of the controls,

[00:03:15] the 110 controls, as well as the 320 assessment objectives, right? So that's kind of a lot of stuff to talk about. But I would love to get your opinion on after creating one fully, how do you even get started? Like, so, you know, if those of you who aren't familiar with NIST 800-171 and the controls that come with CMMC, there are different groups, right?

[00:03:43] You've got access control and, you know, assessments and training. You've got these different groups. Is there a way that you tackle starting and building a system security plan? Do you just start from top to bottom? You know, like, tell me a little bit about the secret sauce of it, I guess. I mean, you know, the big caveat here is your mileage may vary. Every organization is going to be slightly different. But let's say you've been tasked with writing one, and you have absolutely nothing at all.

[00:04:10] You open up Microsoft Word, you change the document name to system security plan, and you go, now what? Okay, I like it. First off, NIST does publish a system security plan template that you can use. It's free. It's publicly accessible. It's already designed around 171 Rev 2. It's all right, in my opinion. It's certainly better than nothing, and it's a good starting point. It's one of those resources that's great to have, but there's better.

[00:04:40] Mm-hmm. What we did, and what I would recommend if it's possible, is find a good consultant out there that offers some documentation available for you, because they've probably already got it started. Right. That certainly has helped propel our journey forward and helped move things a little bit faster by calling out key things, some of those gotchas there. And it's been really worth it, because at the end of the day, our system security plan is 217 pages long. A nice book. That's a lot. A nice novella. Yes.

[00:05:10] So having someone that's already able to come in and pre-fill some of that and have some of that ready to go is a huge help. But let's say you don't have that at all. Maybe your organization doesn't have the funding available for it, because let's face it, there is no – none of the Cs in CMMC stands for cheap. We all wish it did, but it doesn't. Right. It actually stands for costly. We need to get that on a T-shirt, by the way. I say that enough. It actually stands for costly. That's what I've learned. Yeah. The costly maturity model certification.

[00:05:40] Anyway, so all that being said, say your organization is not able to allocate any funding for any of that stuff. Let's be real. It happens. And you're still wondering, where do I even begin? A lot of organizations working in the CMMC ecosystem are using a cloud service provider. Microsoft, Amazon, someone that's already out there that's done something. And one of the requirements of FedRAMP is a system security plan.

[00:06:04] And it's your responsibility as a customer of that CSP to validate their security requirements to understand your responsibilities and obligations so you can implement them appropriately. Which means they've given you a system security plan. And I'm a big fan of imitations of the most sincere form of flattery. Copy it. Look it over. The big caveat there, of course, they're aligned to 853 under their FedRAMP controls, so there are going to be some very key differences when you get into those requirements. Yeah.

[00:06:33] But it really helps paint that picture of what does a decent system security plan look like. Yeah. Well, that's really interesting that you say it in that way because I've actually never heard you say that. But NIST 800-171 is a tailored version of the controls in 53, right? So 853 would be actually a pretty interesting place to start because technically if you followed all of those controls in there, you'd be overprepared for something.

[00:07:00] Yeah, because I'm sure Bobby talked about this in our episode with Dr. Ron Ross, which if you haven't seen that episode, go check it out. It's really cool. Ron Ross is fantastic. And a little bit bummed as of recording right now, he has officially retired from NIST to move on to bigger and better things and everything. Well worth it. But anyway, when they were tailoring for CMMC in 800-171, the concern was the confidentiality of controlled unclassified information.

[00:07:27] Remember, our three pillars of information security are confidentiality, availability, and integrity. So 853 includes those integrity pieces and those availability pieces, which is why CMMC doesn't require backups. But if you have them, you have to protect them against unauthorized disclosure. Yep. So a little cheat in that approach. That was really interesting when I found that out the first time. And I think credit to Jacob Horn over at Summit 7 with his… I was just about to say that. Yeah, with his history of CMMC video he's had out for a while.

[00:07:57] Mm-hmm. Mm-hmm. Yeah, that's a great point. But yeah, anyway, so yeah, the parallels between FedRAMP and CMMC are definitely there, given that we're looking at a subset of stuff, which is why they call back so well. Mm-hmm. But again, when you look over a system security plan from Microsoft or Amazon or whatever, you start seeing that common structure out there. And I think that kind of segues us into something that we wanted to talk about was our critical sections of that. Yep. Like what needs to be called out in a system security plan?

[00:08:27] So first off, again, our system security plan is huge. Our first section is simply who are we as a company? What's our legal name? Who are our key people involved? What are our key contracts that require security protections? And what kind of, you know, CUI protections do we have to have in place? Mm-hmm. Just a real quick overview of the organization. Section two, this is how we describe our organization's technology environment.

[00:08:55] It calls out some of our data flows, our authentication flows. What servers we have in scope? How are those configured roughly? Like what baselines are we calling in there? Do we have mobile devices and how are those handled? What about printers, external service providers, cloud service providers? Mm-hmm. That's where we call out that we use Microsoft and they've got a FedRAMP IATO. Or we use AWS and they've got their FedRAMP IATO. We keep listing all that out. Yeah. And that's just to give the assessor that idea of here's what I'm here to look over. Here's the scope of my assessment.

[00:09:25] When we went through our assessment, phase one of that was simply what are we assessing? What's the technology scope? Who are our key people? Who am I talking to in the assessment? So having that clearly detailed and documented is fantastic. Yeah. Keep in mind, you don't have to go absolutely crazy with it. Mm-hmm. It should be pretty distinct and to the point. You know, if you're listing printers, you'll want to describe your printer protection strategy. Are you doing any kind of printing of CUI on those?

[00:09:52] If you are, how are you implementing the requirements on those as a CUI asset? Yeah. But if you're not printing, I think our statement is simply, since we don't allow printing from our enclave, is this is not in scope. Yeah. We do not allow this. Period. Moving on. Yeah. So there's not a required word count is what you're trying to say. If you don't have to deal with the, you know, printer printing CUI situation, you don't have to go in depth for a whole paragraph about printing CUI. Right.

[00:10:21] And remember, it's a summary. Mm-hmm. You know, when I just described out our server environment or our workstation environments, I didn't list every single piece of software installed or every single patch or every single maintenance procedure. I said, we use Windows. It is this version. This procedure is used to maintain it, link to procedure. General summary of what we do on this system. Period. Moving on. Yeah. Hmm.

[00:10:46] Um, I think our entire section for workstations didn't go over half a page, including the headers. Mm-hmm. Um. So the first parts of it, what you're trying to say is basically the summary of like who you are as a company and the mapping of your organization in, in the general sense. And then after that is when you get into the more specifics and the individual controls itself. Yeah. So kind of, kind of.

[00:11:14] So section one is just what's the company? Who are the important people there? And what exactly do they do? And why are they required to do this? Mm-hmm. Our next section is what technologies in scope and how does it play with one another? How does it communicate? How is it connected? What's that scope really look like at a more technical level? Section three in our system security plan is that section of requirements. Um, that is everything broken out by control family.

[00:11:42] So, um, access control, awareness and training, um, audit and accountability, et cetera. Each control, who's responsible for each control, the assessment objectives are listed out. And then we talk about how we've implemented each one. Mm-hmm. That's where we get very focused and specific. Yeah. Because that's what our assessors are going over.

[00:12:07] 3.1.1, you know, access control, uh, how are you identifying your processes acting on behalf of users? And I'm over here going, well, according to our system security plan, we identify our processes acting on behalf of users by doing blah, blah, blah, blah, blah, blah, blah, blah, blah. Mm-hmm. So you want to be able to, you want to be able to read that off with when they ask you, you answer.

[00:12:28] And it's enough information that they feel like it is enough to know what you guys are doing as a company and be able to move on from there. Right. If it comes from a specific policy, we will reference that policy. A specific procedure, we will reference that procedure. A specific setting in Intune or a GPO, we'll call that out specifically and reference that. Mm-hmm. That also helps us. That's a little cheat that we put in for ourselves. So when our assessor says, can you prove that?

[00:12:56] We're going into Intune and pulling up that setting and saying, look, there's the setting. It's applied on all endpoints. Questions? Mm-hmm. And that's a huge help. But I think that's another kind of cheat as we go through in writing these statements. We've got some statements for certain controls that are probably a good two, two and a half pages long. Our assessors hate that because I got really granular and in the weeds and accounted for everything on every system. Hey, thoroughness, right?

[00:13:24] When doing that, some things that were really helpful for us from a readability standpoint and just being able to skim through, breeze through, update appropriately and understand what we were doing. First off, and this is I think the lesson I learned on my first day with Axiom was if I'm citing a document, put it in bold. Mm-hmm. It helps it stand out. It lets you know where it's at. And that has been so invaluable over the course of our journey, modifying, editing, and improving.

[00:13:51] So that way we know, and that actually helped create a master list of documents of here's all the documents cited in the system security plan. Yeah. And which control that's aligned to. So if I update subsection G in a system security plan, or not system security plan, we're talking about those right now, in an access management policy. Yeah, in a policy. I know to look at that section, cross-reference that with my system security plan and see, did anything change? Does this impact my SSP at all?

[00:14:21] The second thing, as we were going through that entire process, was, you know, two and a half pages for giving control. That's a lot of words, right? Right. So how do we know which assessment objectives we're talking about? Well, we'll write our sentence. You know, this is how we identify authorized users. We identify authorized users through this and this and this and this and this. At the end of that sentence, we put in a little bracket A or B or C or D.

[00:14:47] Something to call back to the assessment objective that we're looking at there so we don't go too far into the weeds when we're being assessed. But we also know exactly how we're meeting that specific AO. When you're saying getting too far into the weeds, I'm really curious about your perspective of, is there such a thing with your SSP of writing too much? Maybe at some point? Yeah, there absolutely is.

[00:15:12] It's kind of like, you know, think back to when we were all kids and, you know, you did something that you're going to get in trouble for. And you get home from school and your parents ask you, do you have any idea what you did? The more you talk, the deeper of a hole you tend to dig yourself. So it is important to find that balance. Yeah. Because the more specific you get with that, the more you can get wrong.

[00:15:42] CMMC is, again, very complex. Implementing all these AOs across different systems can be very complex. The more in the weeds you get, the more you put yourself in a corner. You want to be thorough, but not restrictive, if that makes sense. Yeah. No, it definitely does. Yeah. I think a great example of that would be,

[00:16:06] if you have a setting in Intune that requires a specific lockdown of a system, maybe that's how you're doing your application allowed listing. You would write in your system security plan for that AO, I do it through this setting, period. If you start talking about the specific values of that setting and how that setting is configured, if they go to assess that and that doesn't match, that could potentially be a finding that you are not meeting that because it's not what you said you did.

[00:16:36] We all know from just working in IT and technology, things change often, whether that be through human error, whether it be through Microsoft. One of my tasks right now is reviewing our baseline inventory or our baseline configurations, including all those Intune policies. And from when we made them to now, Microsoft changed a bunch of stuff. They're different now. What do you know? And I'm over here trying to just go, okay, this setting's over here. Where is it over here? And try to – Yeah. It's not fun, folks. Trust me, it's not.

[00:17:05] That's why I'm doing a podcast today because it means I get to procrastinate on that for a little bit. So thank you. Okay. Let's keep on this train then too. What are some other things that you feel like could be easily messed up when creating an SSP? You know, one thing that we found is making sure that the documents and settings that you specify in there actually match. There are a few times in our early drafts where, you know, we have the Axiom Access Management Policy.

[00:17:35] But for several controls, it said Access Control Policy. Oh, yeah. So you want to make sure – you know, our assessor was able to, you know, when we did our mock assessment, was able to, you know, put two and two together and realize it was the same document. But still, you know, it's a little gotcha you can get. You know, so you just want to make sure that everything lines up as accurate on that front. Another thing that I think you can get into, and this is actually a really critical one, inheritance.

[00:18:05] So I mentioned earlier, if you're using a cloud vendor like AWS GovCloud or Microsoft GCC or GCC High, including Azure, you have to demonstrate that you're doing your job and your requirements that they've told you you have to do. You can't just show up to an assessment and say, oh, yeah, Microsoft handles all this. Like, it's their FedRamp. It's fine. Trust me, bro. It's fine. They've got – they're on the FedRamp marketplace. That counts, right?

[00:18:32] No, our assessor, when we said we inherited something from a Microsoft FedRamp ATO, they wanted the specific control we inherited, and then they wanted to see that we took that statement that Microsoft said, and we took it the rest of the way there. So that was important for us to call out. And we actually, for each given control, we put a specific section for our inheritance statements, saying whether we did or did not inherit for a given control. So when we would get into, say, our physical security,

[00:19:01] we would inherit from Microsoft for their system security plan for their Azure data centers. Yeah. And we would say, you know, for data centers governed and owned by Microsoft for our environment, we inherit this control fully from Microsoft per FedRamp, blah, blah, blah, this. You know, Axiom does not, or if we did, you know, this is what we do from here. And then we would get into that specific implementation. Oh, interesting. So it's kind of like, so what you're saying is when a CSP is involved,

[00:19:30] you kind of fill in the blank with that part of it, but then you continue further as well if needed, because you can't. Yeah, because I guess you're right. It's like in a control, they're only probably doing a part of that with their process, and then we have to do the rest of it. So it's never really fully fulfilling a control. So we have to, like, continue on with what we do from that. Is that what you're trying to kind of say?

[00:19:59] Think through your auditing and logging capabilities. Microsoft inherently provides logging capabilities and some audit capabilities within the 365 environment for things like Entra and whatnot. That's not a blank check for that entire domain for you, because they simply, you know, do that by default. You still have to review your logs. You still have to configure your alerts. You still have to build your container. Just because you bought it from Microsoft doesn't mean that everything's perfect.

[00:20:27] That's exactly why responsibility matrices are so important for not only the CSP, but your ESPs and your end clients, is to clearly understand what your job actually is to do. That way there's no confusion about, well, I thought Microsoft was doing this for me. It really demystifies it. Because at the end of the day, this is a supply chain. You know, Microsoft is the big one, or Amazon is the big one at the top with that first link. But then your ESP is like Axiom. We come in that.

[00:20:56] We're another link. And then finally you have the, you know, the end client, the OSC, OSA. I'm flip-flopping which one's the most appropriate one to use these days. I think they are too. That's okay. You know, that's the next chain. But, of course, they're going out and selling their products to the, you know, Lockheed Martins and Boeings and, you know, et cetera. So it's all linked together. And we all need to know what we're responsible for. And detailing that in the system security plan is super helpful and super important.

[00:21:25] Because, again, it shows I understand my requirements in the DoD space. I understand that, well, I might be using stuff from a vendor that's FedRAMP. Here's exactly what they told me I have to do. And now I talk about how I do that and how it meets this control. Yeah, you brought in a great point that I did just want to touch on,

[00:21:46] which is the CRM or the client or customer responsibility matrix that also should connect with your system security plan. This is the opportunity to speak very clearly to what each person is doing as far as the controls in the processes.

[00:22:08] So just like Adam was saying before, if you have an MSP or an ESP or you have a CSP, look at all of those definitions. I apologize. But you are working with a client. The client needs to know what their responsibility is, what the MSP is doing, and then what the cloud service provider is doing. Each one of those needs to be directly filled out in that CRM.

[00:22:37] So can I ask you too, Adam, about the connection between, since we've been talking about the SSP and the CRM, what is the connection process between the two? Did you create our SSP and then create the CRM? Did you make them at the same time? What is the process between connecting those two? A little bit of both.

[00:23:03] So when we went through our journey, we prepared our system security plan in line and following Microsoft's CRM to make sure we were just building it right for us first. Yeah. The reason on that is simply we didn't know if everything that we wanted to do would actually hold up under scrutiny for an assessment. You know, we were a little cautious, a little anxious about some stuff, and we wanted to play it safe.

[00:23:28] So we went through our mock assessment that validated a ton of stuff for us, was really valuable and helpful for us. Then that started our, we'll call it the sprint, between mock assessment and real assessment, where we realized we had a whole bunch of lessons learned and improvements we wanted to make, and less than six months to do it all. Yeah. Wow. In that time, we also, you know, I didn't have the luxury this time around of focusing my entire energy on just our stuff,

[00:23:56] because we had clients knocking on the door. Mm-hmm. So I had to start building multiple things at the same time and thinking through, what would a system security plan for a client look like? Yeah. And that's when I really started to think through, what do we provide the client and what does the client have to do? And that helped build that connective tissue, because I was thinking through writing this SSP statement for the client, and would that be accurate? Yeah.

[00:24:23] Then I had to think about, okay, well, what does the client specifically have to do in this versus what are we responsible for? Yeah. I should probably write that down in that responsibility matrix in our first draft of that. And then we took that a step back to our own SSP to add an extra section. This is purely extra credit optional stuff. But we simply decided to describe in our system security plan, how would we do it for a client? How would we support that entity? So that way, if it was something where we said, I don't know, instant response procedures.

[00:24:53] You know, we have our documented IR procedure, and it is the same procedure for us that we would follow for a client. So we'd write out our IR statement saying the client is responsible for defining and identifying certain things. If they're getting a policy template from someone, they still have to read, review, authorize, and follow it. But all that would then authorize us to be able to do our job, and we do our job through our procedure as we described in our system security plan. And this is now all detailed and documented in the responsibility matrix.

[00:25:21] So, you know, all that to say, if a client comes up to us and says, how can you get a CMMC compliant? We go, well, we can do that. We can go through this process. But we're not promising that we'll just do it. We're not promising it'll be easy. Yeah. And we're not promising that we will do it all for you because you can't. Yeah, exactly. Yeah.

[00:25:41] I mean, you literally, no matter how much you will it into existence or want it to happen, there are policies and there are procedures that we physically and literally can't do for the client. Right. Even just going back and forth with Bobby the first times around is I would, you know, anything that any control that said define or identify, even if we're providing policy templates, I still showed client responsibility and ownership on that.

[00:26:10] And he's like, well, why can't we just say that we provide that? And I'm like, because they've got to understand the document they just signed. Yeah. Because at the end of the day, if, you know, say in a hypothetical scenario, manufacturing shop, and you've got that one grisly, grumpy old engineer who's been there since, you know, the dawn of time who will never change how they operate because if it ain't broke, don't fix it. Yeah, right.

[00:26:35] And that person decides they're going to just ignore data sensitivity labeling and CUI marking on CUI that they may generate. That's a huge problem. So we might be aware of that. We take that to the appropriate, you know, person in the client environment and say, dude, Joe over here doesn't isn't following your policies or procedures. And like, you've got unmarked CUI floating around that's unsecured. This is a huge problem.

[00:27:02] If the business leader doesn't understand that they signed a data management policy saying this is required and non-optional, does that business leader just go, you know, what's the big deal? Like, you need that consistency. And this kind of stuff has to flow from the top down. Yeah, so true. Like, even on our end, we've got our policy exemption tracking file, which we don't have any exemptions. But every time, you know, Bobby wants to do something and I say, you can't do that, that goes against the policy or that's not the procedure.

[00:27:30] He doesn't like that very often because now he's stuck in an administrative paper trail when he's trying to get something done. But I always tell him, you can exempt yourself from this. I just have to write it down and risk assess it. Yeah. And then he goes, no, we'll do it the right way. But that's because we have that top down approach to getting it done. Mm hmm. Mm hmm.

[00:27:50] Well, compliance isn't supposed to be the easy way, you know, and it's supposed to enforce these policies and procedures to make sure that security is truly happening. You know, it's not always going to be the most efficient way to do things because there's going to be sometimes more steps. A lot of times there's going to be more steps. A lot of paperwork.

[00:28:17] A lot of, you know, you'd know that there's a lot of paperwork, but it's all purposeful. I was going to say, speaking of all the paperwork, I just finished the review of all of our procedures in this, you know, because that's an annual requirement for us. We review every procedure every year. Mm hmm. That was hundreds of pages of procedures that I had to go through and read and say, is this up to date? Are there any enhancements to it, et cetera?

[00:28:46] Which then goes back to our system security plan of how we govern our maintenance procedures, saying that we've got our maintenance checklist that we follow that has procedures. And that's a list of stuff. And then we review all of our procedures, blah, blah, you know, and it all starts to come full circle because now I'm just talking about the demonstration of a given control and assessment objective, but how I've documented that in a repeatable checklist and reference that in my system security plan. And so when our assessor assessed us over that item, they said, well, what procedures do you follow? Here's the maintenance checklist with a list of procedures. Right. Cool.

[00:29:15] Can you show us that you did one of those? Yeah. Here's a ticket that, you know, Jim did last week for this given one. And they're like, can you show me that he followed the procedure? Yeah. Check out his ticket notes. He said that he followed the procedure in here and he demonstrated what the results was from each step in the procedure. And they're like, okay, moving on. No, that's great. I love that example. Cause I, I mean, you said, you've said that to me before and explained it in that way. And it was just really helpful to understand.

[00:29:43] Like I even told Bobby, it reminds me of like, if you compare to, cause he wanted me to do a theater analogy and it kind of reminds me of a script. It's like, like the SSP is your script that you need to stay on, stay on book. You know, keep, we're not saying that we need to do some improv classes here. You know, there's no need for it. Stay on script, uh, follow your script.

[00:30:05] And it should be a good enough script that when you read off of it, it totally and completely makes sense, you know, to your audience, your assessor. You know, um, when I say with enough information that if you do have an opportunity to do those improv moments, you can do so with meaning. You know, we think of some of those absolutely fantastic movie moments that were completely improv and how great some of those landed. If it wasn't for a good script behind it to create that opportunity, we probably never would have saw it. Yeah.

[00:30:33] I think I saw a random trivia thing from, uh, the, you know, from Arlie Ermey in Full Metal Jacket. They didn't write his dialogue. He improv just about everything he did in that. Wow. Wow. He was just so good at what he did that the, the, the, the directors was like, this is great. Unfortunately, in the CMC space, we are not all that kind of a person. We cannot just riff things off the top of our head. No. And it has to be written down for the assessor to assess anyway. Yeah. So you need that script.

[00:31:02] You need that system security plan. It needs to be good enough to give you what you need in that time without fumbling over, you know, trying to figure out what you're trying to do there. Yeah. Hey, I thought you were going to, I thought you were going to mention Han Solo because what's Han Solo's classic line that he improv'd that was not supposed to be the case. When. That's not how the force works. That's a line, right? Well, no, I was thinking of when she says, when she says, I love you. And he says. Wow. Spoiler alert.

[00:31:30] And he says, I didn't, I just said she, I just, you never know who I could be talking about. And he says, I know. And not. I love you too. That he wasn't supposed to say that. That was not written. But that was kind of cool, honestly. Yeah. So, okay. I want to end this with one more section. And I'm calling this section cheat codes. They're not really cheat codes.

[00:31:56] But just things that I feel like that you want to share with people that you're like, man, this was really helpful to me. And maybe I wish I would have known sooner. What would you say are a few of those things that you could tell somebody that's making an SSP? So I mentioned a couple things early on. You know, namely, when you write out your implementation for a given control, make sure you note which assessment objectives correlating to which sentence you wrote down.

[00:32:25] If you're putting your documents in there, make sure you bold the names of those documents to make it easier for you. So don't be afraid to use appendixes for additional information. We've got a few of those in ours. Like, for instance, we've got our list of ports and protocols allowed through a firewall listed out there. As well as our just overall, not exactly our asset inventory, but we've got a list of our asset types and what they are and correlating that to our CUI categories.

[00:32:56] So we're not afraid to use those as we need to. Each organization may be slightly different in how they want to handle that. They might have more documents that will be external. They might have less. But again, and another big one, have a buddy with you when you go through this journey. You know, from writing our system security plan ourselves and just writing so many documents, things start to blur together an awful lot. We all make mistakes and typos.

[00:33:25] You know, spellchecking Word is, well, it is what it is. I'd be cautious against using a third-party tool like Grammarly or something like that because they do collect keystrokes and form data and whatnot about you. Yeah. And if you're writing, you know, potentially sensitive and confidential information, that could be a problem. Yeah.

[00:33:46] So having a friend to be able to help go through proofread for you, but also someone that understands the requirements as well can help out a lot because they can look at that and say, hey, your statement for 3.4.1 Bravo is pretty weak. I'm not buying this. I think you need more information here. Or they may say, this is way too much. You lost me after the third sentence. That's really helpful. If you have one in your company that can be that person for you, awesome.

[00:34:14] You know, I was able to bug Bobby with things as we were able to get into other specific ones, you know, lean on the rest of the team for that help. If you don't, a consultant is really helpful. Again, if that's not always available, there are some great peer groups out there as well. Shout out to MSP Cyber X. There are your other ones like the CMMC Center of Awesomeness, the Discord out there, the KUI Discord. KUI Discord, yeah. You know, LinkedIn communities, subreddits, et cetera.

[00:34:43] Yeah, there's a CPN group that Derich has on LinkedIn that's really great too. So... There's a lot of groups out there. Yeah. I am curious. I know I said that that was the last thing, but it made me just think of a question for you. I am curious on if you were to give your opinion on somebody who is hiring a person on their staff to create these plans and these documents.

[00:35:12] If they were thinking that they were going to hire this outside person to come in and this was going to be their one job was to create these CMMC documents. One, would you even recommend it? And two, if you did, how long would it take that one person to do? Well, first off, it would be a little ironic if I said I don't recommend that considering that's what I was hired in to do.

[00:35:39] No, but just one person because Bobby helped you. Yeah. Like Bobby was your partner in crime. But I'm talking about a person that just hired the one person on staff to do it for their organization. If it's just a single person trying to do everything, get them some help.

[00:36:00] There's a ton of stuff in here because first off, not only do you have to write a system security plan, you need the policies, you need the procedures, and your environment needs to be architected to support all that, and you need your people trained. That's a full-time job. Each one of those things can easily be its own full-time job depending on the size and complexity of a company. On top of that, too, things come up.

[00:36:27] Depending on how you look at your small, medium businesses, if that one person is trying to do all that and then run the IT department, they're already six feet underwater, and they don't even know it yet. Yeah. Right. And in terms of time, you know, with us and our journey, we went from essentially a rough draft of stuff around November of not last year but the year before.

[00:36:53] And we took that rough draft, threw it out, started over, got it to being assessment ready by July, went through our mock assessment in August, redid it all by mid-January. That was a dedicated team of people working their full-time jobs to get that across the finish line, including overtime.

[00:37:18] That final stretch, basically, we'll just say from about mid-December through mid-January, I'd sign on about 8.30 in the morning and I would sign off about 9 o'clock at night just to get it done. Yeah. I don't recommend that. That's a lot of work. Yeah, I would recommend. We had some ambitious targets. We wanted to get it done. It was, you know, Bobby and I had communicated to make sure that that was all agreed upon and everything, too. Mm-hmm. But it takes time.

[00:37:44] And this is with at least myself, Bobby, and a handful of people on the team doing their own respective parts to get this done. A single person you are probably looking at between one and three years. Mm-hmm. Especially if they're starting completely from scratch. Yeah. And P.S., because I see this question come up a lot on the CMMC subreddits and the MSP subreddits, don't hire an intern to do that.

[00:38:10] Like, I see so many posts from people saying, I'm an intern at the cybersecurity firm and they tasked me with coming up with our CMMC compliance posture. Stop. Run away. So if you have any questions about SSPs or CRMs or any of that stuff, please make sure to either follow us on LinkedIn or comment under our YouTube videos or whatnot so that we can check it out. We're pretty responsive and we will reach out to you as soon as we're available. So just let us know.

[00:38:38] And also, we have some really exciting news coming next week. So if you're not already following our podcast, please make sure to follow us and tune in next week because we have some exciting announcements. Well, guys, I hope you enjoyed today's episode and tune in next Thursday for another episode of Climbing Mount CMMC. But until then, keep on climbing. See you guys. Yeah.

[00:39:03] Make sure to follow us on LinkedIn and YouTube to stay up to date on the latest CMMC news. We hope you guys enjoyed today's episode and listen out for the next one. But until then, keep on climbing.