Cybersecurity Maturity Model Certification (CMMC) Overview

Introduction

When I was last on the industry side, more than twelve years ago at Northrop Grumman, Cybersecurity Maturity Model Certification (CMMC) did not exist. That does not mean compliance was not there. It absolutely was. Defense work already came with mandatory safeguards, security controls, handling rules, contractual obligations, and the constant understanding that if you were going to touch sensitive government information, you were going to be expected to protect it. The names, structures, and enforcement mechanisms have evolved, but the underlying idea has been around for a long time. If you wanted to do serious work in the defense space, cybersecurity was never optional. It was part of the cost of entry.

Then I spent the next twelve years on the other side of that equation, in government. From that vantage point, I was much closer to mission systems, accreditation, risk decisions, control implementation, security documentation, and the broader machinery required to get Department of War systems approved to operate on DOW networks. I was not living inside CMMC the way a contractor, subcontractor, or defense startup would need to. That world was adjacent, not central. So stepping into my new role as Technology Director at Rise8 has felt a bit like walking back through a door I used to know, only to find the building renovated, relabeled, and running under a new set of rules.

Still, the terrain does not feel entirely foreign.

The more I started reading about CMMC, the more familiar it felt. Not identical, but familiar in the way a different branch of the same river feels familiar. The language changes. The audience changes. The process shifts. But the core logic is recognizable. You are still dealing with protected information, required safeguards, scoped environments, documented controls, assessment criteria, and the need to prove that what is written on paper matches what is happening in reality. In that sense, CMMC does not feel like some alien compliance invention dropped out of nowhere. It feels more like the defense industrial base's version of a lesson government systems have lived with for years: trust is not assumed, especially when sensitive information is involved. It has to be built, implemented, documented, and demonstrated.

That is what makes this topic interesting to me. On paper, CMMC looks like one more acronym in a long defense alphabet soup. In practice, it is much more consequential than that. It is the DOW trying to create a more consistent, verifiable standard for how contractors protect Federal Contract Information and Controlled Unclassified Information. The framework leans heavily on familiar NIST guidance. NIST SP 800-171 Revision 3 provides the core security requirements for protecting CUI in nonfederal systems and organizations. NIST SP 800-171A Revision 3 provides the companion assessment procedures. At the highest end of the model, NIST SP 800-172 adds enhanced requirements for more advanced protection needs.

So I am writing this from a specific vantage point. I am not writing as someone who has spent a decade running a CMMC practice. I am writing as a technical leader with a long background in defense, software, security, and government systems who is now getting reacquainted with the contractor side of the fence. That perspective matters. It lets me see both what is new here and what is not. CMMC may be newer than the compliance structures that came before it, but the broader pattern is familiar: if you want to participate in the defense ecosystem, you need more than good intentions and a few security tools. You need disciplined safeguards, clear boundaries, and evidence that your organization can handle sensitive information responsibly.

This post is my attempt to make that world easier to understand. Not as a dry checklist. Not as a legal memo. More like a field guide for technical leaders, builders, and defense tech teams who need to get smart on CMMC quickly and without the fog. Because while the framework may look dense at first, the basic story underneath it is fairly simple. The Department of War wants to know whether the companies it relies on can be trusted to protect sensitive information. CMMC is one of the ways it now answers that question.

What CMMC Is

At its simplest, CMMC is the Department of War's way of asking a very practical question: if a company wants to do business with the DOW and handle sensitive government information, can that company actually protect it?

That may sound obvious. Of course it should. But this is the kind of obvious that only becomes obvious after years of breaches, inconsistent safeguards, uneven self-attestation, and the slow realization that trust across the defense industrial base cannot live on PowerPoint alone. At some point, somebody has to check whether the doors are actually locked.

That is where CMMC comes in.

CMMC, or the Cybersecurity Maturity Model Certification, is a cybersecurity verification framework for defense contractors and subcontractors. Its purpose is to ensure that organizations handling certain types of government information meet a required level of cybersecurity maturity and can demonstrate that they do. CMMC is both a maturity model and a certification requirement, primarily aimed at Department of War contractors handling government data. Current DOW guidance likewise presents CMMC as the framework used to verify implementation of cybersecurity requirements for companies in the defense industrial base, using a tiered model tied to the sensitivity of the information involved.

