Shield Sessions: 10 Lessons From Hands On CMMC Implementation
By: Courtney Brahm
It’s quarter 2 of 2026. Pardon my French, but holy s***, that happened fast.
While this whole CMMC effort has been years in the making, it really does feel like just yesterday the first assessments were happening and everyone was waiting on final guidance to shake out (if you know, you know). But that wasn’t yesterday. That was 15 months ago.
Those 15 months have been a great ride. We have walked, run, and supported more than 20 clients through their CMMC Level 2 assessments. Each one has brought a different set of challenges, but also, a lot of the same patterns. With each subsequent assessment, you start to see what this whole CMMC program really looks like once it is part of how a business runs in actuality.
There have been many lessons learned along the way. Some lessons have been surprising, some have been hard learned, and some have reinforced what we already knew. And here are 10 of those lessons that we’re sharing so hopefully you don’t have to learn them the same way we did.
What this covers:
- Where CUI actually spreads inside organizations
- Why compliance alone creates friction in operations
- What tends to break during implementation
- How user behavior shapes outcomes
- What drives programs to successful completion
Lesson #1: Know where your CUI actually lives
This one sounds simple, but it is what makes the whole thing… a thing.
As organizations grow and change, so too does the use and storage of CUI. It is easy to think that a defined process in place today will keep everything contained tomorrow. In reality, we all know how this goes: one person shares something, it gets saved somewhere else, and before long that same information exists across multiple folders, sites, and places no one originally accounted for.
That does not mean everything is broken, but it does mean you need to take a real look at how that information has moved over time. Once you understand that, scope becomes clearer, and in CMMC, scope drives everything. If you don’t know where the data is going, you can’t effectively protect it.
Compliance should support how your business operates
Once you know where your data lives, the next step is understanding why it lives there.
Compliance can guide how decisions are made, but it should not be the only driver of how your business operates. Compliance in protecting CUI has an actual impact, because that data does matter to your business. It’s not meaningless data that is just creating a compliance burden; it’s actual data that is in use.
There are times when processes need to change to meet compliance requirements, but if those changes do not align with how work actually gets done, they will not hold. The goal is to support business operations in a compliant way, not force operations into something that feels unnatural.
Build a security program, not compliance checklist
Alright, so now we know where the CUI is and we are starting to build processes around protecting it, but at some point you have to step back and look at the environment as a whole. This is usually where things start to drift a bit because it is really easy to look at your IT environment and try to fix things one by one. You put a Band-Aid on problem A, a little ice on problem B, maybe a quick workaround somewhere else just to get something to pass, and in the moment it feels like you are making progress because things are getting checked off.
But what is actually happening is you are layering fixes instead of building something cohesive, and that accumulates as debt, quickly. Before long, you end up with an environment that technically meets requirements but is difficult to operate and even harder to maintain because everything is being held together by patches instead of structure. Organizations that approach CMMC this way often find that their environments become harder to manage over time, even if they meet the requirement on paper.
The way out of that is not throwing more fixes to the pile. It is stepping back and building a security program instead of a compliance checklist. Yes, the requirement is a CMMC Level 2 certification, but that is not really the point. The point is protecting your data, which includes CUI, and if you focus on building something that supports a strong security posture, the compliance tends to follow. It becomes built into how the environment works.
At the same time, the environment is not static and neither is the threat, so whatever you build has to be able to hold up over time without turning into a burden on the organization. That is usually the difference between something that just passes and something that actually works.
Build an actual program, not just pretty documentation
There is no shortage of content out there on documentation. Templates, examples, infographics, perfectly formatted policies that make it look like if you just follow the structure, you are in a good place. It is easy to look at that and assume that is where most of the effort should go, especially when you start thinking about assessment.
In practice, that is not usually where teams get stuck.
If your processes are actually working and people are following them, documentation tends to come together more easily than expected because you are just capturing what is already happening. It still takes effort, but it is structured, and it makes sense because it reflects something real.
Where it starts to break down is when documentation is trying to lead instead of support. You end up with policies that look great, diagrams that check every box, and procedures that read exactly how they should, but when you step into the environment, that is not how things are operating in reality. That disconnect is unfortunately what creates most of the friction later on.
It’s also where teams start to feel like they are spinning, because they are putting time into refining documentation that is not grounded in something stable. Yet.
The better approach is to focus on getting the implementation right first, making sure the processes actually hold up in day-to-day use, and then building documentation around that. When it is done in that order, it lines up much more cleanly and is a lot easier to maintain over time.
Nail the basics
This is one of those areas that does not get as much attention as it should, mostly because it feels simple compared to everything else going on.
When you start working through CMMC, it is easy to focus on the more complex scenarios or the controls that feel more technical, but the issues that tend to show up most often are usually tied to everyday processes that run in the background of the organization.
Onboarding is a good example. If access is not aligned correctly when someone joins, that gap does not always get caught right away, but it carries forward. The same goes for offboarding, especially when it is delayed or handled inconsistently. It’s not one big failure, rather, small things stacking over time.
Role changes are another one. Someone moves into a new position, picks up additional responsibilities, but their access doesn’t fully reflect that shift, or worse, it still reflects what they used to do. That kind of drift is easy to miss in the moment and harder to clean up later.
Even how documentation is handled internally or how information is shared externally comes into play here. These are all routine actions, and because they happen so often, they have a much bigger impact on the environment than most people expect.
When those fundamentals are consistent, everything else has something solid to build on. When they are not, even a well-designed program starts to show cracks in ways that are not always obvious at first.
Remember the people
This one is my favorite – If you didn’t know, my background is not in cybersecurity -it’s in education. Specifically, behavior. And as it turns out, this makes all the difference here. Your simultaneously biggest risk and greatest asset in your organization is your people. And for your security program to work, the people have to be on board.
Having a strong security program and implementing what is needed for CMMC compliance is not always easy. In most cases, it pushes on pressure points and creates friction across workflows and day-to-day operations. Taking the time to help users understand why changes are happening, how they personally connect to protecting CUI, and how the changes support their work goes a long way in making adoption smoother.
Workflows will likely need to change, and not everyone is going to love that, but preparing users early and getting buy in on the short-term changes sets up long term success. It also tends to reduce a lot of the friction and headaches that come up during implementation.
Who you work with matters in CMMC
Here’s a straightforward lesson: who you are working with matters. Compliance lives and dies in the gray space. Making sure you are working with people who understand that is crucial. This applies to both who you choose as a partner for implementing and maintaining your CMMC program and who you choose to assess your environment.
In both cases, you want to make sure you are working with partners who understand your business and how your environment operates. You want to make sure they evaluate implementation based on how your organization is meeting CMMC requirements, not how they would meet the requirements in your stead. That distinction, and selecting a partner who understands it, helps ensure you are building a security program that supports your business, not forcing your business into an unwieldy and ineffective checklist.
Deadlines drive decisions
Okay, you’ve made it this far. These lessons are starting to stack up, especially as we get into these last couple. So far, we have covered building a security program, aligning it to business operations, thinking about the people it affects, and choosing the right partners for your organization; but we still have not actually scheduled the assessment, and this is where a lot of organizations start to slow down.
Without a scheduled CMMC assessment, it’s easy to get far down the road and still find that the goal keeps getting pushed because there is always something else to refine or improve. Without a clear endpoint, progress can start to drag without anyone really intending for that to happen.
The way to fix that is to set a deadline and schedule the assessment. Not an unrealistic one, but one that is real enough to commit to, forecast against, and put on the calendar so that everyone understands what they are working toward.
Once there is a defined assessment date, alignment tends to follow because stakeholders are working toward the same objective. Investment decisions are quicker and items that might have sat open, undefined, start to close as priorities become clearer. That date becomes the point everything works toward. Setting it helps remove barriers and keeps momentum moving. In most cases, it’s what gets organizations across the finish line. Deadlines motivate action. It is what it is.
Maybe not the time to be the groundbreaker
Do you know the most common way that user credentials are compromised? Phishing. As it turns out, phishing is devastatingly effective. Still. And it’s so effective because it targets the often-weakest link in the security program: the people. It produces results. Phishing works, reliably. But there’s a pretty simple protection that we should all be using that greatly reduces the risk: multifactor authentication. Simple, and proven to work.
Security is evolving and it can be tempting to jump on the newest, hottest thing that claims to optimize your security program or identify threats before they even hit your environment. But your security program, especially in a CMMC environment, may not be the best place to try new groundbreaking technology or adopt the newest tool on the market. The basics do work, and sticking to known, proven methods is usually a better path than rolling the dice on something flashy.
Embrace the Starbucks model
Starbucks is the model network for most organizations. That is, Starbucks is a place where people can reliably get wifi, coffee, and a comfortable seat. Mirror this model in your organization if you can. Focus on defending endpoints and identities, and invest in protection there – the network-based moat is yesterday’s method. This model is generally a better security approach anyway, and it has the helpful side effect of simplifying your CMMC scope and makes the rest of this advice much easier to adopt. Like I said in lesson 1, scoping is the name of the game in CMMC, simplify the scope, simplify the requirements. If you can keep your network out of scope, you can make everything that much easier.
Thanks for taking the time to read. I hope these lessons help the next 15 months move a little faster as you work through implementing your CMMC program. If you want to go a bit deeper, we spend more time on these topics in our webinars and additional content on CMMC implementation.
