As a Certified CMMC Assessor (CCA), I want to pass along some vital information that can help an Organization Seeking Certification (OSC) achieve a successful outcome on its CMMC assessment journey. At 227 InfoSec, we created a three-part blog series, Tales from the Assessment, to give OSCs an insider’s look at what CMMC assessors see during actual assessments.

Part 1 of the series is Define and Identify.

The Most Common Failure We See

The most common failure we see in CMMC assessments is the OSC failing to clearly define or identify the items required by the first assessment objective of a control. If that foundation is unclear, the entire control collapses.

In too many assessments, it has become clear that organizations misunderstand what the words “define” and “identify” mean in the assessment objectives. That misunderstanding shows up in the System Security Plan (SSP) as a word-salad statement that neither the OSC nor the assessor can justify. The organization writes something that sounds correct in plain language, often following the familiar school pattern of repeating the question in the answer, only to have the assessor ask, “Where did you define or identify this?” The response is always the same: “We defined it in the SSP.”

To be clear, the SSP is a perfectly good place to define things. The problem is that the SSP statement doesn’t actually define anything. It contains a sentence about the definition instead of the definition itself.

“Define” vs. “Identify”: What Each Verb Asks For

Both verbs ask for something concrete, but they ask for different things:

• Define means the OSC makes a decision and writes down the specific value or set. Examples: the means of limiting unsuccessful logon attempts (3.1.8[a]), the period of inactivity before a session lock (3.1.10[a]), password complexity requirements (3.5.7[a]), essential system capabilities (3.4.6[a]), and essential programs, functions, ports, protocols, and services (3.4.7).
• Identify means the OSC enumerates things that already exist in its environment. Examples: authorized users, processes acting on behalf of authorized users, and devices (3.1.1[a]–[c]).

NIST SP 800-171A uses related verbs, such as “specified” for the audit event types to be logged (3.3.1[a]), and they work the same way. Whatever the verb, the answer is a concrete list or value, never a restatement of the objective.

What Assessors See

Here are two examples of statements assessors encounter during actual CMMC assessments. (Real SSPs use the company’s name; we’ve used “the OSC” here.)

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’s easy to see what the OSC is trying to convey, these statements miss the assessment objectives entirely. How does the first statement support assessment objective 3.4.6[b]? The short answer: it doesn’t. To meet 3.4.6[b], the system is configured to provide only the defined essential capabilities, both the OSC and the assessor must know what those essential capabilities are and how they were chosen based on least functionality. Likewise, “all staff” gives the assessor nothing to compare against when testing 3.1.1[d], system access is limited to authorized users.

So what are assessors looking for when they review assessment objectives with “define” and “identify” actions? The actual items: a list, table, inventory, or specific value, written directly in the SSP or in a referenced document or system, that the assessor can use to determine whether the OSC limited, controlled, or monitored those items in its implementation.

Why This Matters: The Assessor’s Logic Chain

Every control that includes a “define” or “identify” action sets the stage for the assessment objectives that follow. Assessors use three methods: they examine documentation, interview personnel, and test the system. Your definition is what the assessor examines. Your configuration is what the assessor tests against it. If there’s nothing concrete to test against, the chain breaks.

1. First, create a clear foundation by identifying or defining something specific: a definition, list, table, spreadsheet, or system display that clearly and unambiguously states the items on which the OSC has built the control.
2. Second, use that foundation to support the implementation of the remaining assessment objectives.

Let’s fix both examples so the 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.

SSP Example:

ACME Corp. defines the following essential system capabilities for the two authorized roles that access CUI. Capabilities were selected based on the minimum each role requires to perform its job functions. All capabilities not listed are disabled or restricted.