What makes CMMC important is that it is not just advice. It is not a best-practices poster on the wall. It is a compliance mechanism tied to contracting. In other words, this is not the DOW saying, "We recommend that you take cybersecurity seriously." This is the DOW saying, "If you want certain kinds of work, you need to be able to prove that you protect the information that comes with it." From a policy perspective, CMMC certification is embedded in contract language and that noncompliance can affect an organization's ability to win future government contracts.

Another useful way to think about it is this: CMMC is less about whether a company says it is secure and more about whether it can withstand scrutiny. That distinction matters. A lot of organizations have good intentions. Many even have decent tooling. Firewalls, endpoint protection, MFA, logging, policies in a shared folder somewhere. But CMMC is concerned with whether safeguards are actually implemented, whether they are documented, whether the environment is properly scoped, and whether an assessor can trace claims back to reality. That theme shows up throughout the transcript, especially in the discussion of documentation, evidence, and the need for written practices to match what the organization is truly doing.

Here is the cleanest way to frame it:

There is also an important nuance here. CMMC is not trying to solve every cybersecurity problem in industry. It has a narrower and more specific purpose. It is focused on protecting federal contract information and controlled unclassified information in nonfederal systems and organizations. NIST SP 800-171 Revision 3 describes that foundation directly, stating that its requirements are intended for use by federal agencies in contractual vehicles and other agreements with nonfederal organizations handling CUI. NIST SP 800-171A Revision 3 provides the companion assessment procedures, and NIST SP 800-172 adds enhanced requirements that come into play at the highest end of the model.

That is one reason CMMC feels familiar to anyone who has spent time around government cybersecurity. The shape of the problem is recognizable. Sensitive information leaves pure government enclaves and moves into contractor environments. Once it does, the government still needs confidence that the information is being protected with rigor. CMMC is one of the main mechanisms the DOW now uses to create that confidence.

Understanding what CMMC is gets you only part of the way there. To really understand why it exists, you have to look at the kind of information it is trying to protect and why the DOW no longer treats that problem as something contractors can simply self-police.

Why CMMC Exists

CMMC did not appear because the Department of War suddenly discovered cybersecurity. The real story is less dramatic and more familiar. Sensitive government information had already been flowing into contractor environments for years, and the Department had already imposed safeguarding obligations through existing acquisition rules and security requirements. The problem was not the absence of expectations. The problem was the gap between expectations on paper and confidence in practice.

That gap matters more than it sounds.

The defense industrial base is enormous. Prime contractors, subcontractors, software vendors, cloud providers, integrators, consultants, niche engineering firms, and startups all touch parts of the mission. Information moves with the work. Technical data, contract data, program information, designs, support artifacts, operational context, and other sensitive but unclassified material do not stay neatly inside government-owned enclaves. They travel. Once they do, the government still has to trust that the receiving organization can protect them. NIST SP 800-171 Rev. 3 makes that exact point by stating that protecting CUI in nonfederal systems and organizations is of paramount importance to federal agencies and that the requirements are intended for contractual vehicles and other agreements with nonfederal organizations.

For a long time, that trust leaned heavily on self-attestation. In theory, that sounds reasonable. In practice, it proved uneven. The old self-certification approach was problematic due to inconsistent methodologies, standards, and sometimes inaccurate reporting. CMMC is also a response to breaches involving government contractors and as a way to strengthen security by building on existing federal acquisition requirements. The DOW states that the defense industrial base faces increasingly frequent and complex cyberattacks and that CMMC was developed to strengthen DIB cybersecurity and better protect FCI and CUI by providing greater assurance that contractors have implemented required safeguards.

That is really the heart of it. CMMC exists because the DOW no longer wants to rely only on a company saying, "Yes, we have this covered." It wants stronger assurance. Not perfect assurance. Not absolute assurance. But something more disciplined, more repeatable, and more verifiable than a checkbox exercise.

Another way to put it is this: CMMC is a supply-chain trust mechanism. It is the DOW recognizing that mission risk does not stop at the government network boundary. If sensitive unclassified information is stored, processed, or transmitted in contractor systems, then contractor cybersecurity becomes part of mission assurance. That is why the program is tied to contract performance, and why it focuses specifically on nonfederal environments that handle FCI or CUI.

A simple table helps here:

To be fair, none of this has arrived without friction. Industry, especially small businesses and nontraditional defense companies, has raised real concerns about the cost of compliance, the expense of assessments, confusion around scope and guidance, and whether the ecosystem has enough trained assessors to keep up with demand. Those concerns are not trivial, and they help explain why CMMC has drawn both support and skepticism across the defense industrial base. Still, from DOW's perspective, the core rationale has not changed: the cybersecurity risk to sensitive defense information is too serious to leave to uneven self-attestation alone.

