03.13.06: Network Communications – Deny by Default – Allow by Exception

“Deny by default, allow by exception” is one of those requirements that sounds like a policy statement but is assessed as an engineering reality. For NIST SP 800-171 Rev. 3, requirement 03.13.06 focuses on network communications: how traffic moves between networks, segments, and systems that handle Controlled Unclassified Information (CUI). The compliance question is simple: if an attacker or misconfigured device tries to communicate over the network, does your environment block it unless you intentionally allowed it?

For a CCO, compliance officer, or GRC lead, the fastest way to operationalize 03.13.06 is to treat it as a rule governance and evidence problem as much as a security tooling problem. Most organizations already have firewalls, security groups, and cloud network controls. The gaps show up in (1) permissive “any/any” rules, (2) undocumented exceptions that never expire, (3) inconsistent controls across on-prem, cloud, and third-party connectivity, and (4) weak evidence of review.

This page translates 03.13.06 into concrete steps you can assign to network/security engineering, then ties those steps to the artifacts you will need for assessments and customer audits under NIST SP 800-171 Rev. 3. ¹

Regulatory text

Requirement: “NIST SP 800-171 Rev. 3 requirement 03.13.06 (Network Communications – Deny by Default – Allow by Exception).” ¹

Operator interpretation: You must set network communication controls so that the default posture is to deny traffic, and you only permit traffic through explicitly defined, justified, and controlled exceptions. “Network communications” includes traffic crossing boundaries (internet edge, partner links), lateral movement between segments, and host-level ingress/egress controls where those are part of your architecture. ¹

Plain-English interpretation (what the requirement means)

You are expected to run an allowlist-based network for systems in scope for CUI. If a flow is not explicitly required and approved (for example, workstation-to-internal app on a specific port), it should not work.

Put differently, you should be able to answer these assessment questions with evidence:

• “What communications are allowed into and out of the CUI environment, and why?”
• “Where is that enforced (edge firewall, cloud security groups, microsegmentation, host firewall)?”
• “How do you ensure exceptions don’t drift over time?”

Who it applies to

Entity scope

• Federal contractors and other organizations operating nonfederal systems that handle CUI under NIST SP 800-171 expectations. ¹

Operational scope (systems and situations)

• On-prem networks supporting CUI workloads (data centers, office networks with CUI endpoints).
• Cloud networks (VPC/VNet, security groups/NSGs, cloud firewalls) where CUI is processed or stored.
• Remote access paths into the CUI enclave (VPN, ZTNA).
• Third-party connectivity that reaches CUI systems (managed service providers, SaaS integration endpoints, EDI links). Treat these as “network communications” paths that require explicit allow rules and strong governance.

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

Below is a practical implementation sequence that a GRC lead can drive, even if engineering executes the changes.

Step 1: Define the “CUI boundary” and traffic control points

1. Identify the in-scope network segments, cloud accounts/subscriptions, and endpoints that store/process/transmit CUI.
2. List enforcement points that can deny/allow traffic:
   • Edge firewalls / secure web gateways
   • Internal segmentation firewalls
   • Cloud security groups/NSGs and route tables
   • Kubernetes network policies (if applicable)
   • Host firewalls (Windows Firewall, iptables) where used for segmentation

Deliverable: A boundary diagram and inventory of enforcement points tied to the CUI environment.

Step 2: Establish a default-deny baseline in each control plane

For each enforcement point, confirm the configuration implements “deny by default”:

• Ingress: block inbound connections unless explicitly allowed to specific destinations.
• Egress: block outbound connections unless explicitly allowed (or at minimum, tightly constrain egress for CUI systems).

Practical target state: No broad “any source, any destination, any port” rules for in-scope zones. Where you must allow broad traffic temporarily, require a documented exception with an expiration and a compensating control plan.

Step 3: Build an “allowed communications matrix” (the allowlist)

Create a matrix that maps business-required flows to technical rules. Keep it simple and assessable.

Field	What to capture	Example
Source	subnet/SG/group/system role	“CUI App Subnet”
Destination	subnet/host/FQDN/service	“CUI DB Subnet”
Protocol/Port	TCP/UDP + port	“TCP/5432”
Direction	ingress/egress/lateral	“Lateral”
Business justification	why needed	“App-to-DB connection”
Data sensitivity	CUI yes/no	“CUI”
Control location	where enforced	“Segmentation firewall + SG”
Owner	accountable team	“Network Sec”
Review cadence	how often reviewed	“Quarterly” (guidance)

This matrix becomes your single best assessment artifact because it ties “allow by exception” to an auditable list.

Step 4: Put exception governance around changes to allowed flows

Define a lightweight workflow:

1. Request: new flow or modification requested with business justification.
2. Risk review: security/network review confirms least privilege (scope, ports, destinations).
3. Approval: named approver(s) for CUI boundary rule changes.
4. Implementation: change executed through standard change management.
5. Validation: test evidence that only intended connectivity works.
6. Expiration/review: temporary rules auto-expire; permanent rules enter periodic review.

Tip for operators: Treat firewall/security group rule changes as “controlled changes” for CUI scope and require tickets with approval and implementation evidence.

Step 5: Validate “deny by default” in practice (not just on paper)

Evidence that convinces assessors usually includes:

• Rulebase exports showing explicit allows and default denies.
• Test results:
  • Attempted connections that should fail (negative tests).
  • Confirmed connections that should succeed (positive tests).
• Logging/monitoring:
  • Denied traffic logs at key boundaries.
  • Alerting for risky rule changes (for example, opening inbound management ports broadly).

