SC-7(5): Deny by Default — Allow by Exception

SC-7(5): Deny by Default — Allow by Exception requires you to configure network traffic controls so communications are blocked unless you have explicitly approved them. Operationalize it by setting “default deny” policies on boundary devices and internal segmentation controls, then managing every allowed flow as a documented, time-bound exception with owner approval and recurring review. ¹

Key takeaways:

• Set default-deny at enforcement points (perimeter, cloud security groups, internal segmentation), not just on paper. ²
• Treat every permitted connection as an exception with a business justification, scope, and review trigger. ¹
• Keep assessor-ready evidence: configs, rule inventories, exception tickets, and periodic access/flow reviews mapped to an owner. ²

The sc-7(5): deny by default — allow by exception requirement is one of the fastest ways for an assessor to distinguish a “secure-by-design” network from an organically grown one. They are not looking for a single firewall rule. They are looking for a control posture: the default state of network communications is blocked, and the only permitted traffic is traffic you can explain, approve, and re-validate.

This matters in modern environments because “the network” is no longer only a perimeter firewall. Your enforcement points include cloud security groups, Kubernetes network policies, SaaS tenant allowlists, VPN concentrators, identity-aware proxies, WAFs, and microsegmentation controls. If any of those are configured permissively (“allow any” with a few blocks), you will struggle to demonstrate SC-7(5) even if the traditional perimeter is tight.

For a CCO or GRC lead, the work is straightforward but detail-heavy: define where default-deny must be enforced, establish a repeatable exception process, and collect durable evidence that the posture is real. Your goal is to make “why is this traffic allowed?” an easy question to answer in minutes, not days. ²

Regulatory text

Requirement (verbatim): “Deny network communications traffic by default and allow network communications traffic by exception {{ insert: param, sc-07.05_odp.01 }}.” ¹

What the operator must do: configure your network control plane so the baseline behavior is deny, then create explicit allow rules only where there is a documented need. “By exception” means allowed traffic is a managed decision: it has an owner, business justification, defined scope (sources/destinations/ports/protocols), and is reviewed to confirm it is still needed. ²

Plain-English interpretation

• Default behavior: if nobody has approved a communication path, it must not work.
• Allow rules are deliberate: a permitted flow exists because someone requested it, someone approved it, and the scope is as narrow as practical.
• Ongoing governance: exceptions do not live forever by accident; you review them and remove what is no longer required.

A useful litmus test: if your team cannot produce a current list of “allowed inbound/outbound flows” and who approved them, you do not have “allow by exception” in an auditable sense, even if you have some blocking rules.

Who it applies to

SC-7(5) is part of NIST SP 800-53 and commonly appears in assessments for:

• Federal information systems implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is flowed down contractually or used as the assessment baseline. ²

Operationally, it applies anywhere you control network communications traffic, including:

• Internet perimeter and DMZ
• East-west traffic between workloads (data tier, app tier, admin tier)
• Remote access paths (VPN, ZTNA, bastions)
• Cloud networking (VPC/VNet security groups, NACLs, peering rules)
• Container networking (Kubernetes network policies)
• Third-party connectivity (B2B links, vendor access, managed services)

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

1) Name the enforcement points (where “default deny” must exist)

Create an inventory of all controls that can enforce network policy. Typical categories:

• Perimeter firewalls / cloud firewalls
• Cloud security groups / NACLs
• WAF / reverse proxies / load balancers (where they control access paths)
• Microsegmentation / host firewalls
• Kubernetes network policies / service meshes
• Egress controls (NAT gateways with policy, secure web gateways)

Deliverable: Network Policy Enforcement Point Register (one row per enforcement point, with system owner and logging location).

2) Define the default-deny standard (what “deny” means in your environment)

Write a short standard that answers:

• For each enforcement point type, what is the required baseline: “deny all inbound,” “deny all east-west unless whitelisted,” “deny egress except approved destinations,” etc.
• Whether “implicit deny” is acceptable or you require an explicit “deny any any” rule (both can be valid; pick one and document it).
• Minimum scoping rules: no “any/any” sources, no “all ports,” no broad CIDR ranges unless justified.
• Required logging: what gets logged and where it is retained.

This becomes your assessor anchor: “Here is what default deny means for us, and here is where it is enforced.” ²

3) Build the “allow by exception” workflow

Treat allow rules like controlled changes:

• Request intake: ticket or change record includes source, destination, port/protocol, environment, data sensitivity, and business justification.
• Risk review: security/network reviews for least privilege and segmentation alignment.
• Approval: system owner approval plus security approval for higher-risk paths (define what triggers elevated approval).
• Implementation: implemented through IaC or controlled change on the enforcement point.
• Expiration/review: add a review date or trigger (for temporary access, add an expiration).

Deliverable: Network Connectivity Exception Procedure and the corresponding ticket fields.

Practical tip: If your org uses Daydream for third-party risk and control evidence, store the exception workflow, control owner mapping, and recurring evidence requests in the same control record so you can produce audit artifacts without scrambling.

4) Convert current state “allows” into explicit, justified exceptions

Most environments start from permissive rules. You need to reverse that:

• Export the current rule base from each enforcement point.
• Identify high-risk patterns (any/any, broad CIDRs, wide port ranges, unmanaged egress).
• For each allowed flow, assign:
  • owner
  • justification
  • scope narrowing opportunities
  • whether it should be removed
• Implement a cleanup plan: narrow first, then remove, then add compensating controls if needed.

Deliverable: Allowed Traffic Register (the authoritative list of permitted flows and their approvals).

5) Prove it works: test deny-by-default

Assessors will expect more than policy statements. Build repeatable tests:

• Attempt a connection that is not in the allow register and confirm it fails.
• Validate that approved flows succeed and are logged.
• Confirm changes follow the workflow and produce traceable records.

Deliverable: SC-7(5) Test Evidence (test scripts/results, screenshots, or logged outcomes tied to dates and environments).

6) Operate it: recurring reviews and drift control

You need operational hooks that stop rule creep:

• Periodic review of the allowed traffic register by system owners.
• Monitoring for “new allow rules” and “scope expansions” outside the workflow.
• Exceptions hygiene: remove expired rules and stale access paths.
• Evidence collection cadence aligned to your audit cycle.

Deliverable: Recurring Review Records (attestations, meeting notes, exported rule diffs).

Required evidence and artifacts to retain

Use this table as your evidence checklist.

Artifact	What it proves	Owner
Network Policy Enforcement Point Register	You know where policy is enforced	Network/SecOps
Default-Deny Network Standard	Defined baseline and scoping expectations	Security Governance
Allowed Traffic Register (approved flows)	“Allow by exception” is explicit and traceable	Network/SecOps + App Owners
Exception tickets/change records	Each allow has justification and approval	Change Management
Firewall/SG/K8s policy exports	Config aligns to registers	Network/SecOps
Logging evidence (SIEM queries, samples)	Denies/allows are monitored	SecOps
Review/attestation records	Exceptions are revalidated	Control Owner
Test results	Default-deny is demonstrable	Security Engineering

Mapping tip: explicitly map SC-7(5) to a control owner, a written implementation procedure, and recurring evidence artifacts so audits don’t depend on institutional memory. ¹

Common exam/audit questions and hangups

Expect these, and prep short answers plus artifacts:

1. “Show me the default deny configuration.” Have exports from representative enforcement points and your baseline standard.
2. “How do you know only approved traffic is allowed?” Produce the allowed traffic register and show it reconciles to actual configs.
3. “Who approved this rule and why?” Pull the exception ticket linked to the rule ID/object name.
4. “How do you prevent drift?” Show change controls, IaC pipelines, detection of out-of-band changes, and periodic reviews.
5. “What about cloud and Kubernetes?” Have the same story across those planes (security groups, network policies), not only perimeter firewalls.

Frequent implementation mistakes and how to avoid them

• Mistake: default deny only at the perimeter. Fix: apply default-deny principles to east-west and admin paths, prioritizing high-value segments (identity, databases, management networks). ²
• Mistake: “any/any” justified as “temporary” with no expiry. Fix: require expirations for temporary access and enforce automated reminders/escalations.
• Mistake: exception register exists but does not match reality. Fix: reconcile by exporting rules routinely and diffing against the register; treat mismatches as findings.
• Mistake: no owner for a rule. Fix: make owner a required field; if no owner exists, the rule becomes a removal candidate.
• Mistake: relying on tribal knowledge for legacy flows. Fix: run discovery, document flows, and retire what cannot be justified.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so this page does not cite enforcement actions.

Risk-wise, SC-7(5) failures usually translate into:

• larger attack surface from unnecessary open ports and broad network reachability
• easier lateral movement after initial access
• higher likelihood of data exfiltration through unrestricted egress paths

From a governance standpoint, the most common assessment failure is not “you allowed a port.” It is “you cannot prove you intended to allow it, and you cannot show ongoing control.” ²

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Assign a single SC-7(5) control owner (and a technical delegate in Network/SecOps).
• Publish the default-deny standard and define required exception fields.
• Inventory enforcement points and pick the authoritative logging source for network control events.
• Stand up the allowed traffic register, even if it starts incomplete.

Days 31–60 (reduce exposure and build repeatability)

• Export rules from priority enforcement points and reconcile against the register.
• Triage and remediate high-risk rules (broad inbound, broad admin access, unmanaged egress).
• Implement “new allow rule” detection (change management linkage or config monitoring).
• Run a first formal exception review with system owners and record outcomes.

Days 61–90 (scale coverage and lock in operations)

• Extend the program to cloud-native and container enforcement points.
• Convert repeatable changes to IaC where feasible to reduce drift.
• Operationalize recurring evidence pulls (rule exports, exception lists, review attestations).
• In Daydream, centralize the SC-7(5) control record: owner, procedure, and scheduled evidence so audits are pull-button instead of project work.

Frequently Asked Questions

Does “deny by default” mean I must block all outbound (egress) traffic?

SC-7(5) requires default-deny for network communications and allow-by-exception, but it does not prescribe where you start. Many teams begin with inbound and sensitive east-west paths, then expand egress controls where the risk justifies it. ²

Are “implicit deny” rules acceptable, or do auditors require an explicit deny rule?

Either can be acceptable if your technology enforces deny by default and you can show it clearly. Document your standard and provide config evidence that the platform’s evaluation ends in deny when no allow matches. ¹

How do we handle third-party connectivity under SC-7(5)?

Treat third-party connections as exceptions with named owners, narrow scope (source IPs, ports, protocols), and explicit review triggers. Keep the approval record tied to the rule object so you can answer “why is this allowed?” fast. ²

What evidence matters most for an assessment?

Assessors usually want three things: your written default-deny standard, real configuration exports showing default deny in effect, and traceable exception tickets for permitted flows. Add recurring review records to prove the control operates over time. ²

We have legacy apps with unclear network dependencies. How do we avoid breaking production?

Start by documenting observed flows, then convert them into explicitly approved allows with narrow scope. Stage changes in lower environments and use temporary, time-bound exceptions while owners validate required traffic. ²

How should we represent SC-7(5) in our GRC system?

Record the control owner, the enforcement points in scope, the exception procedure, and the evidence set you will produce on a schedule. Daydream works well as the system of record for the procedure-to-evidence mapping so the control stays assessment-ready. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5