There is also a quieter reason CMMC exists, and it is worth saying plainly. In the defense world, weak cybersecurity at one supplier can become systemic risk for many others. One small company with poor identity controls, weak endpoint security, sloppy data handling, or vague documentation can become the loose panel on a much larger aircraft. That does not mean every contractor needs the same level of rigor. It does mean the government wants a more defensible way to align security expectations with the sensitivity of the information involved.

That is why CMMC is structured in levels. The goal is not to make every company look the same. The goal is to make the required level of protection more explicit and more verifiable based on the work being performed and the data being handled. DOW's current CMMC program description reflects that model directly, with different assessment approaches and requirements depending on whether the contractor is handling FCI, CUI, or higher-priority CUI associated with Level 3 needs.

In other words, CMMC exists because the old way left too much room for ambiguity. And ambiguity is not a great security control.

To understand how CMMC applies in practice, you have to understand the two kinds of information sitting at the center of the whole model: Federal Contract Information and Controlled Unclassified Information.

The Information at the Center of CMMC

CMMC starts to make much more sense once you stop thinking about it as a general cybersecurity program and start thinking about it as an information protection problem.

The question is not just whether a company has decent security in the abstract. The question is what kind of government information that company touches, where that information lives, who can reach it, and what level of protection the Department of War expects around it. In practice, two acronyms sit at the center of that conversation: FCI and CUI.

They sound dry. They are not. They are the difference between a company being lightly in scope and a company finding itself pulled into a much more demanding compliance posture.

FCI stands for Federal Contract Information. FAR 52.204-21 defines it as information not intended for public release that is provided by or generated for the government under a contract to develop or deliver a product or service to the government, excluding public information and simple transactional information such as what is necessary to process payments. In plain English, this is the working material of doing business with the government. Think contract deliverables, internal technical exchanges tied to contract work, support artifacts, schedules, reports, and other nonpublic information created or handled as part of performance.

CUI stands for Controlled Unclassified Information. This is unclassified information that laws, regulations, or government-wide policy require to be safeguarded or have dissemination controls applied. The National Archives CUI Registry is the authoritative catalog of CUI categories, and the current registry shows just how broad that universe is, spanning areas like defense, export control, intelligence, procurement and acquisition, privacy, proprietary business information, and more. If FCI is the baseline category that tells you government contract information must not be handled casually, CUI is the category that tells you some information carries a much more specific protection burden.

That distinction matters because not every contractor handles the same kind of information, and CMMC is built around that reality. At a high level, Level 1 is tied to the safeguarding of FCI, while Level 2 is built around the protection of CUI through the NIST SP 800-171 requirement set, and Level 3 adds enhanced requirements derived from NIST SP 800-172 for higher-priority needs.

A table helps here:

One of the easiest mistakes a company can make is assuming CUI is rare, exotic, or limited to obviously sensitive engineering data. Sometimes it is that. Sometimes it is not. The National Archives registry makes clear that CUI is a broad umbrella with many categories and subcategories, and the DoD CUI Program site exists precisely because agencies and contractors need a common way to identify, mark, handle, and protect that information. That is why scoping matters so much. A team may think it is just handling ordinary project information, only to discover that parts of the data flow fall squarely into CUI territory.

This is where the topic stops being academic. Once FCI or CUI enters an environment, the question becomes practical very quickly. Which systems store it? Which users access it? Which admins can touch the systems that protect it? Which collaboration tools, file repositories, ticketing systems, endpoints, backups, and identity services are now part of the picture? NIST SP 800-171 Rev. 3 is explicit that its requirements apply not only to components that process, store, or transmit CUI, but also to components that provide protection for those components. That is one reason scope has a way of expanding faster than people expect.

Once you understand the kinds of information CMMC is trying to protect, the next question is where the actual security requirements come from. That is where the NIST foundation underneath the model starts to matter.

The NIST Foundation

Once you understand that CMMC is really about protecting specific kinds of information in contractor environments, the next logical question is where the actual requirements come from.

This is where NIST enters the picture.

