CMMC System and Communications Protection: Build the Evidence

CMMC System and Communications Protection evidence is not a network diagram and an encryption setting. It is proof that every CUI path, boundary rule, cryptographic module, session control, device restriction, and blocked route matches the system that is operating now.

A clean diagram can hide an open firewall rule. A TLS label can hide the wrong module, mode, certificate, or operating environment. A split tunnel policy can look strict until a remote device reaches an unapproved external route. That is where confidence breaks.

The practical job is to connect six things: defined scope, live implementation, operating history, accountable owners, repeatable tests, and current evidence. If those records disagree, the family is not ready for an honest assessment decision.

Use the CMMC Compliance hub for the full program, the Security Protection Asset guide for the tools and people that defend the boundary, and the Access Control evidence guide for the identities and rights allowed through it. The assessment evidence guide explains the objective method. GS Consulting supports this work through secure AI automation and evidence engineering.

CMMC System and Communications Protection: The Short Answer

Start with every place CUI enters, leaves, rests, or crosses a trust boundary. Map external interfaces, key internal boundaries, public services, remote paths, cloud services, provider connections, collaborative devices, mobile code, voice services, and the systems that manage cryptographic keys.

For each applicable objective, identify the approved design and owner. Then point to the live configuration, the operating record, the person who can explain it, and the test that demonstrates the expected protected or blocked result.

The official potential objects are selectable examples. They are not a universal file checklist. Use the smallest current evidence set that lets a reviewer trace the CUI path, observe the live control, question the operator, reproduce the test, and reach the same result.

Check the Current CMMC and Cryptographic Status

Program timing and a contract obligation are separate questions. On July 13, 2026, the DoD CMMC Resources and Documentation page announced that Phase II requirements were suspended while Phase I self assessment requirements remained in place. That direction can change.

The current solicitation, contract, subcontract, modification, required level, CUI path, affirmation duty, and customer direction still control the work for a specific award. Read them with DFARS 252.204-7021 and 32 CFR Part 170.

September 21, 2026 is also the published final day that active FIPS 140-2 modules can be used for new systems. The NIST Cryptographic Module Validation Program says those certificates move to the Historical List after this date and remain available for existing systems under the transition guidance. Verify certificate status, module version, approved mode, product mapping, operating environment, contract terms, and customer direction before reaching a conclusion.

Use Examine, Interview, and Test as One Standard

The CMMC Level 2 Assessment Guide, version 2.13, uses three methods across the family:

• Examine. Review policies, procedures, plans, diagrams, rules, settings, module records, key records, logs, tickets, reviews, exceptions, and other current artifacts.
• Interview. Ask the architects, administrators, security staff, data owners, remote access owners, cryptographic owners, device operators, and provider contacts to explain the actual work.
• Test. Exercise the mechanism or process and compare observed traffic, protection, termination, indication, block, or recovery behavior with the expected result.

The three methods should tell one story. The diagram shows a boundary. The live rule permits only the approved service. The change record identifies the owner and basis. Monitoring shows the path over time. The administrator explains the exception process. A test proves required traffic succeeds and an unapproved route is denied.

Original Research: The GS Evidence Pressure Index

GS Consulting built a planning model for one decision: which System and Communications Protection requirements deserve the earliest evidence work?

The model covers all 16 current Revision 2 requirements. It uses four public features from the official NIST supplemental assessment procedures: objective count, potential examine object mentions, potential interview candidate mentions, and potential test candidate mentions. GS added two ratings from one through five: operating volatility and scope spread.

The base weights are 25 percent for objective breadth, 15 percent for examine breadth, 10 percent for interview coordination, 10 percent for test breadth, 20 percent for operating volatility, and 20 percent for scope spread. Public counts are normalized to the family maximum. GS ratings are normalized to five. The sum is reported on a zero through 100 scale.

Boundary protection ranks first at 93.3. CUI data in transit follows at 74.0. Security engineering scores 72.9. Mobile code reaches 70.8, deny by default reaches 70.1, and collaborative device control reaches 70.0. These are evidence sequencing signals, not official risk ratings or assessment scores.

The sensitivity case moves five points from objective breadth to scope spread. Boundary protection remains first. No score moves more than 4.4 points, and the leading requirements remain concentrated in the same operating concerns. This limited test checks one weight choice. It does not predict labor, cost, failure probability, or CMMC status.

Operate the 16 Requirements Through Six Protection Lanes

A numbered requirement list is accurate but hard to run. Six lanes expose the evidence dependencies without changing the official structure.

