CMMC Level 2 Practice 3.13.1: Monitor, control, and protect communications (i.e., information transmitted or received by

To meet CMMC Level 2 Practice 3.13.1, you must actively monitor and control how communications carrying CUI move into, within, and out of your environment, and you must protect those communications with appropriate safeguards (for example, encrypted transport, controlled remote access paths, and logged/inspected network traffic). Build this as an operational network security control with repeatable evidence tied to NIST SP 800-171r2 3.13.1. ¹

Key takeaways:

• Define “communications” broadly: email, VPN, remote admin, cloud access, APIs, file transfer, VoIP, and system-to-system traffic that could carry CUI.
• Implement a controlled, monitored boundary: approved paths, restricted protocols, encryption in transit, and logged network/security telemetry.
• Keep assessor-ready evidence: diagrams, configurations, logs, alert triage records, and proof the control runs continuously, not just on paper.

CMMC Level 2 aligns to NIST SP 800-171 Rev. 2 for protecting CUI in non-federal systems. Practice 3.13.1 sits in the System and Communications Protection family and focuses on something assessors test quickly: whether your organization can show controlled, protected communications paths for CUI, and whether you can detect and respond to suspicious communications activity. ¹

For most contractors, the gap is not intent. It’s sprawl. CUI can move through Teams chats, email gateways, VPN tunnels, cloud storage sync clients, browser sessions to SaaS, remote admin tools, and vendor-managed connections. If you cannot clearly define which paths are allowed and how you monitor them, you will struggle to demonstrate “monitor, control, and protect” in an assessment.

This page translates the requirement into concrete operator actions: scoping communications that may carry CUI, enforcing approved channels, implementing monitoring and logging, and packaging evidence so a CMMC assessor can validate control operation. It also highlights common hangups (like split-tunnel VPN, unmanaged DNS, and opaque third-party connections) and gives a practical execution plan you can run as a program of work. ²

Regulatory text

Requirement: “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.13.1 (Monitor, control, and protect communications (i.e., information transmitted or received by).” ¹

Operator meaning: You must (1) know where communications occur that could carry CUI, (2) restrict communications to approved, managed channels and controlled boundary points, and (3) protect those communications against interception, tampering, and misuse. You also need monitoring that produces actionable security telemetry you can review and retain for assessment. ¹

CMMC program context: CMMC is implemented through the DoD’s program rules and guidance. Your assessment posture and evidence expectations should align to CMMC program requirements and assessor evaluation practices. ^{3 2}

Plain-English interpretation (what “communications” covers)

Treat “communications” as any transmission or receipt of information across a boundary or between components where CUI could exist. In practice, scope at least:

• User communications: email, web browsing to SaaS portals, Teams/Slack, file sharing links, collaboration sites
• Network access: VPN, ZTNA, remote desktop gateways, bastion hosts, VDI
• System-to-system: APIs, service accounts, replication, backups to storage, EDI connections
• File transfer: SFTP/FTPS, SMB shares over WAN, managed file transfer tools
• Administration: SSH, RDP, WinRM, hypervisor management, network device management
• DNS and time services: DNS queries, NTP, directory/auth traffic (because they influence control and monitoring outcomes)

Your goal is not to monitor “everything everywhere.” Your goal is to monitor and control the communications paths that are in-scope for CUI and the infrastructure that enables them. ¹

Who it applies to (entity and operational context)

Applies to:

• Defense contractors and subcontractors handling CUI in non-federal systems for DoD work. ³
• Operationally, it applies to the CUI enclave (if you use one) or the entire enterprise environment if CUI is processed broadly. ¹

Typical in-scope owners:

• Network/security engineering (firewalls, IDS/IPS, secure web gateways)
• IT operations (endpoint configuration, identity, email)
• Cloud/security (CASB/SSPM posture, cloud logs)
• GRC/Compliance (scoping, policy, evidence, assessment readiness)
• Third-party management (connections to MSPs, SaaS providers, data exchanges)

What you actually need to do (step-by-step)

1) Define the scoped communications boundary for CUI

• Identify where CUI is stored/processed and map ingress/egress points (internet edges, VPN, cloud tenants, email gateways, partner links).
• Produce a CUI data flow diagram and a network boundary diagram that shows enforcement points (firewalls, secure web gateway, VPN concentrators).
  Evidence goal: an assessor can trace “CUI in → CUI out” paths and see your control points. ¹

2) Standardize approved channels and block or constrain the rest

