SC-7(2): Public Access

SC-7(2): Public Access requires you to tightly control and segment any system components that are accessible from the public internet, so public-facing services cannot directly reach internal networks or sensitive system components. Operationalize it by inventorying all public entry points, placing them in controlled boundary zones, enforcing least-privilege flows, and retaining evidence that the segmentation is designed, implemented, and monitored. ¹

Key takeaways:

• Treat every internet-exposed service as a controlled boundary with explicit, documented traffic rules and strong isolation from internal networks.
• Your audit win condition is evidence: diagrams, firewall/WAF rules, allowlists, and verification results that show public-to-internal paths are prevented.
• Make “public access” a repeatable process: new public endpoints must go through design review, security testing, and change control.

SC-7 is the NIST SP 800-53 family control for boundary protection; enhancement (2) focuses specifically on public access. In practice, assessors read “Public Access” as a segmentation and exposure-management requirement: if something is reachable from the internet, it must sit behind a boundary that limits what it can talk to, what can talk to it, and how that access is monitored and changed.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SC-7(2) into an operating model with clear ownership. Someone must own the inventory of public endpoints; someone must own the network/security controls that enforce separation; and you must be able to prove, on demand, that public-facing components cannot laterally move into internal environments without tightly controlled, explicitly authorized pathways.

This page gives requirement-level implementation guidance you can hand to security/network teams and then audit with confidence: what to build, what to document, what evidence to retain, and how exams typically probe this control. Primary references: the NIST SP 800-53 Rev. 5 catalog and overview materials. ²

What SC-7(2): Public Access means (plain English)

The sc-7(2): public access requirement expects you to prevent “internet-reachable” from becoming “internally trusted.” Public access should terminate in a controlled zone (logical or physical) with explicit, minimal connections to internal systems. You should be able to show that:

• You know every public entry point you expose (web apps, APIs, VPN portals, email gateways, DNS, SFTP, remote admin, cloud load balancers).
• Those entry points sit behind boundary protections (firewalls, security groups, WAF/reverse proxies, gateways) with restrictive rules.
• Connections from public-facing components to internal systems are intentionally designed, reviewed, approved, and monitored.

This is less about buying a specific tool and more about proving controlled architecture and disciplined change management around exposure.

Regulatory text

Excerpt (as provided): “NIST SP 800-53 control SC-7.2.” ³

Operator interpretation: Implement boundary protections for publicly accessible components and demonstrate effective isolation between public-facing services and internal networks/components. Your documentation and evidence should let an assessor trace: public endpoint → boundary control(s) → allowed flows → monitoring and change control. ¹

Who it applies to

Entity scope

• Federal information systems.
• Contractor systems handling federal data (including cloud and SaaS environments supporting federal workloads). ¹

Operational scope (where it shows up)

• Internet-facing applications and APIs (including SaaS front doors).
• Perimeter and remote access (VPN, ZTNA portals, bastions, jump hosts).
• Cloud ingress (internet gateways, ALBs/ELBs, API gateways, public buckets with endpoints, public IPs).
• “Shadow exposure” created by third parties: embedded support tools, outsourced web hosting, CDN/WAF providers, managed DNS.

If your ATO boundary, SSP boundary, or system boundary includes anything public-facing, SC-7(2) is in play.

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

Use this as an execution checklist you can assign and track.

1) Build and maintain an inventory of public access paths

• Enumerate all public DNS names and public IPs tied to the system boundary.
• Enumerate all cloud resources marked public or internet-routable (security groups, network ACLs, gateways, load balancers).
• Include third-party-managed endpoints that route into your environment (support portals, embedded chat widgets with admin access paths, externally hosted SFTP that lands data internally).

Output: “Public Access Register” with owner, purpose, data sensitivity, and upstream/downstream dependencies.

2) Define the approved public access architecture pattern(s)

Pick a small set of patterns and forbid everything else by policy. Common patterns:

• Reverse proxy/WAF → app tier in DMZ/subnet → internal services via explicit allowlist
• API gateway → service mesh/ingress controls → internal services via mTLS + authZ
• Remote admin via bastion/jump host only; no direct admin ports exposed

Output: Reference architecture diagram(s) and a short standard that says “public endpoints must conform to these patterns.”

3) Enforce segmentation and default-deny rules at the boundary

Have security/network engineering implement:

• Default deny inbound from the internet, allow only required ports/protocols.
• Default deny outbound from public-facing tiers to internal networks, allow only documented dependencies (for example, app-to-database on a specific port to a specific subnet).
• Administrative access paths separated from user paths (separate management plane, separate auth, separate network path).

Output: Firewall/security group rule sets mapped to each registered public endpoint.

4) Add layered boundary protections appropriate to the exposure

Depending on what is exposed, require one or more of:

• WAF/reverse proxy for web traffic.
• DDoS protections where relevant.
• TLS policies and certificate management.
• Strong authentication and authorization for any non-public content; no “hidden URL equals auth.”
• Rate limiting and abuse monitoring for APIs.

Output: Configuration baselines and screenshots/exports showing control enablement.

5) Instrument monitoring and detection for boundary events

• Centralize logs for boundary devices/services (WAF logs, firewall logs, gateway logs, load balancer access logs).
• Alert on “newly opened paths” (rule changes, new listeners, new public IPs, new DNS records).
• Alert on suspicious inbound patterns and unexpected outbound connections from public-facing tiers.

Output: SIEM queries/alerts list, sample alerts, and evidence of log ingestion.

6) Gate public exposure through change management

Make it hard to accidentally become public:

• Require security review for any new internet-exposed service or rule change.
• Require architectural sign-off that segmentation is in place and tested.
• Require validation testing (port scans from outside, attempted connections from DMZ to internal that should fail).

