{"id":79546,"date":"2026-10-28T06:32:33","date_gmt":"2026-10-28T06:32:33","guid":{"rendered":"https:\/\/www.devopsschool.com\/blog\/?p=79546"},"modified":"2026-10-28T06:32:35","modified_gmt":"2026-10-28T06:32:35","slug":"cmmc-for-defense-suppliers-understand-fci-cui-assessment-levels-and-the-evidence-you-actually-need","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/blog\/cmmc-for-defense-suppliers-understand-fci-cui-assessment-levels-and-the-evidence-you-actually-need\/","title":{"rendered":"CMMC for Defense Suppliers: Understand FCI, CUI, Assessment Levels, and the Evidence You Actually Need"},"content":{"rendered":"\n

A manufacturer bids on a U.S. defense contract and receives controlled engineering drawings. The drawings are not necessarily classified, but disclosure or tampering could still create major risks. The company cannot decide its cybersecurity obligations by installing a firewall and declaring itself ‘mature.’ Its obligations come from the contract<\/strong>, the information involved, and the applicable federal cybersecurity requirements.<\/p>\n\n\n\n

The Cybersecurity Maturity Model Certification (CMMC)<\/strong> program is the U.S. Department of Defense’s assessment model for safeguarding Federal Contract Information (FCI) and Controlled Unclassified Information (CUI) in the defense industrial base. Despite its name, the current program’s three levels are sets of defined safeguarding and assessment obligations<\/strong>, not a generic five-step enterprise process maturity model.<\/p>\n\n\n\n

Read this status note before planning an assessment<\/h2>\n\n\n\n

The Department announced on July 13, 2026<\/strong> that it had suspended Phase II CMMC implementation<\/strong>, previously scheduled to begin November 10, 2026. Phase I self-assessment requirements remain in place.<\/strong> The Department also initiated a review of the program. The suspension does not remove underlying contractual information-protection requirements, including applicable DFARS safeguarding provisions and NIST SP 800-171 obligations. Verify the latest agency guidance, solicitation language, contract modifications, and instructions before claiming that a specific third-party assessment is currently mandatory or waived.<\/p>\n\n\n\n

This distinction is essential: the CMMC three-level model<\/strong> remains important for understanding security expectations, but the rollout phase and currently enforceable assessment form<\/strong> depend on up-to-date agency action and the contract.<\/p>\n\n\n\n

Understand FCI and CUI first<\/h2>\n\n\n\n

Federal Contract Information (FCI)<\/strong> is information provided by or generated for the government under a contract to develop or deliver a product or service, not intended for public release, within the regulatory definition and its exclusions. Controlled Unclassified Information (CUI)<\/strong> is information subject to specific safeguarding or dissemination controls under applicable government authority and marking\/handling rules. Do not guess that every internal document is CUI or that anything without a banner is safe to disclose. Work with your contract owner and the information owner to determine status.<\/p>\n\n\n\n

Program level<\/th>Underlying requirements<\/th>General focus<\/th><\/tr><\/thead>
CMMC Level 1<\/td>15 safeguarding requirements drawn from FAR 52.204-21<\/td>Basic protection of FCI<\/td><\/tr>
CMMC Level 2<\/td>110 requirements from NIST SP 800-171 Revision 2 in the CMMC assessment model<\/td>Protection of CUI<\/td><\/tr>
CMMC Level 3<\/td>24 selected NIST SP 800-172 requirements in addition to Level 2’s 110<\/td>Enhanced protection for especially sensitive circumstances<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

The original assessment design included Level 1 annual self-assessment, Level 2 self-assessment or third-party assessment depending on the contract, and Level 3 government-led assessment. Do not copy the original implementation schedule into a current compliance plan without accounting for the suspension.<\/strong> DoD guidance has permitted certain organizations to implement NIST SP 800-171 Revision 3 while CMMC assessment mapping continues to reference Revision 2 under applicable transition instructions. Confirm the required baseline and any organization-defined parameters in official guidance.<\/p>\n\n\n\n

Think in terms of a protected information enclave<\/h2>\n\n\n\n

A contract may require a specific safeguard for the systems that process covered information. A small supplier can reduce unnecessary exposure by determining where FCI\/CUI are received, stored, processed, discussed, backed up, and transmitted. The environment could include engineering workstations, identity providers, file sharing, cloud systems, email, printers, remote support, contractors, and subcontractors.<\/p>\n\n\n\n

Controlled exchangesGovernment \/ prime contractorAuthorized information intakeDefined FCI\/CUI environmentApproved engineering workstationsApproved storage and backupsIdentity, access, audit controlsAuthorized subcontractor flowdownExternal providers under contractual requirements<\/pre>\n\n\n\n
The drawing is illustrative, not a CMMC-approved architecture. System boundaries should be established using the applicable official scoping guidance and information flows; real-world assets may be categorized differently based on their roles and security effects.<\/p>\n\n\n\n
A step-by-step implementation approach<\/h2>\n\n\n\n
Step 1. Identify contractual requirements<\/h3>\n\n\n\n
Review FAR\/DFARS clauses, contract statements, flowdown obligations, government marking instructions, and the current CMMC status required for the bid or performance. Assign a contract owner to document interpretation. Never assume one customer’s requirements apply to every contract.<\/p>\n\n\n\n
Step 2. Inventory covered information and assets<\/h3>\n\n\n\n
Classify information according to authoritative instructions. Diagram entry and exit points, authorized users, local and cloud storage, email attachments, engineering systems, and external service providers. Identify where sensitive data can be replicated into backups, logs, support tools, endpoints, and unmanaged collaboration spaces.<\/p>\n\n\n\n
Step 3. Build the System Security Plan (SSP)<\/h3>\n\n\n\n
An SSP explains the covered system’s boundary, environment, connections, owners, applicable safeguards, and how each security requirement is implemented. Avoid a generic ‘NIST compliant’ statement. A useful entry names the tool, responsible owner, configuration standard, actual activity, and evidence.<\/p>\n\n\n\n
Example (synthetic, not an official template):<\/p>\n\n\n
system: northstar-defense-engineering-enclave\ninformation<\/span>: example-controlled-engineering-content\nboundary<\/span>:\n  - managed-engineering-workstations\n  - approved-project-storage\n  - enterprise-identity-service\n  - protected-backup-system\ncontrol_example<\/span>:\n  topic: unique-user-identification\n  owner<\/span>: identity-team\n  implementation<\/span>: individual-accounts-with<\/span>-managed-authentication\n  evidence<\/span>:\n    - approved-account-roster\n    - current-identity-configuration\n    - recent-offboarding-records\nassessment_status<\/span>: evidence-review-required\n<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Step 4. Implement safeguards and collect evidence<\/h3>\n\n\n\n
Map every applicable requirement to a current implementation and an authorized test. Common workstreams include identity and access control, MFA where applicable, endpoint hardening, audit logs, incident response, configuration management, physical security, media protection, training, risk assessment, system integrity, and secure communications.<\/p>\n\n\n\n
A requirement is not met simply because the policy mentions it. Establish operating procedures, configuration evidence, approvals, and regularly tested outcomes. Ensure evidence storage itself meets contractual handling restrictions.<\/p>\n\n\n\n
Step 5. Assess honestly and manage deficiencies<\/h3>\n\n\n\n
Use the applicable DoD assessment guide and methodology for the required program level. Validate requirement assessment objectives with evidence and authorized tests. Plans of Action and Milestones (POA&Ms) have restricted uses and conditions<\/strong> under CMMC; Level 1 does not permit POA&Ms for its final status. Do not treat unresolved deficiencies as permissible solely because a ticket exists.<\/p>\n\n\n\n
Where applicable, ensure assessment results, organizational affirmations, and submission to the Supplier Performance Risk System (SPRS)<\/strong> follow current official instructions. Do not invent or casually estimate an SPRS score; use the prescribed scoring methodology and assessment process.<\/p>\n\n\n\n
Step 6. Verify cloud and subcontractor obligations<\/h3>\n\n\n\n
Cloud contracts need particular attention. For covered defense information under DFARS 252.204-7012, relevant external cloud providers must meet the contract’s FedRAMP Moderate-equivalent security requirement and incident-reporting-related conditions. A marketing statement such as ‘hosted on a major cloud’ is not enough to establish every contractual obligation.<\/p>\n\n\n\n
Obtain provider security evidence, define inherited and shared controls, and ensure flowdown of necessary protection and reporting requirements to relevant subcontractors. Check the precise obligations of your contract and the services actually used.<\/p>\n\n\n\n
Hands-on lab: Find missing evidence without touching real CUI<\/h2>\n\n\n\n
Use the synthetic cmmc_evidence_lab.py<\/code> file below. It checks whether representative requirements have named owners, documented implementation, and evidence references. It does not compute an official CMMC or SPRS score.<\/p>\n\n\n
requirements = [\n    {\"id\"<\/span>: \"training-01\"<\/span>, \"owner\"<\/span>: \"HR\"<\/span>, \"implementation\"<\/span>: True<\/span>, \"evidence\"<\/span>: [\"training-records\"<\/span>]},\n    {\"id\"<\/span>: \"accounts-01\"<\/span>, \"owner\"<\/span>: \"IAM\"<\/span>, \"implementation\"<\/span>: True<\/span>, \"evidence\"<\/span>: []},\n    {\"id\"<\/span>: \"incident-01\"<\/span>, \"owner\"<\/span>: \"Security\"<\/span>, \"implementation\"<\/span>: False<\/span>, \"evidence\"<\/span>: []},\n]\n\nfor<\/span> item in requirements:\n    complete = bool(item[\"owner\"<\/span>] and<\/span> item[\"implementation\"<\/span>] and<\/span> item[\"evidence\"<\/span>])\n    print<\/span>(f'{item[\"id\"]}: {\"review-ready\" if complete else \"gap to investigate\"}'<\/span>)\n<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\n
Run python3 cmmc_evidence_lab.py<\/code> or py -3 cmmc_evidence_lab.py<\/code>. The account and incident samples should be flagged. Next, assign an owner and an evidence artifact without putting actual government information into this training folder.<\/p>\n\n\n\n
For a real program, replace placeholder labels with exact requirement and assessment-objective identifiers from the applicable official guide. Evidence completeness is not equivalent to passing an assessment objective.<\/strong><\/p>\n\n\n\n
Audit readiness and operational discipline<\/h2>\n\n\n\n
Assessment artifact<\/th>Why it matters<\/th><\/tr><\/thead>
Contract and information-classification analysis<\/td>Determines actual obligations<\/td><\/tr>
Current scoping and data-flow diagrams<\/td>Supports defensible assessment boundary<\/td><\/tr>
System Security Plan<\/td>Explains safeguards as implemented<\/td><\/tr>
Requirement-to-evidence matrix<\/td>Demonstrates implementation and testing links<\/td><\/tr>
POA&M records where permitted<\/td>Tracks deficiencies within applicable limits<\/td><\/tr>
Incident response and provider records<\/td>Supports safeguarding and reporting duties<\/td><\/tr>
Current official assessment and affirmation status<\/td>Prevents outdated award representations<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
A well-maintained program includes vulnerability management, user offboarding, identity reviews, incident practice, secure configuration changes, and supplier oversight after the assessment window. Protecting CUI is a continuing contractual responsibility, not merely a paperwork milestone.<\/p>\n\n\n\n
Mistakes defense suppliers must avoid<\/h2>\n\n\n\n