If CMMC is the inspection framework, NIST provides much of the engineering drawing. It supplies the baseline requirements, the assessment procedures, and, at the highest end, the enhanced protections for more sensitive situations. That is one reason this subject feels familiar to people who have spent time around federal cybersecurity, even if they are newer to CMMC specifically. The names may be different and the audience may be industry rather than government system owners, but the rhythm is recognizable. Requirements. Controls. Assessments. Evidence. Repeat. NIST SP 800-171 Rev. 3 establishes the security requirements for protecting CUI in nonfederal systems and organizations, NIST SP 800-171A Rev. 3 provides the assessment procedures for those requirements, and NIST SP 800-172 provides enhanced security requirements for selected environments with more advanced protection needs.

The most important document for most companies in the CMMC conversation is NIST SP 800-171 Rev. 3. This is the core requirement set for protecting Controlled Unclassified Information in nonfederal systems and organizations. It is the document that answers the question, "What safeguards are we actually expected to implement?" NIST describes it as the publication that gives federal agencies recommended security requirements for use in contracts and other agreements when nonfederal organizations process, store, or transmit CUI.

Right next to it is NIST SP 800-171A Rev. 3, which matters for a different reason. If 800-171 tells you what you are supposed to do, 800-171A tells you how that gets examined. It provides the assessment procedures used to determine whether the requirements have been satisfied. That distinction is important because many compliance efforts stall out right there. Teams focus on implementing technology and forget that eventually someone has to evaluate whether the requirement is actually met, partially met, or unsupported by evidence.

Then there is NIST SP 800-172. This is not the document every contractor starts with, and it should not be introduced like it applies equally to everyone. It does not. But it matters because it represents the enhanced end of the model. NIST describes 800-172 as enhanced security requirements for protecting CUI, and the current CMMC structure uses selected 800-172 requirements as part of Level 3. In other words, this is where the framework moves beyond the baseline expectations for protecting CUI and into stronger protections for higher-priority needs.

A table helps separate their roles:

There are also adjacent NIST and federal references that help explain the bigger architecture around all of this.

NIST SP 800-53 Rev. 5 is the broader federal security and privacy control catalog. It is not the same thing as 800-171, but readers with experience in government accreditation, control tailoring, and baseline thinking will recognize the family resemblance immediately. FIPS 200 provides minimum security requirements for federal information and information systems, and the NIST Risk Management Framework explains the larger risk-based approach to selecting, implementing, assessing, and monitoring security controls. Together, those publications help explain why CMMC does not feel like it came out of nowhere. It sits in a larger federal cybersecurity tradition that already values defined requirements, structured assessment, and risk-informed implementation.

One useful way to visualize the structure underneath CMMC is through its core security domains, which group related requirements into recognizable areas of cybersecurity practice.

That is also why CMMC should not be misunderstood as a random overlay pasted on top of defense contracting. It is more accurate to think of it as a specific application of familiar federal cybersecurity logic to nonfederal environments handling protected defense-related information. The Department of War may own the contract relationship, but the NIST publications supply much of the technical backbone.

With that foundation in place, the next piece is understanding how CMMC turns those requirements into a tiered model. Not every company is held to the same standard, and the levels are how the Department of War signals what degree of protection and verification it expects.

The CMMC Levels

Once you get past the acronyms and source documents, CMMC becomes easier to understand because it is built as a tiered model. Not every contractor is expected to carry the same burden. That is the point. The level depends on the kind of information involved and the degree of assurance the Department of War wants before award and during performance.

In other words, CMMC is not trying to make a small company handling basic contract information look exactly like an organization supporting higher-priority programs with more sensitive unclassified data. It is trying to scale the expectation to the risk.

The current CMMC program describes three levels. Level 1 is focused on the basic safeguarding of Federal Contract Information. Level 2 is focused on the broad protection of Controlled Unclassified Information. Level 3 is aimed at higher-level protection of CUI against advanced persistent threats. The Department's current CMMC overview also states that the model is tiered based on the type and sensitivity of the FCI or CUI involved, and that implementation is being phased in over multiple years.

A table is the cleanest way to see the model at a glance:

Level 1 is the shallow end of the pool, but it is still a real requirement. It is aligned with the 15 security requirements in FAR 52.204-21 and is centered on protecting FCI. The current Department overview says Level 1 requires an annual self-assessment and annual affirmation. That should be reassuring for some companies, but not misleadingly so. "Basic safeguarding" does not mean "no effort." It means the expectation is narrower and tied to foundational protections rather than the fuller CUI-oriented regime.

Level 2 is where the model becomes much more serious for most defense technology companies. This is the level associated with protecting CUI, and the Department's CMMC overview says it requires compliance with the 110 security requirements in NIST SP 800-171 Revision 2, along with either a self-assessment or an independent assessment by an authorized CMMC Third-Party Assessment Organization every three years, depending on the solicitation. It also requires annual affirmation.

