SC-7(3): Access Points

SC-7(3) requires you to limit the number of external network connections (access points) into your system so every inbound/outbound pathway is intentional, approved, and monitored. Operationally, this means you maintain an authoritative inventory of all external connections, eliminate or consolidate unnecessary ones, and enforce architecture and change controls that prevent “new internet paths” from appearing without review ¹.

Key takeaways:

• Define what counts as an “external network connection” for your boundary, then inventory and reconcile them to reality ¹.
• Reduce and standardize entry/exit points (consolidate through controlled gateways) and require approvals for exceptions ¹.
• Audit readiness hinges on evidence: diagrams, inventories, firewall/edge configs, and change tickets that prove limits are real and enforced ¹.

The sc-7(3): access points requirement is easy to misunderstand because it sounds like “have a firewall.” That’s not what auditors are looking for. They want proof you deliberately constrained how the system can be reached from outside networks, and that you can show where those access points are, who approved them, and how you prevent unauthorized ones from being added ¹.

For federal information systems and contractor environments handling federal data, uncontrolled external connections are a predictable failure mode: shadow VPNs, “temporary” vendor tunnels that never get removed, direct-to-instance public IPs, test environments exposed to the internet, and third-party managed appliances with their own outbound paths. Each one expands attack surface, complicates incident scoping, and weakens boundary monitoring.

This page translates the requirement into implementable work: scoping the system boundary, building an inventory that matches reality, reducing connections through standard gateways, and setting up governance so the number of external connections stays limited over time. The goal is fast operationalization and clean assessment evidence against SC-7(3) ².

Regulatory text

Requirement (SC-7(3): Access Points): “Limit the number of external network connections to the system.” ¹

Operator interpretation: You must (1) identify every way traffic can cross your system boundary to an external network, (2) intentionally constrain those paths to the minimum needed for mission/business, and (3) keep them constrained through architecture standards and change control. “Limit” is a governance and engineering outcome, not a one-time diagram exercise ¹.

Plain-English interpretation (what this really means)

An external network connection is any network path where traffic crosses from your system to something outside the authorization boundary (internet, partner networks, third-party networks, other enterprise enclaves if they are out of scope, and any externally managed segment). SC-7(3) expects you to reduce sprawl: fewer internet-facing entry points, fewer uncontrolled egress paths, and fewer one-off tunnels.

Practically, “limit the number” usually translates into design patterns like:

• Centralized ingress via an approved gateway (reverse proxy/WAF/VPN/ZTNA) rather than direct exposure of workloads.
• Centralized egress via controlled NAT/secure web gateway/egress firewall rather than free outbound from every subnet.
• Approved partner connectivity via a small number of managed interconnects rather than ad-hoc site-to-site VPNs.

You are allowed to have external connections. You are not allowed to have many of them by accident.

Who it applies to (entity and operational context)

SC-7(3) commonly applies where NIST SP 800-53 Rev. 5 is in scope, including:

• Federal information systems.
• Contractor systems handling federal data (including cloud and hybrid environments supporting federal missions) ².

Operationally, the control touches:

• Network/security engineering (firewalls, cloud networking, DNS, remote access).
• Cloud platform teams (public IP allocation, load balancers, API gateways, peering).
• IT operations (VPNs, MPLS/SD-WAN, remote admin tools).
• Application owners (internet-facing endpoints, partner integrations).
• Third-party management (vendor/partner tunnels and managed connectivity).

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

1) Define the system boundary and “external” for this control

Write down:

• What is inside the system boundary (accounts/subscriptions/VPCs, on-prem segments, SaaS components if in scope).
• What counts as external (internet, partner networks, third-party managed networks, other internal networks that are out of scope).

Evidence outcome: a boundary statement in the SSP or system security documentation that an assessor can follow ².

2) Build an authoritative inventory of external connections (reconciled to reality)

Create a single inventory (spreadsheet, CMDB, GRC record, or Daydream control record) with one line per connection:

• Connection name/ID
• Type (internet ingress, internet egress, site-to-site VPN, peering, private circuit, API integration path)
• Source/destination networks
• Termination points (firewall, gateway, load balancer)
• Ports/protocols and directionality
• Business purpose and system owner
• Approval reference (change ticket, architecture review)
• Monitoring/log sources (SIEM, flow logs)
• Status (active, planned, decommissioning)

Then reconcile the inventory against:

• Firewall rulesets and objects
• Cloud security groups/NACLs and load balancer listeners
• VPN/SD-WAN configs
• Routing tables/peering configurations
• Public IP allocations and DNS entries

This reconciliation is where most programs fail. Your inventory must match what’s deployed ¹.

3) Set a “default stance”: no new external connections without review

Implement a governance gate:

• Architecture review required for new ingress/egress patterns.
• Change management required for new firewall rules, VPNs, peerings, public IPs, or DNS that exposes services.
• Explicit expiration for temporary connections, with an owner.

If your org moves fast, bake it into pipelines:

• Infrastructure-as-code checks that block public exposure unless a waiver/approval token exists.
• Standard modules for approved gateways so teams don’t build bespoke paths.

4) Reduce the number of access points by consolidation

Work down the inventory and decide:

• Remove: connections with no current owner, unclear purpose, or replaced integrations.
• Consolidate: multiple partner tunnels into a standard partner gateway; multiple app endpoints behind a shared reverse proxy; scattered egress into a small number of controlled NAT/egress points.
• Standardize: enforce “approved patterns” (for example, “all internet ingress through WAF + reverse proxy + MFA-protected admin access”).

Keep a decision log for each connection you keep that explains why it must exist.

5) Enforce technical controls that prevent sprawl

Examples of practical enforcement mechanisms:

• Restrict who can allocate public IPs, create internet gateways, open inbound security group rules, or create new VPNs/peerings.
• Baseline firewall policies that deny inbound by default and restrict outbound to required destinations.
• Network segmentation and routing controls so only gateway subnets can reach external networks.

SC-7(3) is satisfied by the outcome (limited connections), but assessors will expect you to show the mechanisms that keep it that way ¹.

6) Monitor for drift and prove ongoing control operation

Set up recurring checks:

• Detect new public endpoints, new VPNs, new peerings, and new inbound listeners.
• Review the external connection inventory on a schedule tied to your change cadence.
• Alert on “direct-to-internet” paths that bypass approved gateways.

Daydream fits well here as the control “home”: assign an owner for SC-7(3), store the inventory, map each external connection to approvals and log sources, and generate assessor-ready evidence bundles without chasing engineers at the last minute ¹.

Required evidence and artifacts to retain

Keep artifacts that prove (1) you know your access points, (2) you reduced them, and (3) you prevent re-growth:

Design and scope

• System boundary definition (SSP excerpt or boundary narrative) ².
• Network diagrams that clearly mark external connections and termination points.

Inventory and decisions

• External network connections inventory (authoritative register).
• Exception/waiver register for “must keep” one-offs, with rationale and compensating controls.

Technical configurations (point-in-time exports)

• Firewall edge policy exports (sanitized as needed).
• Cloud configuration evidence (security group rules, load balancer listeners, public IP lists, peering/VPN configs).
• Routing evidence showing egress paths are constrained.

Process evidence

• Change tickets for new/modified external connections.
• Architecture review records and approvals for exposed services or partner connectivity.

Operational evidence

• Monitoring coverage: where logs/flows are collected and who reviews them.
• Findings from periodic reviews and remediation tickets.

Common exam/audit questions and hangups

Assessors typically probe:

• “Show me every way the system connects to the internet or third parties.” Expect a request for both diagrams and a tabular inventory ¹.
• “How do you know this inventory is complete?” They will ask how you reconcile it to firewall/cloud configs.
• “What stops a developer from creating a new public endpoint?” They will look for permissions boundaries and change gates.
• “Why do you have these three separate partner VPNs?” They will ask for consolidation rationale or documented exceptions.
• “How do you review and remove stale connections?” They will want evidence of periodic review and decommissioning.