• Establish an “approved communications methods for CUI” standard (examples: approved VPN/ZTNA, approved file transfer method, approved collaboration tenant).
• Restrict risky protocols and unmanaged paths (examples: direct inbound admin from the internet, consumer file transfer, unmanaged remote tools).
• Require administrative access to go through controlled jump points (bastion/management network) with strong authentication and logging. ¹

3) Protect communications in transit

• Enforce encryption for CUI transmissions over untrusted networks (TLS-based services, secure VPN, secure file transfer).
• Control certificates and cipher policy centrally where feasible (reverse proxies, gateways, managed endpoints).
• Validate that “encrypted” is not merely optional in client settings; enforce via policy/configuration at endpoints and gateways. ¹

4) Implement monitoring that can detect misuse and policy violations

• Centralize logs from key control points: firewalls, VPN/ZTNA, email security, DNS, secure web gateway, cloud audit logs, endpoint security.
• Configure detections and alerts for high-risk events relevant to communications:
  • anomalous outbound connections from CUI systems
  • impossible travel / suspicious remote access patterns
  • blocked exfil attempts by DLP or web gateway
  • repeated failed VPN authentication
• Document triage: who reviews alerts, what “escalation” means, and how you track closure. ¹

5) Control third-party communication paths

Third parties often create the least-visible communications routes.

• Inventory all third-party connections that touch CUI systems: MSP remote tools, vendor VPNs, SaaS integrations, support tunnels.
• Require documented authorization, defined source IPs, MFA, time-bound access where possible, and logging of actions/traffic.
• Contractually require security logging and support for investigations when the third party hosts or transmits CUI on your behalf. ²

6) Operationalize evidence capture (make it repeatable)

• Tie each technical control to a written procedure and an evidence cadence.
• Store artifacts in an assessment-ready repository with change history.
• For Daydream users: map 3.13.1 to your implemented controls, assign owners, and automate recurring evidence requests (network diagrams, firewall rule reviews, log review tickets) so evidence exists before the assessor asks. ²

Required evidence and artifacts to retain

Keep evidence that proves design and operation:

Design / configuration

• CUI network boundary and data flow diagrams
• Approved communications standard (CUI transmission methods, remote access patterns)
• Firewall/VPN/secure web gateway configuration excerpts (redacted where necessary)
• Baseline hardening standards for endpoints and network devices relevant to communications controls ¹

Operational proof

• Centralized logging/SIEM data source list and sample ingested events
• Alert and incident tickets tied to communications monitoring (with timestamps and analyst notes)
• Periodic review records: firewall rule review notes, VPN access reviews, third-party connection approvals
• Change management records for communications-impacting changes (new VPN, new SaaS connector, new site-to-site link)

Assessment packaging tip: For each “major channel” (email, web/SaaS, VPN/remote admin, file transfer), prepare a one-page control narrative: what is allowed, what is blocked, where it is logged, and where the evidence lives.

Common exam/audit questions and hangups

Assessors and internal auditors commonly probe:

• “Show me where CUI enters/exits your environment and the control points.”
  Hangup: no current diagrams, or diagrams don’t match reality.
• “How do you know someone isn’t moving CUI through unapproved channels?”
  Hangup: policy exists, but no enforcement or monitoring.
• “Demonstrate encryption in transit for remote access and file transfer.”
  Hangup: split-tunnel VPN with direct internet egress from endpoints handling CUI.