That last point matters. Level 2 is not one thing operationally. For some programs, a self-assessment may be enough. For others, an outside C3PAO assessment is required. The distinction is driven by what the solicitation requires and the nature of the information being processed, stored, or transmitted. That means companies cannot just say, "We are Level 2," as if that settles it. They need to understand which Level 2 path applies to the work they are pursuing.

Level 3 is the highest tier in the current model. It is not the default destination for the average defense contractor. It is intended for more sensitive contexts where the Department wants higher assurance against advanced threats. The current Department overview says Level 3 requires the organization to first achieve Final Level 2 status for the same assessment scope, then undergo an assessment every three years by DIBCAC, and provide annual affirmation verifying compliance with 24 identified requirements from NIST SP 800-172.

Level 3 is cumulative. An organization does not skip over Level 2 to get there. It also is not just more of the same. It is meant for environments where the Department wants stronger protection against more advanced threats, which is exactly how NIST frames SP 800-172: as enhanced security requirements for protecting CUI in more demanding situations.

Another quick table helps make the progression intuitive:

It is also worth resisting a common misunderstanding here. The levels are not abstract maturity badges. They are tied to the sensitivity of the information involved, the nature of the work, and the assessment expectations attached to the solicitation. A company does not simply choose the level it wants. In practice, the contract, the data, and the required assurance model determine it.

And that is why the levels matter so much. They translate the abstract idea of "better cybersecurity" into something the contracting ecosystem can actually use. A supplier either meets the required level for the work or it does not. Clean. Imperfect, perhaps. But much clearer than the old world of uneven self-attestation and vague confidence.

How Assessment and Certification Work

This is the part where CMMC stops sounding like a framework and starts feeling like a real business constraint.

It is one thing to read about levels, publications, and protected information types. It is another to realize that at some point an organization has to draw the boundary, gather the evidence, make formal assertions, and in some cases sit across from an outside assessor or government team that will test whether the story holds together. That is when the abstract turns concrete. Policies have to exist. Configurations have to match. Multi-factor authentication cannot just be "mostly there." Asset inventories cannot live only in someone's head. If the earlier sections describe the map, assessment is the moment someone checks whether the road actually exists.

At a high level, the assessment path depends on the CMMC level and the solicitation. The current Department CMMC overview says Level 1 requires an annual self-assessment and annual affirmation, Level 2 requires either a self-assessment or a C3PAO assessment every three years depending on the program, plus annual affirmation, and Level 3 requires a government assessment by DIBCAC every three years, along with annual affirmation and Final Level 2 status for the same scope.

A simple table helps organize that quickly:

That structure sounds tidy on paper. Living it is messier.

The first hard problem is scope. Before any assessment begins, the company has to define what environment is actually in scope for the information being protected. That means identifying where FCI or CUI is stored, processed, or transmitted, and then identifying the systems and services that protect those assets. If that sounds deceptively simple, it is because it usually is. Email, identity, endpoints, collaboration tools, administrators, backups, logging, remote access paths, and shared infrastructure all have a way of pulling more of the environment into scope than teams first expect. NIST SP 800-171 Rev. 3 makes this especially important by stating that the requirements apply not only to components that process, store, or transmit CUI, but also to system components that provide security protection for those components.

The second hard problem is evidence.

Most organizations do not fail because they have done literally nothing. They fail because what they believe they do, what they have written down, and what they can actually prove are not the same thing. The companion assessment document, NIST SP 800-171A Rev. 3, exists for exactly this reason. It is about examination, interview, and testing. In other words, it is not enough to claim a safeguard is implemented. The implementation has to stand up to structured evaluation.

That is why CMMC tends to force a company into a more disciplined operating posture. You do not just need security controls. You need repeatable evidence that those controls exist and are being maintained. In practice, that often means things like:

• a documented system security plan
• policies and procedures that match actual practice
• boundary and architecture diagrams
• asset inventories
• access control records
• logging and audit evidence
• training records
• vulnerability management artifacts
• incident response documentation
• records showing that corrective actions were tracked and closed where allowed

The next piece is the ecosystem around the assessment itself. For Level 2 third-party assessments, the broader CMMC marketplace involves C3PAOs, which are CMMC Third-Party Assessment Organizations, and The Cyber AB, which plays a central role in the authorization and ecosystem structure around assessors and related participants. The Cyber AB describes itself as the sole authorized nonprofit accreditation body for the CMMC ecosystem, supporting assessor training, marketplace functions, and the broader assessment community.

