SC-7(28): Connections to Public Networks

SC-7(28): Connections to Public Networks requires you to prohibit any direct connection of specified system components (defined by your organization) to a public network. Operationally, you must define what assets are in scope, enforce network architecture controls that block direct exposure, and maintain evidence that the prohibition is continuously implemented and monitored. ¹

Key takeaways:

• Define the in-scope components (the parameter) and document the rule in a control card with clear ownership and exceptions.
• Enforce the prohibition through network segmentation, controlled ingress/egress, and configuration guardrails that prevent “public internet direct” paths.
• Retain machine-verifiable evidence (configs, scans, diagrams, tickets) that proves the prohibition is operating over time.

The sc-7(28): connections to public networks requirement is simple to read and easy to fail in practice: “direct connection” is often created by cloud defaults, rushed proof-of-concept builds, unmanaged remote access, or third-party connectivity that bypasses approved boundary controls. SC-7(28) is an architectural prohibition, not a training requirement or a policy statement. Auditors will look for technical enforcement that makes direct public exposure hard or impossible, plus evidence that you regularly validate the control still holds.

This control enhancement sits under SC-7 (Boundary Protection) in NIST SP 800-53 Rev. 5. It expects you to choose which components are prohibited from direct public-network connection (the sc-07.28 organizationally defined parameter), then implement and operate guardrails so those components cannot be attached straight to the internet. ²

If you’re a CCO, Compliance Officer, or GRC lead, your fastest path is to: (1) lock down the scope definition, (2) align network/security engineering on the “allowed connectivity patterns,” and (3) build an evidence bundle that proves continuous enforcement, not a one-time diagram.

What SC-7(28) requires (plain-English interpretation)

SC-7(28) requires your organization to block direct connections from certain system components to public networks. “Public network” generally means the public internet. “Direct connection” means there is no approved boundary control or managed intermediary that enforces your security policy at the connection point.

The control is parameterized: you must explicitly define the components/assets that are prohibited from direct public-network connectivity (for example: databases, directory services, internal admin interfaces, management planes, OT assets, regulated workloads, or the entire production VPC/VNet). The requirement is that those defined components do not connect directly to a public network. ¹

What auditors expect:

• A clear statement of what is prohibited (scope).
• A clear statement of what is allowed instead (approved patterns).
• Technical enforcement and recurring validation.

Regulatory text

Excerpt (SC-7(28)): “Prohibit the direct connection of {{ insert: param, sc-07.28_odp }} to a public network.” ¹

Operator translation (what you must do):

1. Fill in the parameter: define which components are covered by the prohibition (systems, subnets, interfaces, device classes, environments).
2. Implement controls that prevent direct public-network paths to those components (architecture + configurations).
3. Prove it stays true through monitoring, testing, and change control evidence.

Who it applies to

Entity types

• Federal information systems.
• Contractor systems handling federal data (common in federal contracting, regulated programs, and environments aligned to NIST 800-53). ¹

Operational contexts where SC-7(28) shows up

• Systems with sensitive data that must not be internet-reachable (customer PII, federal contract data, auth systems).
• Cloud environments where “public IP by default” can happen quickly.
• Hybrid networks where remote access, partner connectivity, or third-party tooling can create bypass paths.
• Environments with management networks (hypervisor management, Kubernetes control planes, CI/CD admin consoles).

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

Step 1: Define the sc-07.28 parameter (scope) in a control card

Create a one-page “requirement control card” that an engineer can execute without interpretation drift. Minimum fields:

• Objective: prohibit direct connection of defined components to public networks. ¹
• In-scope components (parameter): name categories and concrete examples (e.g., “production databases,” “identity directory,” “internal admin UIs,” “management plane subnets,” “regulated workloads”).
• Owner: Network Security or Cloud Platform Engineering; GRC owns oversight.
• Trigger events: new VPC/VNet, new internet gateway, new load balancer, new public IP, new remote access tool, mergers, third-party network connections.
• Exceptions: tightly defined, risk-accepted, time-bound, with compensating controls and explicit approval workflow.