• Boundaries and flows. External and key internal boundaries, interfaces, CUI routes, monitoring, and control.
• Architecture and separation. Security design, management functions, shared resources, public systems, and approved changes.
• Network trust decisions. Deny by default rules, permitted exceptions, split tunnel restrictions, and connection state.
• Cryptography and keys. CUI in transit and at rest, module status, approved mode, certificates, keys, and lifecycle records.
• Sessions and devices. Connection termination, session authenticity, collaborative device control, and indication.
• Mobile code and voice. Approved code types, execution rules, voice paths, monitoring, exceptions, and closure.

Keep the official objective identifiers in the crosswalk. The lanes are an operating view for assigning owners, reconciling systems, collecting records, designing tests, and spotting evidence that supports several objectives.

A Boundary Diagram Must Reconcile to Live Rules

Start with the system and CUI flow maps. Name every external interface and the key internal boundaries that separate users, management functions, public services, sensitive workloads, providers, remote access, and shared infrastructure.

Then reconcile the picture with live firewall rules, cloud controls, routes, gateways, security groups, proxies, private links, virtual networks, service endpoints, and segmentation mechanisms. Record the default action, each permitted exception, source, destination, service, owner, business basis, review date, and expiration.

Architecture evidence should explain how security engineering principles appear in the real design. It should also show how user functions stay separate from system management, how shared resources prevent unintended transfer, and how public components remain physically or logically separated from internal networks.

A diagram without a rule register is intention. A rule register without a diagram is a pile of local decisions. The evidence packet needs both, tied to the same stable components and change records.

Prove Required Traffic and Deny the Unapproved Route

Deny by default and allow by exception should be visible in configuration and behavior. Select representative paths that matter to the CUI environment. Include approved user traffic, management traffic, provider traffic, monitoring, updates, backups, and remote access.

For each path, state the expected source, destination, service, identity or device condition, protection, logging, and failure behavior. Then test an approved route and an unapproved route. Capture the observed decision, timestamp, rule, event, evidence source, defect, correction, and retest.

Split tunneling deserves a real device test. A policy setting can be present while another adapter, route, browser feature, virtual machine, or local service creates a second external path. Test the exact remote access architecture, not an abstract policy statement.

Coordinate any activity that can block production traffic, lock out administrators, trigger alerts, or affect customer services. Use a change window and approved test information. Good evidence does not justify reckless testing.

A Protocol Name Is Not Cryptographic Evidence

For every protected CUI path, name the data, source, destination, protocol, module, module version, approved mode, validation certificate, product mapping, operating environment, configuration owner, and current certificate status.

Do the same for CUI at rest. The proof should identify the device, database, file store, backup, removable media, or cloud service where protection applies. It should show the module and mode that actually protect the data, not only a product marketing statement.

Key management evidence should cover generation, custody, distribution, storage, rotation, recovery, revocation, disposal, and exceptions. A certificate inventory is not a key lifecycle record. A key vault screenshot is not proof that every application uses the approved key and mode.

Track FIPS 140-2 and FIPS 140-3 status as an operating dependency. Certificate status, product version, deployment mode, provider change, and system expansion can alter the conclusion. Build a review trigger instead of treating cryptographic validation as a one time procurement fact.

Do Not Leave Sessions, Devices, Code, and Voice Implicit

Connection termination evidence should state the inactivity period or defined condition, the affected service, the enforcement point, the event record, and the test result. Session authenticity proof should identify the mechanism that protects the session from impersonation or takeover.

Collaborative devices need an inventory and a control statement. Show how remote activation is prohibited and how people present at the device receive an indication that a camera, microphone, or related capability is in use. Test both the approved function and the blocked activation condition.

Mobile code and voice services often disappear into accepted technology. Name the allowed code types, approved execution conditions, monitoring, change process, exceptions, and owner. For voice services, trace the service, route, administration, monitoring, and incident path that protects the assessed environment.

Temporary exceptions must expire. Record the reason, scope, owner, approval, compensating action, start, end, monitoring condition, and closure result. An exception with no end condition becomes the permanent architecture without a design decision.

Build the Evidence From the CUI Path Outward

Begin with the CUI and protection data. Trace every entry, exit, store, remote path, public service, provider, device, and cryptographic boundary. Define the interfaces, allowed traffic, separated functions, approved protocols, module versions, modes, and owners.

Capture current implementation from authoritative sources. Export rules and configurations. Reconcile diagrams. Map certificates and modules. Preserve changes, reviews, denials, sessions, device use, code use, voice events, alerts, exceptions, and provider actions.