That matters because companies new to CMMC often assume certification is just a single event. It is not. It is really a chain of activities:

That last row is easy to underestimate. A lot of people talk about CMMC as if it ends with a certificate. Operationally, it is closer to a fitness test you have to stay in shape for. The assessment may happen on a cycle, but the environment changes constantly. People leave. Tools change. SaaS settings drift. New integrations appear. Systems expand. Admin paths multiply. A company that treats CMMC as a one-time paperwork sprint is likely setting itself up for pain later.

There is also a governance angle here that senior leaders should not ignore. Annual affirmations mean the organization is not just being examined by technicians and assessors. At some point, a responsible official is effectively standing behind the claim that the company continues to meet the required standard. That should change how leadership thinks about ownership. CMMC is not just an IT project. It is an organizational accountability issue. The Department's current CMMC materials make that annual affirmation requirement explicit across the levels.

For all the anxiety assessments can generate, there is a useful discipline hiding underneath them. They force organizations to move from assumption to evidence. A team may believe it has strong access control, solid logging, mature incident response, and good configuration management. An assessment asks a harder question: can you show it, explain it, and prove it in a way that holds together under scrutiny? That is a different standard. And honestly, it is often the more valuable one.

A simple table helps make the ecosystem easier to follow:

Another point worth making here is that certification is not the same thing as becoming secure forever. It is more like passing an inspection on a ship that still has to sail through weather. Systems change. Staff turnover happens. Tools get replaced. Admin privileges spread. New SaaS platforms appear. Mergers happen. Environments drift. An organization can absolutely pass an assessment and then erode its own posture six months later if it treats compliance as a finish line instead of an operating discipline.

That is one reason the annual affirmation requirement matters. It reinforces that CMMC is not supposed to be a point-in-time theater performance where everybody rehearses for the auditor and then goes back to normal. The intent is for the required practices to remain in place as part of normal operations. The Department's overview makes that expectation explicit across the levels. See the current Department CMMC overview.

This is also where industry concerns become more tangible. Assessment costs are real. Preparation costs are real. Documentation and remediation efforts can consume meaningful time and money, especially for small businesses that do not have a deep compliance bench. That tension is part of the current CMMC story. The Department wants more confidence, but industry has made clear that confidence is not free. The challenge for contractors is to approach certification intelligently, reduce unnecessary scope, and build evidence in parallel with implementation rather than waiting until the last minute.

In practical terms, that means companies should think about assessment readiness early. Not when the solicitation is already on the table. Not when the assessor is two weeks out. Early. They should know where FCI and CUI live, what their protected environment includes, which shared services are in scope, what policies and procedures govern that environment, how technical safeguards map to requirements, and what evidence exists to support each claim. The organizations that struggle most are often not the ones with the worst tools. They are the ones with the foggiest boundaries and the weakest documentation.

That is why the certification ecosystem matters. It is not just bureaucracy piled on top of cybersecurity. It is the mechanism the Department now uses to convert security claims into something contractually meaningful and independently checkable.

Once you understand how certification works on paper, the next question is where companies actually get into trouble. And in most cases, it is not because they have never heard of the controls. It is because scope, documentation, and operational reality are harder than they look.

The Hard Part Most Teams Underestimate

By the time a company gets this far into the CMMC conversation, most people assume the hard part is the controls.

It usually is not.

The hard part is scope. Then documentation. Then the stubborn, uncomfortable gap between what people think is happening and what is actually happening in the environment.

That is where things get real.

On paper, it sounds manageable enough. Identify the information, apply the safeguards, document the controls, prepare for assessment. Clean sequence. Reasonable verbs. But real environments are messy. Data shows up in places no one expected. Access paths multiply quietly. Shared services blur boundaries. One collaboration platform syncs with another. Admins inherit privileges they did not realize put them in scope. A backup system, an identity provider, a logging platform, or a ticketing workflow suddenly matters because it supports the systems that protect FCI or CUI. NIST SP 800-171 Rev. 3 is clear that the requirements apply not just to components that process, store, or transmit CUI, but also to components that provide security protection for those components. That is one reason scope expands so easily.

