This post shows practical, actionable steps to create a system boundary diagram and a connectivity inventory that satisfy the intent of CMMC 2.0 / NIST SP 800-171-level evidence requirements such as CA.L2-3.12.4 — how to scope, discover, document, and maintain a living set of artifacts that auditors expect to see for Compliance Framework assessments.
Why a System Boundary Diagram and Connectivity Inventory are required
For Compliance Framework assessments, a system boundary diagram defines what is in-scope (where Controlled Unclassified Information — CUI — resides or flows) and what is out-of-scope; the connectivity inventory documents every logical and physical connection crossing that boundary. Together they demonstrate that you understand where CUI lives, how it moves, and which controls must be applied — essential evidence for CA.L2-3.12.4 and associated NIST SP 800-171 requirements.
Step-by-step: Build the System Boundary Diagram
1) Scope and identification: define CUI touch points
Start by listing where CUI is created, processed, stored, or transmitted. Use interviews with application owners and data owners, and review policies and contracts. For each system record: system name, owner, purpose, CUI type (e.g., contractor PII, technical data), and location (on-prem subnet, AWS account, Azure subscription). Scoping is a business decision — be conservative: if a system processes CUI even briefly, include it in-scope.
2) Discovery and verification: automated and manual
Combine automated discovery (Nmap for on-prem host discovery, Nessus/Qualys for asset scans, AWS CLI: aws ec2 describe-instances and aws ec2 describe-security-groups, Azure Resource Graph queries) with manual verification (application inventory, developer interviews). Capture IPs, hostnames, service ports, roles, and software versions. Flag remote access, vendor connections, and cloud-managed services (S3 buckets, managed DBs) that hold or move CUI.
3) Diagram creation: conventions and detail level
Create a visual that shows zones (user endpoints, app tier, data tier, DMZ, cloud services), trust boundaries, and ingress/egress points. Use standard symbols and label flows with protocols and ports (e.g., AppServer -> DB: TCP 5432, TLS1.2). Tools: draw.io, Visio, Lucidchart, or infrastructure-as-code visualizers. Store an export (PDF/SVG) in your evidence repository and maintain a source file under version control (Git, Confluence attachment) so changes are auditable.
Creating the Connectivity Inventory: fields and a sample entry
Your connectivity inventory is a table that maps every connection crossing the system boundary. Minimum fields to capture: Asset name, Asset ID / IP, Owner, Role, In-scope? (Y/N), Destination asset, Port/Protocol, Direction (inbound/outbound), Data type (CUI type), Encryption/Authentication, Connection method (VPN, TLS, API), Control/Mitigation (firewall rule, ACL), Evidence location (config file, firewall rule ID), Last validated date. Example single-record CSV line inside a paragraph for clarity: "Payroll-DB","10.0.2.5","Finance","Database","Y","Payroll-App","TCP/5432","inbound","Employee PII","TLS1.2","App-to-DB subnet only; Firewall rule FR-101","/evidence/firewall/FR-101.txt","2026-03-15".
Small-business scenario: concrete example and steps
Example: a 25-person engineering firm with one on-prem app server, an AWS account (S3 for backups), contractor VPN access, and remote employees. Steps they would take: 1) Identify CUI — design files and subcontractor PII stored in S3 and an on-prem Postgres DB. 2) Run an inventory: list the on-prem server IP, AWS account ID, S3 bucket names, and vendor endpoints. 3) Draw a diagram showing office LAN, firewall, VPN concentrator, app server, and AWS VPC with arrows labeled (S3 <-> Backup Agent: HTTPS, 443; Office -> AppServer: HTTPS 443; AppServer -> PayrollDB: TCP 5432). 4) Build the connectivity inventory rows for each arrow, including encryption and authentication mechanisms. 5) Apply compensating controls for vendor backups (restrict IPs, enforce SFTP over key auth) and document evidence for each control in a folder for the assessor.
Practical compliance tips and best practices
Make these artifacts living documents: require diagram + inventory updates for any change request that touches network, cloud, or vendor access; tie them into your change control and CMDB process. Tag assets with business-owner metadata and CUI flags; automate discovery where possible and reconcile automated results with owner-validated inventories quarterly or on every major release. Store evidence in a central, access-controlled repository with version history so you can show when and why a boundary moved.
Risk of not implementing or maintaining these artifacts
Without a clear boundary diagram and up-to-date connectivity inventory you risk uncontrolled CUI exposure, incomplete control coverage (e.g., missing firewall rules for a forgotten API), and failed compliance assessments. Practically, that can lead to lost contracts, remediation costs, contractual penalties, and reputational damage — and in incident response you’ll lose critical time trying to identify what was affected and how data moved.
Summary: Treat the system boundary diagram and connectivity inventory as primary compliance artifacts — scope conservatively, use automated discovery plus owner validation, capture detailed connection metadata (ports, protocols, encryption, owner, evidence), and integrate maintenance into change control. For small businesses this is achievable with inexpensive tools (draw.io, simple CSV inventories, cloud CLI scripts) and disciplined processes that show assessors you control where CUI lives and how it flows, meeting the intent of CA.L2-3.12.4 under the Compliance Framework.
