Assess Guide

Every effective CMMC effort starts with an assessment—not as a formality, but as a foundation. DFARS requirements and NIST SP 800-171 make clear that organizations must assess their controls and generate a score. But beyond regulatory obligation, the assessment serves a more practical purpose: it defines your starting point.

Without it, you are operating on assumption.

A well-executed assessment reveals the gap between required controls and actual implementation across technical, procedural, and operational areas. It provides structure to what can otherwise feel like an overwhelming set of requirements and translates them into a set of identifiable deficiencies and potential corrective actions.

At this stage, the objective is straightforward: understand your current posture in relation to the CMMC framework.

If that understanding is incomplete or overly optimistic, everything that follows becomes less reliable. Organizations that move forward without a grounded assessment often find themselves revisiting earlier decisions—realigning tools, rewriting policies, or addressing gaps that were there from the beginning.

A thorough assessment, by contrast, creates alignment early. It allows you to define a path forward based on what is actually happening in your environment, not what is assumed to be happening.

Grounding Everything in CUI

As you assess your environment, one principle should guide your thinking: CMMC is centered on protecting Controlled Unclassified Information.

This is not simply an IT exercise. While many controls are technical, the framework itself is data-centric. The focus is not just on systems, but on the sensitive information those systems handle.

That makes understanding CUI essential.

In practice, this is rarely straightforward. CUI may be unmarked, inconsistently labeled, or embedded in workflows where it is not immediately obvious. In some cases, information may be clearly sensitive within a DOD context but less clearly defined within your own environment.

At this point, the goal is informed understanding, not perfect classification.

You should be able to identify:

• The types of information in your contracts that constitute CUI
• Where that information exists in your environment
• Who interacts with it and how

If you cannot clearly describe where CUI resides or how it is used, it becomes difficult to determine where controls should be applied. That uncertainty tends to carry forward into scoping, implementation, and ultimately assessment outcomes.

This is also where people become central to the process. The individuals who handle CUI, whether in business development, engineering, or operations, provide the context needed to understand how data actually moves. Their workflows define the environment more accurately than diagrams alone.

Aligning to NIST SP 800-171

With a clearer view of your data, the next step is aligning your environment to the required framework.

NIST SP 800-171 provides the structure for protecting CUI, and assessment against it spans more than just IT controls. It includes policies, procedures, physical safeguards, personnel considerations, and operational practices.

At this stage, you are not just identifying whether controls exist—you are evaluating how they function together.

A complete assessment considers:

• How controls are defined in policy
• How they are implemented in systems
• How they are executed in day-to-day operations

This broader view is what allows you to identify meaningful gaps. In some cases, the issue is technical. In others, it may be procedural or tied to how work is actually performed. If controls appear to exist but cannot be clearly tied to real-world processes, that is often an early indicator that further alignment is needed before moving forward.

Assessment as Investigation, Not Verification

As the assessment progresses, the approach matters as much as the outcome.

Effective assessments are not limited to verifying the presence of controls. They function as structured investigations into how those controls operate in practice. This is where NIST SP 800-171A becomes essential. It defines the assessment objectives that assessors will use, and each objective must be met to satisfy a control. In most cases, scoring does not allow partial credit—meaning gaps in a single objective can impact the entire control.

At this point, you should be able to do more than point to a tool or a policy. You should be able to explain and demonstrate how each requirement is met.

If the assessment process is limited to surface-level checks—confirming that something exists without validating how it operates—it can create a sense of confidence that may not hold up under formal evaluation.

A more thorough approach follows the data, engages with the people who use it, and validates implementation against real workflows. This depth is what distinguishes a preparatory assessment from one that meaningfully supports readiness.

Once your baseline is established, the next step is defining your scope. Scoping determines where CUI is processed, stored, and transmitted—and by extension, where controls must be applied. It translates your understanding of data into clearly defined environmental boundaries.

At this stage, the objective is to establish a defensible boundary around CUI.

This requires identifying:

• The systems and platforms that handle CUI
• The pathways through which CUI enters and exits your environment
• The people who interact with it across its lifecycle

If these elements are not clearly defined, scope tends to expand or contract in ways that create risk. Over-including assets can introduce unnecessary complexity, while under-including them can leave gaps that surface later in the process.

A well-defined scope reflects how CUI actually moves—not how it is assumed to move.

Following the Flow of CUI

The most reliable way to establish scope is to follow the flow of data. CUI may enter your environment through multiple channels—secure file transfers, email, portals, or physical media. It may be stored in cloud platforms, shared drives, or endpoints. It may then be transmitted to subcontractors, suppliers, or back to the DOD.

Each step in that flow introduces systems, tools, and processes that may fall within scope.

At this point, you should be able to trace that flow with reasonable clarity.

If key transitions, such as where data is stored or how it is shared, are not well understood, those gaps can affect both scoping and control implementation. This is also where cross-functional input becomes important. Different teams interact with CUI at different stages, and their perspectives help ensure that the full lifecycle is captured.

