SC-7(22): Separate Subnets for Connecting to Different Security Domains

SC-7(22) requires you to assign separate network addresses (separate subnets or equivalent routed segments) when connecting systems that belong to different security domains, so traffic between domains is explicitly routed and governed by enforceable boundary controls. Operationalize it by defining domains, mapping subnet-to-domain, blocking “flat” pathways, and retaining proof that segmentation is implemented and maintained. ¹

Key takeaways:

• Treat “different security domains” as distinct trust zones with explicit routed boundaries and enforced policy.
• Implement subnet separation plus boundary enforcement (firewalls/ACLs/SGs) and document the subnet-to-domain mapping.
• Keep assessor-ready evidence: diagrams, IPAM exports, configs, change records, and periodic validation results.

The sc-7(22): separate subnets for connecting to different security domains requirement is a segmentation control: different security domains must not share the same network address space in a way that collapses trust boundaries. The fastest way to implement it is to define your security domains (for example: production vs. corporate IT, regulated tenant vs. non-regulated tenant, management plane vs. workload plane), then allocate dedicated subnets per domain so inter-domain traffic must traverse an intentional boundary where you can enforce and log policy.

This control shows up in real assessments as a “prove it” item. Auditors typically ask for your network diagram, your list of subnets, and a demonstration that sensitive systems are not reachable over the same flat network as less trusted systems. If you cannot show subnet separation and boundary enforcement, you will spend time debating intent. Your goal is to remove ambiguity: one domain, one set of subnets, with controlled pathways between them.

This page gives requirement-level implementation guidance you can execute quickly: scope, design decisions, step-by-step execution, and the evidence pack you should retain for assessment readiness. ²

Regulatory text

Requirement (SC-7(22)): “Implement separate network addresses to connect to systems in different security domains.” ¹

Operator interpretation:

• “Separate network addresses” means different IP networks (subnets) or equivalently routed segments that are distinct in IP addressing and routing policy.
• “Different security domains” means environments with different trust assumptions, authorization models, or data sensitivity where you need a boundary you can enforce (not a shared broadcast or flat L2 segment).
• Practically: if two system groups are in different security domains, they should not sit in the same subnet or share the same network address segment as a default. Traffic should cross a controlled boundary where you can restrict, monitor, and document access.

Plain-English interpretation (what SC-7(22) is really asking)

SC-7(22) asks you to prevent “implicit trust” created by shared addressing. If systems from different security domains share the same subnet, lateral movement becomes easier, boundary enforcement gets inconsistent, and it becomes hard to prove separation during an exam. Separate subnets force inter-domain communication to be deliberate: routed, inspected, and governed.

This is not a purely theoretical network architecture preference. It is an operational requirement to make security boundaries enforceable and auditable with tangible artifacts: IP ranges, route tables, firewall rules, and diagrams. ¹

Who it applies to (entity and operational context)

Entity types

• Federal information systems and programs implementing NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST SP 800-53 is in scope via contract, authorization, or flow-down requirements. ²

Operational contexts where SC-7(22) becomes a “must show” control

• Mixed-trust networks: corporate IT connected to production, or shared services connected to regulated workloads.
• Cloud environments with multiple VPCs/VNETs, shared transit, or hub-and-spoke where domain boundaries can blur.
• Third-party connectivity: dedicated partner links, VPNs, and vendor-managed support access that lands in sensitive environments.
• OT/ICS, labs, or legacy networks where “temporary” flat networks become permanent.

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

Step 1: Define and approve your security domains

Create a short list of domains that matter for your system boundary and risk model. Common domain definitions:

• Enterprise IT (end-user devices, SaaS access, email)
• Production workloads (apps, databases)
• Regulated zone (CUI/PII/PHI or mission systems, as applicable)
• Management plane (AD, IAM, hypervisor mgmt, cloud control tooling)
• Third-party access zone (vendor jump hosts, support tooling)

Artifact: “Security Domain Definitions” one-pager approved by the CISO/CCO/GRC lead and Network/Security Engineering.