Hangup to anticipate: teams confuse “external connections” with “number of ISPs” or “number of firewalls.” The requirement is broader: any external network path.

Frequent implementation mistakes (and how to avoid them)

1. Treating the network diagram as the inventory.
   Fix: maintain a line-item register that maps to exact config objects (firewall rule IDs, security group IDs, VPN names).

2. Counting only ingress and ignoring egress.
   Fix: inventory outbound paths and enforce controlled egress; exfiltration risk often rides on unrestricted outbound.

3. Letting third parties create unmanaged access paths.
   Fix: require third-party connections (support tunnels, managed appliance backhauls) to terminate in your controlled gateway zone, with documented ownership and monitoring expectations.

4. Allowing “temporary” exposures to become permanent.
   Fix: require expirations on exceptions, plus an owner and a removal ticket before the expiration date.

5. No mechanism to prevent drift.
   Fix: permissions guardrails + detection. If the only control is a quarterly review meeting, you will miss rapid changes.

Enforcement context and risk implications

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

Risk-wise, a high number of external connections increases:

• Attack surface (more entry points to harden).
• Operational fragility (more dependencies to manage during incidents).
• Audit scope and testing burden (more paths to validate and monitor).

From a CCO/GRC perspective, SC-7(3) is often a “credibility control”: if you cannot enumerate and justify your access points, assessors will question adjacent boundary controls in SC-7 and related families ².

Practical 30/60/90-day execution plan

First 30 days (stabilize and get to a complete picture)

• Name a control owner for SC-7(3) and define system boundary and “external.”
• Build the initial external connections inventory from known sources (network team, cloud team, third-party management).
• Pull configuration exports to reconcile obvious gaps (public IPs, internet gateways, VPNs, firewall rules).
• Stand up a simple rule: no new external connections without a recorded approval.

Next 60 days (reduce and standardize)

• Identify the top candidates to remove (no owner, no business purpose) and open decommission tickets.
• Define approved patterns for ingress/egress and partner connectivity.
• Consolidate where feasible (move ad-hoc endpoints behind standard gateways).
• Create an exception workflow for connections that cannot be consolidated yet.

Next 90 days (operationalize and make it repeatable)

• Implement preventive guardrails (permissions boundaries; IaC checks where applicable).
• Implement detective monitoring for new access points and drift against the inventory.
• Run an internal mini-assessment: sample a few connections end-to-end and verify documentation, approvals, and monitoring evidence.
• Move evidence collection into a repeatable package (Daydream can hold the inventory, map owners, and track recurring artifacts) ¹.

Frequently Asked Questions

What exactly counts as an “external network connection” for SC-7(3)?

Any network path that crosses from your system boundary to a network outside that boundary, including internet ingress/egress, partner links, and third-party tunnels. Write down your boundary definition first, then classify connections against it ¹.

Does SC-7(3) mean we can only have one internet connection?

The text requires you to limit the number, not hit a specific number. Auditors usually expect you to justify each external connection, show consolidation where practical, and prove you prevent unapproved additions ¹.

We’re cloud-native. Is “external connection” just public load balancers?

No. Also include public IPs on instances, API gateways, peering, VPNs, private connectivity to third parties, and uncontrolled egress paths. Cloud makes it easy to create new access points; your control needs inventory plus guardrails ¹.

How do we handle third-party support access (vendor remote tunnels)?

Require third-party connectivity to terminate in a controlled access zone, document the business purpose and owner, restrict scope, and log it. Treat each third party pathway as an external connection that must be inventoried and approved ¹.

What evidence satisfies assessors fastest?

A reconciled inventory tied to actual configuration objects, plus network diagrams showing where each connection terminates. Add change/approval records and monitoring proof to show the limits persist over time ¹.

Can Daydream replace our CMDB for SC-7(3)?

It can act as the control system of record for SC-7(3) by tracking the owner, procedure, inventory, approvals, and recurring evidence artifacts. Keep technical source-of-truth in your network/cloud tools, then map evidence into Daydream for assessment readiness ¹.

Footnotes

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

2. NIST SP 800-53 Rev. 5