Why this matters: audits fail when teams cannot show ownership, cadence, and evidence mapping.

Step 2: Define “allowed patterns” (what replaces direct connection)

Write a short architecture standard that answers: “If it can’t connect directly to the public internet, how do people/admins/services reach it?” Common allowed patterns (choose what fits your environment):

• Access via reverse proxy / WAF / API gateway for web-facing services.
• Admin access via VPN / ZTNA into a restricted admin network.
• Partner/third-party access via private connectivity and dedicated ingress points, not ad hoc public endpoints.
• System-to-system access via private subnets with controlled egress and explicit routing.

Make this concrete. Include examples of approved network paths and forbidden ones.

Step 3: Implement preventive technical controls (guardrails)

Your implementation will vary by on-prem vs. cloud, but auditors want preventive controls, not only detective ones.

Preventive guardrails to implement and document:

• Network segmentation: place in-scope components in private network segments/subnets with no direct route to internet ingress.
• Ingress controls: block inbound from public networks except through approved boundary devices/services.
• Egress controls: restrict outbound paths from sensitive segments; require egress through controlled NAT/proxy with logging where appropriate.
• Configuration controls: prevent assignment of public IPs to in-scope assets; restrict who can create internet-facing load balancers or open security group rules.
• Change control hooks: require review for any change that could create direct public exposure (routing, firewall/security group, gateway creation, public DNS record creation).

Practical note: cloud misconfigurations are a common source of “direct connection.” Your guardrails should make the insecure path fail at build time (policy-as-code) or at least be automatically detected and ticketed quickly.

Step 4: Implement detection and continuous verification

Even strong architecture drifts. Add recurring checks:

• External attack-surface discovery for your domains and IP ranges (to find unexpected internet-exposed services).
• Configuration monitoring to detect public IP assignments, open inbound rules, new internet gateways, or route table changes.
• Vulnerability and exposure scans scoped to “internet-reachable” assets to validate nothing prohibited is exposed.

Tie findings to a remediation workflow with owners and closure evidence.

Step 5: Run control health checks and manage exceptions

Operate SC-7(28) as a living control:

• Periodic review of in-scope component list (the parameter).
• Periodic review of cloud accounts/subscriptions and network boundaries.
• Exception review: confirm any exception is still required, still time-bound, and still has compensating controls.

Daydream (as a workflow layer) fits naturally here when you need a repeatable control card, evidence bundle definitions, and recurring control health checks that close the loop from detection to validated remediation.

Required evidence and artifacts to retain

Build an evidence bundle that maps directly to the requirement language and shows both design and operation:

Governance artifacts

• Approved SC-7(28) control card: scope/parameter, owner, triggers, exceptions, and operating cadence.
• Network/security architecture standard describing allowed connectivity patterns.

Technical enforcement artifacts

• Current network diagrams showing boundaries between private segments and public networks.
• Firewall/security group standards and baseline configurations.
• Screenshots/exports of cloud policies/organization policies that restrict public IPs and internet-facing resources (where applicable).

Operational evidence (the “proves it works” set)

• Change tickets for network boundary changes with security approval.
• Recurring scan outputs (attack surface, exposure checks) and remediation records.
• Exception register entries with approvals, compensating controls, and expiration dates.
• Control health check logs and any resulting corrective actions.

Retention location matters. Store evidence in a system auditors can access without tribal knowledge (GRC repository, ticketing system, or control management platform).

Common exam/audit questions and hangups

Expect auditors to press on these points:

1. “What components are in scope for the prohibition?”
   If your parameter is vague (“sensitive systems”), you will struggle. Provide a list tied to environments, subnets, tags, or asset classes. ¹

2. “Show me it’s prohibited technically, not only by policy.”
   Provide configs/policies that prevent public exposure, plus detection evidence.

3. “How do you prevent drift after changes?”
   Show monitoring, alerts, and a change control workflow for network boundary changes.