• “What telemetry do you collect, and who reviews it?”
  Hangup: logs collected but never reviewed, or review is informal and not retained. ¹

Frequent implementation mistakes (and how to avoid them)

1. Treating 3.13.1 as a firewall-only control
   Fix: include email, SaaS access, remote support tools, APIs, and third-party links in scope.

2. Relying on “policy says so” without technical enforcement
   Fix: implement blocks and guardrails (gateway controls, conditional access, managed endpoints) and show logs.

3. Logging without triage
   Fix: define alert ownership and retain tickets/notes. If you cannot staff a SOC, implement a lightweight review workflow with clear escalation.

4. Opaque third-party connectivity
   Fix: require documented approvals, scoped access routes, and logs for all third-party remote access tied to CUI systems. Use a register that ties the connection to a business owner and expiration trigger.

Enforcement context and risk implications

No public enforcement cases are provided in the source catalog for this requirement, so this page does not cite specific actions. Practically, 3.13.1 failures drive two categories of risk that matter in CMMC contexts:

• Assessment failure risk: inability to demonstrate controlled, protected communications paths and monitoring evidence. ²
• Exposure risk: uncontrolled egress/ingress paths are common root conditions for data exfiltration and unauthorized access to CUI systems. ¹

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and control points)

• Confirm CUI scoping and list all communications channels that can carry CUI.
• Produce/update boundary and data flow diagrams for the CUI environment.
• Inventory monitoring sources and verify log collection from firewalls/VPN/email/cloud/endpoint.
• Identify “known bad” paths (unmanaged remote tools, unknown VPNs, direct admin access) and open remediation tickets.

Day 31–60 (enforce approved channels and harden monitoring)

• Publish the approved CUI communications standard and align procedures (remote access, file transfer, third-party connectivity).
• Implement or tighten encryption-in-transit requirements for CUI paths.
• Add detections for outbound anomalies and remote access misuse; formalize alert triage and retention workflow.

Day 61–90 (prove ongoing operation and assessment readiness)

• Run an internal evidence review: pick a CUI system and trace communications end-to-end with screenshots/log samples.
• Perform a third-party connection review and either formalize or retire undocumented pathways.
• Package artifacts into an assessor-ready folder: narratives, diagrams, configs, log samples, tickets, reviews.
• In Daydream, schedule recurring evidence capture and owner attestations so “continuous operation” is easy to show. ²

Frequently Asked Questions

Does 3.13.1 require a SIEM?

The requirement expects monitoring and protection of communications, not a specific tool. A SIEM often makes evidence and correlation easier, but you can meet the intent with centralized logs, defined alerting, and retained review records. ¹

Are internal east-west communications in scope or only internet traffic?

Both can be in scope if CUI is transmitted internally between systems or segments. Prioritize communications that cross trust boundaries (user subnet to servers, on-prem to cloud, admin networks) and document your rationale. ¹

What counts as “protect communications” for SaaS tools like Microsoft 365?

You need controlled access and protected sessions (strong authentication, conditional access, encryption in transit) plus monitoring through available audit logs. Document which tenant(s) are approved for CUI and how you prevent use of unapproved tenants. ¹

How should we handle third-party remote support for systems that process CUI?

Require an approved remote access path (managed tool or VPN/ZTNA), MFA, scoped privileges, and logging. Keep a record of approval, the technical constraints, and where session/activity logs are retained. ²

Is VPN split tunneling automatically a finding?

The requirement does not name split tunneling, but assessors will question any design that weakens monitoring and control of CUI endpoint communications. If you allow it, document compensating controls (secure web gateway, EDR telemetry, egress controls) and be ready to prove effective monitoring. ¹

What evidence is most persuasive in a CMMC assessment for 3.13.1?

A clear boundary/data flow diagram, enforced configurations (firewall/VPN/policy excerpts), and real operational records (log samples plus tickets showing review and response). The combination shows design and ongoing operation. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170