This is the part that reminds me of old accreditation work. A system almost never stays as small and self-contained as the first diagram suggests. You start with the clean picture. Then you trace identity. Then admin access. Then external integrations. Then laptops. Then mobile devices. Then logging. Then backups. Then the managed service provider. Then the place where someone exported data six months ago and forgot it was there. Suddenly the tidy little island on the whiteboard turns out to be a peninsula connected to half the coastline.

That is why scoping mistakes are so expensive. If you do not understand where FCI or CUI lives and what protects it, you cannot accurately define the assessment boundary. And if you cannot define the boundary, everything downstream gets weaker. Your control implementation story gets fuzzy. Your documentation gets inconsistent. Your evidence gets harder to defend. Your remediation plan becomes guesswork.

A table helps here:

Documentation is the second trap.

A lot of organizations are not starting from zero on security. They already have MFA. They already patch. They already restrict access. They already do some logging, some training, some incident response, some vulnerability management. The problem is not always absence. Often it is proof. The overview transcript hits this point repeatedly. If you do it, document it. If you say you do it, be prepared to show it. If the written policy says one thing and the daily practice says another, the paper will not save you.

That sounds obvious until you watch how many teams operate. Security knowledge lives in people's heads. Procedures are tribal. Admin actions are routine but not formally described. Someone knows how onboarding works, but no one has written it down cleanly. Someone knows which systems hold sensitive data, but the diagram is outdated. Someone knows the logs are reviewed, but there is no durable evidence that the review occurred. In day-to-day operations, that kind of informality can survive for a long time. In an assessment, it gets exposed very quickly.

And then there is the biggest problem of all: operational reality.

This is where compliance efforts go sideways. A company writes polished policies. It creates nice diagrams. It maps controls to statements. It builds an impressive document set. But underneath it, people are still sharing accounts, bypassing process, storing files in the wrong places, leaving old access in place, or relying on manual workarounds no one wants to talk about. The result is a dangerous split-screen. On the left, the official story. On the right, the real environment. The wider that gap gets, the more brittle the whole compliance effort becomes.

That is why CMMC is not just a documentation exercise and not just a tooling exercise either. It is an operating discipline. The organization has to know where sensitive information is, who touches it, what systems support it, what the required safeguards are, and how to prove those safeguards are actually functioning over time. Not in theory. Not in a slide deck. In reality.

There is also a cost dimension here that should be acknowledged plainly. One reason industry has pushed back on CMMC is that this kind of work is not cheap, especially for smaller firms. It is not just the assessment fee. It is the internal labor, the architecture decisions, the cleanup work, the documentation burden, the possible need for outside advisory support, and the discipline required to keep the environment from drifting after the initial push. That burden is real. It is one more reason companies should resist the temptation to make everything in scope if they do not have to.

The practical lesson is simple, even if the work is not. Keep the protected environment as small and intentional as possible. Know your data flows. Know your boundary. Know your admins. Know your shared services. Build evidence while you build controls. And do not let the official story get ahead of the operational truth.

Because in the end, most teams do not fail this kind of effort because they have never heard of the requirements. They fail because their environment is more tangled, their documentation is thinner, and their day-to-day habits are looser than they realized.

So if that is where companies usually get into trouble, where should they actually begin? The answer is not to read every document front to back and panic. It is to start in the right order.

Where to Start

The natural reaction to CMMC is to open ten browser tabs, download a stack of PDFs, and start absorbing acronyms until your eyes glaze over.

That is not the best place to begin.

The best place to begin is with your information. Before the controls, before the tooling, before the assessment choreography, you need to understand a simpler question: what government information do we actually handle, and where does it go? That sounds basic, but it is the question that quietly drives almost everything else. If you do not know whether you are handling FCI, CUI, or both, then the rest of the exercise becomes guesswork dressed up as planning.

So step one is not "become CMMC compliant." Step one is to identify the data and trace the flow. What comes into your environment? Where is it stored? Who accesses it? What systems move it? What services protect those systems? Email, file storage, endpoints, identity, collaboration tools, cloud platforms, backup platforms, ticketing systems, and admin pathways all start to matter once protected information enters the picture.

From there, the next move is scope.

This is where discipline pays off. The more intentionally you can limit where FCI or CUI lives, the more manageable the rest of the effort becomes. Not easy. Just manageable. A smaller, more clearly bounded environment is easier to secure, easier to document, easier to assess, and easier to maintain over time. A sprawling environment with unclear boundaries becomes a tax on everything. Architecture. Process. Documentation. Evidence. Cost.