Output: Change tickets, approvals, and test results attached to each change.

7) Verify control effectiveness (prove the negative)

Assessors will ask how you know segmentation works. Build repeatable checks:

• External scan results (what is reachable).
• Internal reachability tests (public tier cannot reach internal except allowlisted).
• Cloud posture checks for public exposure drift.

Output: Periodic verification report with exceptions and remediation tickets.

Required evidence and artifacts to retain

Keep evidence in a form an auditor can re-perform or at least validate:

Evidence artifact	What it proves	Owner
Public Access Register	You know what is public and why	GRC + Network/SecOps
Network/data flow diagrams (public-to-internal)	Segmentation design and trust boundaries	Architecture
Firewall/WAF/security group exports	Default-deny and explicit allow rules	Network/SecOps
Config baselines/standards	Consistent implementation expectations	Security Eng
Logging + alert definitions	Ongoing monitoring of boundary activity and changes	SecOps
Change tickets for exposure changes	Public access is controlled and reviewed	ITSM owner
Verification results (scans/tests)	Controls work, not just “documented”	Security testing

If you use Daydream to manage control readiness, map SC-7(2) to a named control owner, a short operating procedure, and a recurring evidence list so this doesn’t turn into a quarterly scramble. ¹

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me everything internet-accessible in scope.” They will compare your list to DNS, cloud consoles, and scan results.
• “Where is the trust boundary?” If your diagram is vague, you will lose time.
• “Prove the public tier can’t talk to internal networks broadly.” “We think it can’t” fails; show rules and test evidence.
• “How do you prevent accidental exposure?” They will look for change control gates and detective monitoring for drift.
• “What about third parties?” If a third party hosts a component or provides an admin backdoor, you still need to show boundary controls and approvals.

Hangup: teams often document “the firewall exists” but cannot show rule intent, ownership, review cadence, or testing.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “public access” as only inbound filtering.
   Fix: Control outbound from public-facing components as aggressively as inbound. Document allowed internal dependencies and deny everything else.

2. Mistake: No single inventory of public endpoints.
   Fix: Maintain a register tied to DNS + cloud resource discovery + change management. Make the register the source of truth for audits.

3. Mistake: Flat networks in cloud (shared subnets, permissive security groups).
   Fix: Separate public subnets/tiering, restrict east-west, and require explicit allowlists between tiers.

4. Mistake: Admin interfaces exposed “temporarily.”
   Fix: Create a standard for admin access (bastion/ZTNA) and block direct exposure by policy and technical guardrails.

5. Mistake: Evidence is scattered across consoles.
   Fix: Export configs and attach them to the control record on a recurring basis. Daydream-style evidence mapping keeps ownership and refresh cycles clear. ¹

Risk implications (why operators get burned)

SC-7(2) failures usually surface as:

• Unintended internet exposure (a resource becomes public without review).
• Lateral movement from a compromised public-facing service to internal systems due to permissive routing or overly broad security group rules.
• Inability to demonstrate control operation during an assessment, even if the architecture is “mostly right.”

The immediate risk is technical compromise; the compliance risk is an assessment finding for boundary protection and inadequate evidence of implementation and effectiveness. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and get audit-ready basics)

• Assign a single control owner and technical owners (network/security/cloud).
• Produce the Public Access Register from DNS, IP ranges, and cloud inventories.
• Collect current-state diagrams and boundary rule exports for each public endpoint.
• Identify and ticket “critical exposure gaps” (public admin ports, overly permissive inbound/outbound, unknown endpoints).

Days 31–60 (standardize and enforce)

• Publish approved public access patterns and a short standard for teams to follow.
• Implement default-deny inbound/outbound templates for public tiers (firewall rules, security groups).
• Put exposure changes behind security review in ITSM.
• Stand up monitoring for new public endpoints and rule changes; route alerts to an owned queue.

Days 61–90 (prove effectiveness and operationalize)

• Run repeatable verification (external reachability, segmentation tests, cloud drift checks) and store results as evidence.
• Add quarterly (or other defined cadence) rule review with sign-off and exception handling.
• Close the loop: link register entries to diagrams, rules, change tickets, and verification results in your GRC system so the control stays assessable.

(Plan phases are implementation guidance, not a cited timeframe requirement.)

Frequently Asked Questions

Does SC-7(2) mean we can’t have any internet-facing systems?

You can have internet-facing services, but they must be isolated behind boundary protections with explicit, minimal allowed connections to internal components. The focus is controlled exposure and segmentation. ¹

What counts as “public access” in cloud environments?

Any resource reachable from the public internet: public IPs, internet-facing load balancers, public API gateways, public storage endpoints, and externally reachable admin portals. Track them in an inventory tied to cloud configuration evidence. ¹

Do we need a DMZ to satisfy the sc-7(2): public access requirement?

You need equivalent isolation. In cloud, this is often separate subnets/accounts/projects plus restrictive security groups and routing. The assessor cares about enforced separation and proof, not the word “DMZ.” ¹

What evidence is most persuasive to an auditor?

A complete endpoint inventory, clear boundary/data flow diagrams, exported rule sets showing default-deny with explicit allowlists, and verification results that demonstrate blocked paths. Tie each artifact to the specific public endpoint. ¹

How do we handle third-party services that connect into our environment?

Treat the third party connection as a public access path if it is externally reachable or provides an ingress route. Require documented approved flows, strong authentication, monitoring, and change control for any connectivity into internal systems. ¹

We already have a WAF. Are we done?

A WAF addresses part of inbound web risk, but SC-7(2) also expects segmentation, restricted internal connectivity, monitoring, and controlled changes for all public entry points. You still need rule evidence and effectiveness testing. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

2. NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON

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