Defining boundaries, environments, and system connections in your System Security Plan (SSP) is a foundational step for meeting Compliance Framework requirements—specifically NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control CA.L2-3.12.4—because it makes the scope of Controlled Unclassified Information (CUI) protection concrete, auditable, and actionable.
What CA.L2-3.12.4 Requires and How to Interpret It for Your SSP
At its core, CA.L2-3.12.4 requires that you explicitly define your system boundaries, operational environments (development, test, production, cloud, third-party), and every connection to and from the system that stores, processes, or transmits CUI. For the Compliance Framework, this means your SSP must: 1) list and describe system components; 2) show network and logical boundaries with diagrams; 3) enumerate inbound/outbound connections (IP ranges, ports, protocols, services); and 4) document connection owners and justification. The SSP should be detailed enough for an assessor to reproduce the architecture and understand trust relationships and interconnections.
How to Document Boundaries and Environments in Your SSP
Start with a top-down approach: document the organizational owner, the business function for each system handling CUI, and then map the physical and logical boundaries. Include a network diagram that differentiates VLANs/subnets, cloud VPCs, DMZs, jump hosts, and endpoints. For each environment (development/test/production), state whether CUI is present and, if not, how the environment is prevented from receiving CUI (e.g., sanitized test data, separate VPCs). Use a table for each connection listing source, destination, ports/protocols, encryption used (e.g., TLS 1.2+, IPsec), purpose, and an authorized owner.
Practical technical details to include
Be specific: include CIDR blocks (10.10.0.0/16), VLAN IDs, firewall rule snippets, and cloud security group examples. For AWS VPC connections, show VPC peering or Transit Gateway IDs and the specific security group rules (for example: sg-0a1b2c3d allow TCP 443 from 192.168.10.0/24). For on-prem firewalls include sample ACLs such as: permit tcp 10.1.1.0/24 172.16.1.10 eq 443 log. If using site-to-site VPN, document tunnel endpoints, cipher suites (e.g., AES-256-GCM), authentication (PSK vs. certificate), and NMS alerts that verify tunnel health. Include baseline host configurations—OS versions, local firewall rules (iptables/nftables or Windows Defender Firewall), and agents installed for logging.
Real-world small-business example
Consider a small defense subcontractor with 25 employees, an on-prem file server for CUI, Office 365 for email, and an AWS-hosted application for project collaboration. Their SSP should define: the on-prem network (10.0.0.0/24) with the file server on a separate VLAN (10.0.5.0/24), the AWS VPC (172.31.0.0/16), and the Office 365 SaaS connection. Document the on-prem-to-AWS VPN (public IPs, IKEv2, AES-256) and the outbound ports allowed to Office 365 (443 to Microsoft ranges). Show that CUI storage is restricted to the file server and an encrypted S3 bucket with SSE-KMS, and document that development environments do NOT have access to the file server. Attach diagram PNGs and a CSV of IP/port rules as evidence.
Compliance tips, evidence, and best practices
Best practices include: (1) use automated discovery (Nessus/Qualys/OTX) and asset inventory tools to populate your SSP and keep it current; (2) maintain a configuration management database (CMDB) or tagged cloud inventory so the SSP can reference live assets; (3) implement and document network segmentation that minimizes the CUI footprint; (4) include interconnection agreements or Memoranda of Understanding for third parties; and (5) store configuration snapshots (firewall rulesets, cloud security group exports, router configs) as artifacts. Evidence to attach: up-to-date network diagrams, runbooks for connections, firewall rule exports, VPN configuration files (sanitized for secrets), and change-control records showing approved modifications to the boundary.
Risk of not defining boundaries and connections
Failing to adequately define boundaries and system connections creates several concrete risks: undetected data exposure (CUI accidentally flowing into unprotected environments), expanded attack surface enabling lateral movement, and a lack of accountability for third-party connections that could introduce supply-chain risk. From a compliance perspective, an incomplete SSP often leads to findings during assessment, potential loss of contracts that require handling of CUI, and expensive remediation work that could have been avoided by proper upfront scoping and documentation.
Implementation practicality: treat the SSP as a living artifact. Use a version-controlled repository (Git) for diagrams and textual SSP content, automate exports of network and cloud configurations weekly, and tie SSP updates to change-control tickets so every boundary change is recorded. For small businesses, leverage templates: a one-page network diagram, a connection inventory CSV, and standard text blocks describing common services (SaaS, IaaS, VPN) that you can reuse across SSPs.
In summary, meeting CA.L2-3.12.4 in the Compliance Framework requires precise, technical, and auditable documentation of system boundaries, environments, and connections. Provide diagrams, concrete identifiers (CIDRs, VLAN IDs, security group IDs), connection details (ports, protocols, encryption), and artifacts (config dumps, change records) in your SSP. Doing so reduces security risk, speeds assessments, and demonstrates to stakeholders and assessors that your organization has intentionally limited and controlled the CUI attack surface.
