This post explains how a small business can collect and present concrete evidence, and perform practical tests, to demonstrate compliance with FAR 52.204-21 and the CMMC 2.0 Level 1 practice SC.L1-B.1.X (System & Communications Protection-related basic safeguards) using an auditable, repeatable Compliance Framework approach.
What the control means in practice
While the exact text of SC.L1-B.1.X is scoped to basic protections of Federal Contract Information (FCI) or other covered information, in practice this control requires you to identify the data flows and enforce simple protections on networks and communications — for example, ensuring only authorized protocols and ports are exposed, encryption is used where required, and boundary devices (firewalls, routers, cloud security groups) implement approved rules. For Compliance Framework implementations, translate the control into: (a) a clear scope and data flow diagram showing where FCI resides or transits, (b) technical baselines for communications (allowed ports, required TLS versions, approved VPNs), and (c) operational evidence showing the baselines are enforced day-to-day.
Types of evidence you should collect
Auditors and assessors expect a mix of policy-level artifacts and technical artifacts. Start with scope-defining documents: a system/network diagram (PDF), an inventory of devices and cloud instances (CSV), and a policy or standard that states the allowed communication protections (DOCX/PDF). Technical artifacts include firewall/security group configuration exports, screenshots of ACLs or security group rules, exported router configs, TLS certificate details (subject, fingerprint, expiration), and centralized logs (syslog, CloudTrail, or SIEM) showing connections and enforcement events. Include change-control records (pull requests or change tickets), and retention metadata (when logs were archived and by whom).
Concrete testing methods and sample procedures
Design simple, reproducible tests that an assessor can repeat. Combine three test types: document review, interview/observation, and technical verification. Examples of technical checks: 1) Verify TLS by running: openssl s_client -connect hostname:443 -tls1_2 and capture the certificate chain and negotiated protocol. 2) Validate open ports from the external perspective with nmap -sT -p1-65535 hostname and export the results. 3) Confirm firewall rules by exporting the running configuration (for example, Cisco: show running-config | include access-list) or an AWS security group JSON export. 4) Search centralized logs for blocked connection attempts: e.g., use a query in your SIEM for "action:deny AND destination_port:3389" for the previous 90 days and export the results.
Small-business example scenario
Imagine a 20-person IT services firm that stores minimal FCI on a single web application hosted in AWS and uses Office 365 for email. To demonstrate SC.L1-B.1.X compliance the firm prepares: a simple network diagram showing the web app, the VPC subnet, and the Office 365 flow; an AWS security group export showing only ports 80/443 allowed to the web tier; CloudTrail logs showing administrative changes with timestamps; an exported IIS/Nginx configuration showing TLS 1.2+ only; and a screenshot of the M365 transport rule that prevents unencrypted forwarding of internal contract documents. For a test, the assessor runs an external nmap and an openssl check against the web app, reviews the exported security group JSON, and inspects CloudTrail entries proving no unauthorized security group changes were made in the past 90 days.
Implementation tips and best practices
Use automation and source control: keep firewall/security-group templates and router configs in a version-controlled repo so you can show diffs for changes. Centralize logging and retain at least 90 days of logs for technical tests and 12–24 months for policy artifacts depending on contract terms. Label FCI systems and data stores so evidence reviewers can quickly map artifacts to scope. Use simple runbooks for testing (e.g., "Test TLS: run openssl s_client... capture output") and schedule quarterly scans (nmap, endpoint vulnerability scans) with documented remediation timelines. For cloud environments, export IAM policies and use automated tools (AWS Config, Azure Policy) to show continuous compliance status.
Risks of not implementing and documenting the control
Failing to implement these basic protections — or failing to retain demonstrable evidence — increases the risk of unauthorized disclosure of FCI, contract noncompliance, lost contracts, and reputational damage. Technical risks include exposed management ports, weak TLS stacks, or permissive security groups that enable lateral movement. Operational risks include being unable to prove that a communication control was in place at a specific time (for example, during a suspected incident), which can lead to failed assessments or corrective action plans that are costly for a small business.
To summarize: define your scope, collect both policy and technical artifacts, and create reproducible tests that an assessor can run. For most small businesses, practical steps are: document where FCI flows; export firewall/security-group configs; centralize and retain logs; run and save TLS and port scans; keep configuration and change records in source control; and schedule regular, documented tests. These concrete artifacts and procedures make FAR 52.204-21 / CMMC Level 1 evidence repeatable, auditable, and defensible.