Step 2: Build a subnet-to-domain mapping (the heart of SC-7(22))

For each domain, allocate dedicated IP ranges and subnets. Record:

• Domain name
• Environment (prod/non-prod)
• IP ranges (CIDRs), VLAN IDs (if applicable), VPC/VNET identifiers (if applicable)
• Purpose and system owners
• Allowed ingress/egress and required boundary control points

A simple table is enough, but it must be authoritative.

Decision rule: if two systems are in different security domains, they must not share a subnet. If they must communicate, require a routed path through a documented boundary where rules are enforced and logged.

Step 3: Implement routing boundaries and enforceable policy

Separate subnets alone are not the finish line. You must ensure that inter-domain traffic crosses a control point you can manage. Depending on your environment:

• On-prem: inter-VLAN routing limited through firewalls or L3 ACLs; prohibit “any-any” between domain SVIs.
• AWS: separate subnets inside separate VPCs for different domains, connected via TGW/peering only as needed; control with Security Groups, NACLs, and centralized firewall where required.
• Azure: separate subnets inside separate VNets for different domains; use NSGs and Azure Firewall/route tables where required.
• GCP: separate subnets/VPCs; enforce with VPC firewall rules and controlled interconnect.

Your implementation should make it easy to demonstrate:

• Which subnets belong to which domain.
• Where the boundary is.
• Which rules allow which flows, and why.

Step 4: Eliminate “flat” exceptions and hidden paths

Common hidden paths that violate the spirit of SC-7(22) even if subnets exist:

• Shared “utility” subnets hosting mixed-domain servers.
• Shared jump boxes used for both corporate IT administration and production administration without separation.
• Legacy VPN profiles that drop third parties into an internal subnet that also hosts sensitive workloads.
• “Temporary” routes, permissive firewall rules, or bypass links that effectively bridge domains.

Create an exceptions register for any case where you cannot immediately separate subnets. Put an owner and a remediation plan on each exception.

Step 5: Validate segmentation continuously (don’t wait for an audit)

Perform repeatable checks that prove subnet separation and boundary enforcement:

• IPAM export review: subnets match the domain map.
• Route table review: only intended inter-domain routes exist.
• Firewall/SG/NSG rule review: least-privilege paths only.
• Connectivity tests: verify sensitive domain assets are unreachable from lower-trust domains unless explicitly allowed.

Make this a scheduled control activity with recorded outputs and change linkage.

Step 6: Assign a control owner and operational cadence

SC-7(22) breaks down when nobody owns the subnet map. Assign:

• Control owner: Network Security or Cloud Platform Security
• GRC owner: maps evidence to assessment requirements, runs periodic attestations
• Change control: subnet creation, route changes, firewall policy changes must reference the domain map

If you use Daydream for control operations, tie SC-7(22) to a named owner, a documented procedure, and a recurring evidence checklist so audit requests don’t turn into a diagram scramble. ¹

Required evidence and artifacts to retain

Keep artifacts that prove design and operation. Assessors usually accept exports and screenshots if they are dated, scoped, and attributable.

Minimum evidence pack

• Approved security domain definitions and scope statement.
• Current network diagram showing domain boundaries and control points.
• Subnet-to-domain mapping table (authoritative inventory).
• IPAM exports (or cloud subnet inventory exports) that match the mapping.
• Route table exports showing controlled inter-domain routes.
• Firewall/ACL/SG/NSG rule sets for boundary enforcement.
• Change tickets linking subnet/routing changes to approvals.
• Periodic validation results (connectivity tests, config review notes) with findings and remediation actions.

Common exam/audit questions and hangups