Run tests that prove expected and blocked behavior. A useful test record states the objective, scenario, starting condition, expected result, actual result, source, timestamp, affected version, defect, correction, retest, and approver. Review drift and update the SSP, diagrams, inventory, and packet before approval.

Six Evidence Failures That Weaken Confidence

1. Diagram without live rules. The boundary looks clean while the firewall, route, or service permits another path.
2. Encryption named without the module. A protocol label replaces module, version, approved mode, certificate, and environment evidence.
3. Keys without lifecycle records. Generation, custody, rotation, recovery, revocation, and disposal cannot be traced.
4. Split tunnel trusted by policy. The team never tests whether a remote device can use another external route.
5. Collaborative devices left implicit. Camera, microphone, or conferencing activation has no indication, block, or review proof.
6. Exceptions never expire. Temporary traffic, service, code, voice, or device paths become the permanent design.

A 45 Day Protection Evidence Plan

Days 1 through 7: confirm scope and owners

Review the contract, current program direction, required level, CUI flow, asset categories, provider connections, and public services. Assign one accountable owner and one operator for each protection lane.

Days 8 through 15: build the objective crosswalk

Map all 41 objectives to the implementation statement, source evidence, interview role, test scenario, owner, period, and current result. Record any justified not applicable determination with the scope facts that support it.

Days 16 through 25: reconcile diagrams and live implementation

Collect boundary rules, routes, segmentation, remote paths, public systems, module records, key records, session controls, device controls, code rules, and voice paths. Correct stale identifiers and unexplained differences through normal change control.

Days 26 through 35: collect history and run safe tests

Preserve changes, reviews, sessions, denials, alerts, exceptions, provider actions, and corrective work. Exercise representative protected and blocked paths. Capture exact versions, dates, results, defects, corrections, and retests.

Days 36 through 45: rehearse retrieval and close drift

Have each operator explain the control from the authoritative source. Ask an independent reviewer to request evidence by objective. Repair broken links, stale exports, missing context, weak ownership, and failed tests. Approve the current package.

The Minimum Communications Protection Evidence Packet

1. Boundary and CUI flow map. External and internal boundaries, stores, transfers, providers, public systems, and remote paths.
2. Objective crosswalk. All 41 objectives linked to current examine, interview, and test evidence.
3. Architecture and separation record. Security design, management plane, shared resources, public components, and approved changes.
4. Network rule register. Default action, permitted exception, source, destination, service, owner, basis, review, and expiry.
5. Cryptographic inventory. CUI path, module, version, approved mode, certificate, environment, product mapping, and current status.
6. Key lifecycle record. Generation, custody, distribution, storage, rotation, recovery, revocation, disposal, and exceptions.
7. Operating history. Rule changes, sessions, denials, device use, code use, voice events, alerts, reviews, and exceptions.
8. Protection test record. Scenario, expected result, actual result, evidence, defect, correction, retest, date, and approval.

Research Sources, Method, and Caveat

The research package uses the DoD CMMC Resources and Documentation page, the CMMC Level 2 Assessment Guide, version 2.13, the CMMC Level 2 Scoping Guide, version 2.13, 32 CFR Part 170, and the NIST SP 800-171A Revision 2 publication page.

Counts come from the official NIST supplemental assessment procedures CSV. NIST states that the PDF is normative if a supplemental format differs. The package also uses the NIST Cryptographic Module Validation Program and current validation search for the cryptographic transition context.

The full package under research/insights/cmmc-system-communications-protection/ contains the source register, archived source data, public observations, model inputs, formula driven workbook, derived scores, sensitivity analysis, figure data, evidence lanes, decision path, failure modes, evidence packet, editable SVGs, browser rendered PNGs, and display previews.

Model caveat: this is a GS Consulting derived planning model based on cited public sources and documented assumptions. It is not an official legal, audit, compliance, NIST, CMMC, DoD, assessment, certification, cryptographic validation, or regulatory determination. It does not estimate market averages, labor, cost, failure probability, or a contractor's status. Replace the ratings and sequence with the actual system, contract, assessment, and operating facts.

Frequently Asked Questions About CMMC System and Communications Protection

The standard is direct: every CUI path has an owner, every boundary rule matches the diagram, every cryptographic claim names the current module and mode, every exception expires, and every protected and blocked result can be reproduced.

Continue the CMMC Research

• CMMC Security Protection Assets
• CMMC Access Control Evidence
• CMMC Assessment Evidence Guide