Step 6: Run periodic reviews and clean-up (exception lifecycle)

Create a recurring task to:

• Review the allowed communications matrix against actual rules.
• Remove unused, expired, or “temporary” rules that stuck.
• Confirm third-party connectivity remains justified and scoped.

If you want this to survive staffing changes, assign ownership per control plane (on-prem, cloud, endpoint) and keep the allowed-flow matrix in a system with change history.

Required evidence and artifacts to retain

Assessments often fail on “we did it” without proof. Retain:

• Network/CUI boundary diagram with enforcement points labeled.
• Firewall/security group configuration exports (snapshots) showing default deny posture.
• Allowed communications matrix (allowlist) with owners and justifications.
• Change tickets for rule additions/changes, including approvals and implementation notes.
• Exception register for temporary/permissive rules, with expiration dates and closure evidence.
• Review evidence (meeting notes, signed attestations, or tickets) showing periodic rule review.
• Testing evidence (connection test logs, scan outputs, or validation scripts) demonstrating deny-by-default behavior.

Daydream can help by mapping 03.13.06 to a control narrative, collecting recurring exports (rulebase snapshots, review tickets), and packaging the evidence set so you can answer assessor requests without rebuilding the story each time.

Common exam/audit questions and hangups

Expect questions like:

• “Show me the default rule. What happens if a system tries to connect on an unapproved port?”
• “How do you control outbound traffic from CUI systems?”
• “Where is segmentation enforced? Can a user workstation initiate connections to CUI servers?”
• “How do you approve and document exceptions?”
• “How do you know old rules are removed?”

Common hangups:

• Teams show perimeter firewall rules but ignore east-west traffic inside the environment.
• Cloud environments have permissive security groups that don’t match the on-prem standard.
• “Temporary” partner allow rules have no expiration and no review trail.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Default-deny at the edge only.
   Fix: Add segmentation controls so CUI servers are not broadly reachable from user subnets.

2. Mistake: Egress is ignored.
   Fix: Define outbound allow rules for CUI systems (DNS, patching, required APIs) and block the rest where feasible.

3. Mistake: Exceptions live in email/Slack, not in a system of record.
   Fix: Require a ticket for every rule change and tie it to the allowed communications matrix.

4. Mistake: Overbroad rules (“any/any,” “0.0.0.0/0,” “all ports”).
   Fix: Enforce least privilege: narrow CIDRs, explicit ports, explicit destinations, and time-bound approvals for anything broad.

5. Mistake: No proof of ongoing review.
   Fix: Schedule recurring reviews and retain evidence (rule recertification output and cleanup tickets).

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific requirement, so this page does not cite enforcement outcomes.

Risk-wise, default-deny gaps tend to translate into:

• Larger blast radius after endpoint compromise (lateral movement becomes easy).
• Data exfiltration paths that are hard to detect because outbound traffic is unconstrained.
• Assessment failure due to weak evidence even if tools exist.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and evidence)

• Confirm what is in the CUI boundary and document enforcement points.
• Export current firewall/security group rules for in-scope environments.
• Identify and triage the highest-risk permissive rules (broad inbound admin access, any/any between segments, internet egress from sensitive servers).
• Stand up the allowed communications matrix and start populating it with known required flows.

By 60 days (implement governance and close obvious gaps)

• Implement or tighten default-deny rules at major boundaries (edge and key internal segments).
• Put rule-change governance in place (ticketing, approvals, exception register).
• Convert undocumented rules into documented allowlist entries or remove them.
• Add validation tests (a small suite of “should fail” and “should pass” checks) and store results.

By 90 days (operationalize and make it repeatable)

• Align cloud and on-prem patterns (consistent default-deny posture and exception workflow).
• Run a formal rule review and remove stale/temporary exceptions.
• Finalize an assessment-ready evidence pack: diagrams, rule snapshots, matrix, exceptions, and review records.
• Automate recurring evidence collection where practical (scheduled exports, review tasks). Daydream can act as the system that tracks the control, prompts reviews, and stores artifacts for audits.

Frequently Asked Questions

Does “deny by default” mean I have to block all outbound internet access from CUI systems?

The requirement drives you toward explicit approvals for network communications. Many teams implement constrained egress for CUI systems (only required destinations/ports), then document exceptions where business needs demand broader access. ¹

Are cloud security groups enough to satisfy 03.13.06?

They can be, if they implement a default-deny posture and your allow rules are specific, justified, and governed through change control. You still need evidence and periodic review, not just “the controls exist.” ¹

What counts as an “exception” that needs documentation?

Any allowed communication that deviates from the baseline deny posture or introduces broader exposure (wide source ranges, broad ports, third-party network access) should be documented with justification, approval, and review/expiration. ¹

How do we handle third-party access (MSP, partner VPN, SaaS integration)?

Treat third-party connectivity as allowed-by-exception traffic into the CUI boundary. Require explicit scoping (source, destination, ports), written justification, and a recurring review to confirm the access is still needed. ¹

What will an assessor ask me to show in a single screen-share?

Expect requests for a network diagram of the CUI boundary, a rulebase view/export that shows default deny behavior, and the ticket trail for recent rule changes. Have the allowed communications matrix ready to connect “why” to each allowed flow. ¹

We have legacy apps that require broad ports. Can we still comply?

Usually, yes, but you need tight compensating governance: document the requirement, limit the scope as much as possible (source ranges, destinations), time-box exceptions when feasible, and track a remediation plan to reduce exposure over time. ¹

Footnotes

1. NIST SP 800-171 Rev. 3