1. “Define ‘security domain’ for your environment.” Expect pushback if domains are informal or inconsistent across teams.
2. “Show me the subnets for the regulated zone and how traffic is controlled.” They will want both the subnet list and the enforcement point.
3. “Are there shared services in the same subnet across domains?” DNS, logging, and management tooling are frequent offenders.
4. “How do you prevent a new subnet from being created in the wrong domain?” This tests governance and change control, not diagrams.
5. “How do third parties connect, and what subnet do they land in?” Third-party access is a high-scrutiny pathway.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SC-7(22) in practice	Fix
“We have VLANs, so we’re good” but inter-VLAN routing is permissive	Domains exist on paper, but policy doesn’t enforce separation	Put inter-domain routing behind a firewall or explicit L3 ACLs; document control points
Mixed-domain “shared services” subnet	Creates implicit trust between domains	Split shared services per domain or force access through controlled gateways
Cloud: one VPC/VNET with many subnets but no boundary enforcement	Address separation exists, but domain separation is weak	Treat domains as separate VPCs/VNETs or enforce strict route and firewall policy between subnets
Exceptions handled informally	Audit sees unmanaged risk	Use a formal exceptions register with compensating controls and a plan
No evidence cadence	Control exists but cannot be proven over time	Schedule exports/reviews and retain dated outputs tied to tickets

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement context as assessment-driven rather than case-law-driven here.

Risk-wise, SC-7(22) reduces the blast radius of credential theft, malware propagation, and misconfiguration. It also improves auditability: subnet separation gives you a clear, testable claim about where systems live and how domains connect. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and build the map)

• Name the security domains and get written approval.
• Produce a current-state network diagram with domain boundaries.
• Export current subnet inventories (on-prem and cloud) and draft the subnet-to-domain mapping.
• Identify the top exception paths (shared admin, shared subnets, third-party VPN landing zones) and open remediation tickets.

Day 31–60 (enforce boundaries and remove the worst pathways)

• Implement or tighten boundary controls between domains (firewall/ACL/SG/NSG) and remove broad rules.
• Split or relocate mixed-domain subnets starting with the highest sensitivity domain.
• Put third-party access into a dedicated access zone subnet with controlled paths to targets.
• Stand up a repeatable validation method (route review + connectivity tests) and store results.

Day 61–90 (operationalize and make it assessment-ready)

• Embed subnet-to-domain checks into network/cloud change management.
• Create an exceptions register workflow (approval, compensating control, expiry/remediation plan).
• Run a tabletop audit: respond to the common audit questions using only retained artifacts.
• In Daydream (or your GRC system), map SC-7(22) to the control owner, procedure, and recurring evidence artifacts so you can reproduce the evidence pack on demand. ¹

Frequently Asked Questions

Does SC-7(22) require separate physical networks?

No. The text requires separate network addresses for different security domains, which you can meet with separate subnets and enforceable routed boundaries. Physical separation can be a design choice, but the requirement focuses on address separation and domain connectivity control. ¹

Can I meet the requirement with VLANs only?

VLANs typically imply separate subnets, but the passing condition is that different security domains connect using separate network addresses. You still need boundary enforcement so domains do not effectively behave like one flat network. ¹

What counts as a “different security domain” in a cloud environment?

Treat domains as distinct trust zones: production vs. corporate, regulated vs. non-regulated, management plane vs. workload plane, and third-party access vs. internal admin. Your domain definitions must be documented and mapped to dedicated subnets. ²

If two domains must communicate frequently, do they still need separate subnets?

Yes. Separate subnets force traffic through a controlled boundary where you can allow only the required ports and systems. Frequent communication is an access policy problem, not a reason to collapse domains into one subnet. ¹

What evidence is usually most persuasive to an assessor?

A subnet-to-domain mapping tied to IPAM/cloud exports, plus route tables and firewall/SG rule sets that show controlled inter-domain paths. A diagram helps, but the exports and configs prove the claim. ¹

How do I handle legacy systems that cannot be readdressed quickly?

Track them as explicit exceptions with compensating controls (tighter firewall rules, dedicated jump access, monitoring) and a remediation plan. Make the exception visible, owned, and time-bounded so it doesn’t become your permanent operating model. ²

Footnotes

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

2. NIST SP 800-53 Rev. 5