That is why one of the smartest early moves a company can make is deciding what should be inside the protected environment and what should stay out of it.

A practical starting sequence looks like this:

There is another mistake worth avoiding here. Do not start by buying a pile of security tools and assuming they will solve the problem. Tools matter, of course. But CMMC is not a shopping list. It is a combination of architecture, governance, documented practice, technical safeguards, and evidence. A company can spend plenty of money and still remain poorly positioned if it does not understand its data flows, its scope, its responsibilities, and its weak spots.

This is one reason the NIST documents matter so much. NIST SP 800-171 Rev. 3 gives you the core security requirement set for protecting CUI in nonfederal systems and organizations, while NIST SP 800-171A Rev. 3 helps frame how those requirements are assessed. NIST SP 800-172 adds the enhanced requirements relevant to the top end of the model. Read them, yes. But read them with a map of your own environment in mind. Otherwise the material stays theoretical.

It also helps to be honest about your starting point.

Some companies are early and know it. That is fine. Some are farther along technically than they are procedurally. Some have decent security but weak documentation. Some have strong policies and surprisingly messy operations. Some have one team that understands the environment deeply and another that barely realizes what is in scope. There is no prize for pretending maturity you do not have. In fact, that usually makes the work slower, more expensive, and more embarrassing later.

A more useful posture is this: know what you know, know what you do not, and close the gap deliberately.

For many companies, especially smaller or newer defense tech firms, a sensible starting posture looks like this:

• keep the environment handling protected information as contained as possible
• centralize identity and access control
• enforce MFA and least privilege early
• know what endpoints and users are in scope
• document onboarding, offboarding, admin actions, logging, incident response, and vulnerability management
• maintain current diagrams and inventories
• avoid letting CUI leak into general-purpose collaboration sprawl
• build evidence as part of operations, not as a scramble before assessment

The bigger point is that CMMC readiness is not one giant motion. It is a sequence of smaller clarifying motions. Understand the data. Shrink the scope. Map the requirements. Fix the biggest gaps. Document the truth. Build evidence. Then assess.

That sequence is not glamorous, but it works.

And it also makes the whole topic less intimidating. Because once you stop viewing CMMC as a giant wall of compliance language and start treating it as a practical exercise in protecting sensitive information with discipline, the path becomes much easier to see.

Conclusion

CMMC is easy to misread.

From a distance, it can look like one more layer of defense bureaucracy. Another acronym. Another framework. Another stack of controls, assessments, attestations, and documentation requirements dropped into an already crowded world. And yes, some of that administrative weight is real. Industry has pushed back, especially on cost, complexity, and the burden placed on smaller firms. But if you strip away the jargon, the basic idea underneath CMMC is not hard to understand. The Department of War wants greater confidence that the companies handling sensitive government information can actually protect it, and not just claim they can. Current program guidance reflects exactly that logic through a tiered model tied to FCI, CUI, and higher-assurance needs.

That is why I find the topic more interesting the deeper I get into it. It is new to me in this specific form, but not new in spirit. Years ago on the industry side, there were already mandatory safeguards and contractual security expectations around defense work. Then I spent more than a decade on the government side, closer to mission systems, accreditation, security controls, risk decisions, and the practical reality of what it takes to get systems trusted to operate. Coming back to this from the contractor side, CMMC feels less like a completely foreign language and more like a familiar argument in a different dialect. The names are different. The mechanism is different. But the deeper theme is the same: when sensitive information is involved, trust has to be earned, structured, and demonstrated.

That is also why this should not be treated as a paperwork exercise. At its core, CMMC is about operational discipline. Knowing what information you handle. Knowing where it lives. Knowing who touches it. Knowing what protects it. And being able to prove that your environment works the way you say it works. NIST SP 800-171 Rev. 3, NIST SP 800-171A Rev. 3, and NIST SP 800-172 provide much of that backbone, giving the Department a more structured way to translate cybersecurity expectations into something assessable and contractually meaningful.

For companies new to this space, that may sound heavy. It is. But it is also manageable if approached in the right order. Start with the information. Understand the scope. Keep the protected environment intentional. Build controls and evidence together. Do not let policy drift away from reality. And do not assume that because something feels familiar, it is already handled well.

If this post does anything useful, I hope it lowers the fog a bit. Not by pretending CMMC is simple, because it is not, but by showing that it is legible. There is a structure to it. There is logic underneath it. And for teams that want to build in the defense space responsibly, understanding that logic is part of the job.

See the associated LinkedIn post.