Non-Privileged Users	Privileged Users
Access Productivity and Business Tools • Read and create documents using Word or equivalent • Read and create spreadsheets using Excel or equivalent • Read and create presentations using PowerPoint or equivalent • PDF reader access • Email client and calendar access • Web browser access for approved business websites	Perform System Administration • Create, modify, and disable user accounts • Manage group memberships • Reset user passwords • Create and manage security groups • Review system logs and audit records
Access Communication and Collaboration • Microsoft Teams or approved communication platform • Company messaging system • Internal SharePoint portals or approved file repositories • Access to ticketing or workflow systems as required by job role	Perform Device and Configuration Management • Apply Group Policy or configuration profiles • Configure and deploy endpoint security tools • Install and configure approved software • Execute administrative PowerShell commands • Modify approved firewall or network rules • Configure system services and startup controls
System Interaction • Log in and authenticate to the workstation • Lock and unlock a session • Change user password • Access approved mapped network drives • Access permitted printers • Receive updates only when delivered by centralized IT management (Intune, RMM, etc.)	Perform Patch and Update Management • Deploy operating system and application updates • Approve or reject patches in the centralized patching system • Manage update rings or deployment profiles • Validate patch compliance

Now it’s clear that ACME Corp. has defined its essential system capabilities, and it has tied them to least functionality by calling out each role and stating that everything else is disabled or restricted. The assessor now has what they need to correctly assess 3.4.6[b], the system is configured to provide only the defined essential capabilities, by comparing this table against what the system actually allows.

Example #2

3.1.1[a] authorized users are identified.

SSP Example:

ACME Corp. identifies its authorized users in the roster below. The authoritative source is the CUI-Authorized-Users security group in Entra ID; the roster is exported from that group and reviewed quarterly.

Name	Job Role	Account(s)	Account Type
Jane Smith	Design Engineer	jsmith	Standard
Carlos Rivera	Program Manager	crivera	Standard
Mark Lee	IT Administrator	mlee mlee-adm	Standard Privileged

With this roster, the assessor can test 3.1.1[d] by comparing the identified users against the accounts that actually exist and can sign in. Any account not on the list is a finding waiting to happen.

When the Foundation Is Missing

Assessors rely on this foundation because CMMC is evidence-driven. It’s about assessing whether the OSC’s implementation is adequate and sufficient to support the control. When definitions and identifications are vague, the assessor can’t evaluate the controls as implemented, because the starting point isn’t known. If authorized users aren’t identified, it’s impossible to confirm that only those users have access. If essential ports aren’t defined (3.4.7), how can anyone tell whether an open port 7777 belongs to a business application or to an infostealer like RedLine calling home?

At its core, this issue isn’t about paperwork. It’s about clarity, traceability, and accountability. When organizations clearly define and identify the items a control references, they demonstrate that they understand their environment and can manage it effectively. When they don’t, they leave critical gaps the assessor can’t bridge. That’s why the first step in each control isn’t just a formality. It’s the key to everything that follows.

Key Points Every OSC Must Put into Practice Before Its Assessment

1. Define or identify the item explicitly. Provide the actual items: a definition, list, table, inventory, report, or specific value, written in the SSP or in a referenced document or system.
2. Explain how you enforce or implement the defined items. Connect your implementation directly to what you identified or defined.
3. Provide evidence that the implementation matches the definition. Screenshots, configuration exports, logs, and system outputs.
4. Keep the definition, the SSP, and the configuration consistent. The assessor will compare all three, and any mismatch becomes a question you have to answer.

Final Takeaway

Most failures on “define” or “identify” assessment objectives happen not because the OSC lacks technical controls, but because the OSC never actually defines or identifies the items those technical controls support. When assessors evaluate an assessment objective with a “define” or “identify” prompt, they aren’t looking for concepts or statements that repeat the objective. They’re looking for lists, values, names, and explicit definitions they can use to assess the OSC’s implementation.

If there’s one message to carry forward, it’s this:

If the assessment objective includes the verb “define” or “identify,” provide the actual definition, list, table, or value, or point to the system that contains it. A sentence that restates the assessment objective will not support the subsequent objectives.

-Lamar Clapham

Watch for Part 2 of Tales from the Assessment. Preparing for a CMMC assessment? Contact 227 InfoSec to talk with our team.