Applying Structure to Scope

As your understanding of data flow matures, your environment can be organized into asset categories that reflect how CUI is handled and protected.

Some assets will directly process or store CUI. Others will serve as security protections. Still others may be specialized or legacy systems that require contextual handling. Each category carries different expectations, but all must be understood in relation to the CUI dataset.

At this stage, clarity matters more than precision.

The goal is not to force every asset into a perfect category, but to ensure that nothing critical is overlooked and that your scope aligns with how your environment actually operates.

Common Scoping Challenges

As organizations define scope, certain challenges tend to emerge. In some cases, legacy systems or non-traditional platforms are not initially identified as in-scope, only to surface later when data flows are examined more closely. In others, external services—such as cloud storage or synchronization tools—introduce additional considerations tied to data movement.

These situations often arise not from misunderstanding the requirements, but from incomplete visibility into how systems and users interact with data. If scoping decisions are made without fully tracing those interactions, adjustments may be required later—sometimes at a point when changes are more difficult to implement.

With scope defined and gaps identified, the focus shifts to readiness.

At this stage, the question becomes: Can you demonstrate that your controls are implemented and operating as required?

This is where evidence becomes central. Following NIST SP 800-171A, each assessment objective requires proof—whether through documentation, system behavior, or records of activity. Without that proof, controls cannot be validated, regardless of intent.

Your System Security Plan (SSP) plays a key role here. It serves as the narrative that connects your environment, your controls, and your evidence. It should reflect how your organization meets each requirement in a way that aligns with assessment objectives. If your SSP cannot clearly support those objectives, it may be difficult to present a consistent and defensible position during an assessment.

Understanding What Evidence Looks Like

Evidence takes different forms depending on the objective. Some requirements call for defined policies or procedures. Others require demonstration of technical enforcement. Still others depend on records that show monitoring or review activities are taking place.

At this point, you should be able to answer a simple question for each control: What would I show an assessor to demonstrate this is working?

If the answer is unclear or incomplete, that often indicates an area where additional work is needed—either in implementation, documentation, or both.

This is also where alignment becomes important. Technical controls, written policies, and operational practices should reinforce one another. When they do not, gaps can appear even in environments that are otherwise well-equipped.

Where Implementation and Documentation Meet

A common pattern at this stage is the presence of strong technical controls without corresponding documentation.

For example, a system may enforce a requirement effectively, but if that requirement is not formally defined in policy, assessment objectives related to definition may not be satisfied. This illustrates a broader principle: controls must be both implemented and defined to be fully met. If one exists without the other, the result may not align with how controls are evaluated during an assessment.

Using POAMs to Drive Corrective Action

As gaps are identified, they are captured in Plans of Action and Milestones (POAMs).

POAMs serve as a structured way to track deficiencies and define the steps required to address them. They should clearly describe what is missing, what action is required, who is responsible, and when it will be completed.

At this stage, they function as a bridge between assessment and remediation.

However, it is important to recognize their role. POAMs do not represent compliance—they represent progress toward it. Their value comes from how clearly they define the path forward and how consistently they are maintained. If deficiencies are not documented or tracked, it becomes difficult to demonstrate that they are being addressed in a structured way.

Defining What Readiness Looks Like

CMMC readiness is not defined by effort alone. It is defined by the ability to confidently explain and demonstrate your environment.

At this point, you should be able to:

• Clearly define your scope and boundaries
• Explain how CUI flows through your environment
• Demonstrate implementation of applicable controls
• Support those controls with aligned evidence

If any of these areas remain unclear, it may indicate that additional refinement is needed before entering a formal assessment. Readiness is less about reaching a milestone and more about reaching a level of clarity where your environment can be consistently understood and defended.

CMMC as an Ongoing Practice

Even after readiness is achieved, the process does not end.

CMMC readiness is an ongoing process. Environments evolve, systems change, and data flows shift over time. Maintaining compliance requires ongoing attention to assessments, documentation, and evidence.

This includes:

• Updating SSPs to reflect current environments
• Maintaining and revising POAMs as needed
• Continuing to collect and validate evidence
• Periodically reassessing controls

These activities support not only initial certification, but future reassessments as well.

Across assessment, scoping, and readiness, the throughline is consistency between what is required and what is real.

Organizations that approach CMMC with a clear understanding of their data, a well-defined scope, and a disciplined approach to evidence are better positioned to navigate both assessment and certification.

If you are beginning this process or refining your approach, starting with a structured assessment and building forward from there provides a path that is both practical and defensible. For organizations looking for guidance along the way, working with experienced practitioners can help bring additional clarity to each stage of the process.

Contact CyberSheath for a consultation to understand the latest CMMC updates and, more importantly, how your business should respond to achieve documented, defensible evidence of compliance and obtain CMMC certification.