Tales from the Assessment, Part 1
What CMMC Assessors Are Really Looking For in Defined and Identified Controls.
As a CCA, I wanted to pass along some vital information that may help an OSC experience a successful outcome with their CMMC assessment journey. At 227 InfoSec, we decided to provide a 3-part blog series called “Tales from the Assessment” to give OSCs an insider’s look at what CMMC assessors are seeing during actual assessments.
The most common failure in CMMC assessments is that OSCs do not clearly define or identify the items required in the first assessment objective. If the foundation is unclear, the entire control collapses.
In too many assessments, it has become very clear that organizations misunderstand the meanings of the words “Define” and “Identify” in the Assessment Objectives. This misunderstanding manifests itself in the OSC’s SSP as some word salad statement that neither the OSC nor the assessor can justify. While the organization writes something that sounds correct in plain language, often following a familiar school pattern of repeating the gist of the question in the answer, only to have the assessor ask, “Where did you define or identify this assessment objective?” The response is always the same: “We defined it in the SSP”. Here are a couple of examples of what assessors see during actual CMMC assessments.
Example #1:
3.4.6[a] essential system capabilities are defined based on the principle of least functionality
“The OSC defines least functionality as the limited essential system capabilities provided to the user.”
Example #2:
3.1.1[a] authorized users are identified
“Authorized users are identified as all staff within the OSC.”
While it is easy to see what the OSC is attempting to convey here, these statements miss the assessment objectives entirely. How does the first example write-up support the assessment objective 3.4.6[b]”? The short answer is that it does not. To meet “3.4.6[b] the system is configured to provide only the defined essential capabilities”, the OSC and the assessor must know what those essential capabilities are and how they are based on the least functionality.
So, what are assessors looking for when they review assessment objectives with the “define” and “identify” actions? Assessors are looking for lists, tables, spreadsheets, or systems that provide a tabular format of the data, so that the assessor can use those lists, tables, spreadsheets or systems to determine if the OSC limited, controlled, or monitored them in their implementation.
Why This Matters: The Assessor’s Logic Chain
Every control that includes a defined or identified action sets the stage for the subsequent assessment objectives. The first step is creating a clear foundation by identifying or defining something specific. This is a list, table, spreadsheet, or system display that clearly and unambiguously states that the items illustrated are the foundation on which the OSC has constructed the control. The second step is using that clear foundation to support the implementation of assessment objectives. Let’s review our examples and make them more explicit so that the subsequent assessment objectives that rely on them can be met.
Example #1:
3.4.6[a] essential system capabilities are defined based on the principle of least functionality
The ACME Corp. defines the following essential system capabilities for our two authorized roles that access CUI.
Non-Privileged User | Privileged Users |
Access Productivity and Business Tools• Read and create documents using Word or equivalent | Perform System Administration• Create, modify, and disable user accounts |
Access Communication and Collaboration• Microsoft Teams or approved communication platform | Perform Device and Configuration Management• Apply Group Policy or configuration profiles |
System Interaction• Log in and authenticate to the workstation | Perform Patch and Update Management• Deploy operating system and application updates |
ETC…. | ETC…. |
Now it should be very clear that ACME Corp has defined the essential system capabilities, and they have done this based on the least functionality, by explicitly calling out the two roles. The assessor now has the tools to correctly assess 3.4.6[b] the system is configured to provide only the defined essential capabilities.
Assessors rely on this foundation because CMMC is evidence-driven. It is about assessing whether the OSC implementation is adequate and sufficient to support the control. When definitions and identifications are vague, the chain breaks. The assessor cannot evaluate the controls as implemented if the starting point is not known. For example, if authorized users are not identified, it is impossible to confirm that only those users have access. If essential ports are not defined, how can the assessor correctly assess if port 7777 is needed or if this is the Redline Stealer C2.
At its core, this issue is not about paperwork. It is about clarity, traceability, and accountability. When organizations clearly define and identify the items referenced in a control, they demonstrate that they understand their environment and can manage it effectively. When they do not, they leave critical gaps that the assessor cannot bridge. This is why the first step in each control is not just a formality. It is the key to everything that follows.
Key Point that every OSC must know and put into practice before their assessment.
1) Define or identify the item explicitly
Use lists, tables, reports, inventories, or specific numerical values
2) Explain how you enforce or implement the defined items
Connect your implementation directly to what you identified or defined
3) Provide evidence showing the implementation matches the definition
Screenshots, configuration exports, logs, system outputs
Final Takeaway
Most failures in Define or Identify AOs occur not because the OSC lacks technical controls, but because the OSC never actually defines or identifies the items that the technical controls support. When assessors evaluate an assessment objective with a “define” or “identify” prompt, they are not looking for concepts or vague statements that merely repeat the assessment objective. They are looking for lists, values, names, and explicit definitions that can be used to assess the OSC implementation.
– Lamar
“Remember, kiddies… in CMMC, nothing is scarier than an SSP with no definitions.”
Many organizations misunderstand what the CMMC Assessment Objectives mean when they use the terms defined or identified. This misunderstanding makes it difficult for assessors to verify implementation and often leads to negative findings.
This post explains how assessors interpret these requirements, why lists and tables matter, and how the define/identify Assessment Objective affects the entire control.
Define or identify items using specific lists or values
Avoid conceptual statements that restate the control language
Use tables, inventories, or system outputs to show explicit detail
Link implementation AOs directly to what was defined or identified