4. “How do you handle remote administration?”
   Show the approved admin access pattern (VPN/ZTNA/bastion) and logs demonstrating its use.

5. “Do third parties have network paths that bypass your boundary?”
   Show third-party connectivity diagrams and approvals.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails SC-7(28)	Better approach
Treating SC-7(28) as a policy-only statement	“Prohibit” implies enforcement	Implement guardrails that block public exposure and keep proof
Undefined parameter (scope creep or ambiguity)	Auditors can’t test the control	Name concrete in-scope components and how you identify them
Relying on “security groups are fine” without standards	Misconfigurations create direct paths	Baselines + restricted admin rights + monitoring for risky changes
Exceptions without expirations	Temporary risk becomes permanent	Time-bound exceptions with compensating controls and periodic review
Ignoring third-party connectivity	Partners can create direct exposure	Review and document all third-party network connections and boundary points

Enforcement context and risk implications

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

From a risk perspective, direct internet exposure of internal components increases the likelihood of unauthorized access, exploitation of misconfigurations, and loss of confidentiality or availability. SC-7(28) is a straightforward way to reduce attack surface by design, which also simplifies incident response because “should this have been reachable?” becomes an auditable yes/no question. ³

Practical execution plan (30/60/90-day)

Timelines below are an execution pattern, not a claim about how long implementation “should” take.

First 30 days (Immediate stabilization)

• Assign control owner and publish the SC-7(28) control card (scope/parameter, exceptions, triggers).
• Identify in-scope components using CMDB, cloud inventory, and tagging standards.
• Freeze high-risk changes: require security review for any new internet-facing endpoint or public IP assignment in relevant environments.
• Stand up an “internet exposure” detection report and a remediation queue.

By 60 days (Preventive guardrails)

• Implement organization-level cloud restrictions for public IPs and internet-facing resources where feasible.
• Standardize network segmentation patterns for in-scope systems (private subnets, controlled ingress/egress).
• Document and rollout approved admin access patterns (VPN/ZTNA/bastion) and remove ad hoc direct access paths.
• Establish exception workflow with time-bound approvals and compensating controls.

By 90 days (Operational maturity)

• Run a control health check and produce a management-ready report: current exposure findings, exceptions, and remediation status.
• Automate evidence collection where possible (config exports, scan outputs, ticket links).
• Test the control: attempt to create a direct public connection in a controlled manner and verify guardrails block it; document results.
• Integrate third-party connectivity reviews into onboarding and periodic reassessment.

Frequently Asked Questions

What counts as a “direct connection” to a public network for SC-7(28)?

If an in-scope component can be reached from the public internet without an approved boundary control enforcing your policy, treat it as a direct connection. Document your organization’s interpretation in the control card so engineering and audit test the same rule. ¹

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

No. It means the components you define in the parameter cannot connect directly to a public network. You can still have public-facing services if they follow your approved boundary pattern and the prohibited components remain non-public. ¹

How should we handle administrative access for engineers?

Provide a controlled admin access path (for example, VPN or ZTNA into an admin network) and prohibit direct public exposure of admin interfaces for in-scope systems. Keep configuration evidence and access logs tied to that pattern.

What evidence is strongest in an audit?

Preventive configuration proof (org policies, network rules, IAM restrictions) plus recurring detection outputs showing no prohibited exposures, with tickets that show remediation when issues arise. Pair that with a clear scope definition and exception register. ¹

How do we manage third-party connectivity under SC-7(28)?

Treat third-party network connections as potential bypass paths and require architecture review before provisioning. Keep diagrams, approvals, and boundary control descriptions for each third-party connection that touches in-scope components.

What if a business team demands a temporary public endpoint “just for testing”?

Route the request through an exception process with a defined owner approval, compensating controls, and a clear expiration and rollback plan. Track it like a production risk item, not an informal workaround.

Footnotes

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

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

3. NIST SP 800-53 Rev. 5