This post gives a practical, actionable compliance checklist to help small businesses implement FAR 52.204-21 basic safeguarding requirements and meet CMMC 2.0 Level 1 control AC.L1-B.1.IV for publicly accessible information systems, with technical examples, audit evidence suggestions, and low-cost mitigations.
Understanding the requirement
At a high level, FAR 52.204-21 and CMMC Level 1 focus on "basic cyber hygiene"—protecting contractor information systems that process, store, or transmit federal information (including Controlled Unclassified Information, when applicable). The AC.L1-B.1.IV control addresses risks introduced by publicly accessible systems (websites, APIs, public cloud storage, admin portals) and requires you to apply basic access and protection measures so that public-facing assets do not become an easy path for data exposure or compromise.
Practical compliance checklist (inventory, scope, and segmentation)
Begin by inventorying all publicly accessible systems as the first checklist item: domain names, hosting providers, CDN endpoints, public cloud storage (e.g., S3 buckets or Azure Blob containers), externally accessible APIs, and any self-hosted admin consoles. Record software versions, responsible owners, and the data types exposed. Next, apply network and logical segmentation: place any systems that handle sensitive data behind authenticated services or isolated subnets and ensure only strictly required ports (for a public website, typically 80/443) are open in firewall/security group rules.
Practical checklist (access control, authentication, and hardening)
Implement least-privilege access: remove default accounts, enforce unique admin credentials, and enable multi-factor authentication (MFA) for all admin and vendor accounts. For public-facing services, ensure TLS (TLS 1.2 or higher) is configured with strong ciphers and automated certificate renewal (Let's Encrypt or managed certs from your cloud provider). Keep web and application software patched on a defined cadence (monthly at minimum) and subscribe to vulnerability alerts for components you use (CMS plugins, libraries). Disable directory listing, unused modules, and debug endpoints on production sites.
Technical implementation examples
Use low-cost, high-impact technical controls: deploy a Web Application Firewall (WAF) or managed WAF rules (Cloudflare, AWS WAF, Azure Front Door) to block common attack patterns; enable rate-limiting to mitigate basic abuse. For cloud storage, check S3 ACLs and policies with a command like aws s3api get-bucket-acl --bucket your-bucket and correct by setting a bucket policy that denies public access. For an NGINX-hosted site add headers: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; add_header X-Content-Type-Options nosniff; and disable autoindex with autoindex off;. For Apache, ensure Options -Indexes to disable directory listing. These specifics are easy to document as evidence during an assessment.
Real-world small business scenarios and examples
Example 1: A small engineering firm hosts a WordPress blog on a public server and stores proposal PDFs in an S3 bucket. Action: inventory the bucket, run aws s3api get-public-access-block --bucket your-bucket to confirm public access is blocked, enable MFA for AWS console users, and apply a WAF rule to block common WordPress attack signatures. Example 2: A subcontractor exposes a REST API for customers; implement TLS, require API keys with rate limits, log every authentication attempt, and place the API behind a reverse proxy that enforces IP and geo restrictions when appropriate.
Evidence collection and audit-readiness
Prepare simple, verifiable evidence: an inventory spreadsheet with hostnames and ownership, screenshots of cloud console settings (public access block, security groups), output from commands used to verify configuration, change tickets for patching and hardening, and log retention screenshots showing access and WAF logs. Create a short SOP that describes how you onboard a new public system (inventory entry, baseline hardening checklist, monitoring configuration) and retain it for assessors. Keep artifacts for at least 12 months to demonstrate continuous compliance.
Risks of not implementing AC.L1-B.1.IV
If you fail to secure publicly accessible systems you risk data exposure (publicly readable storage, leaked sensitive files), unauthorized access to dashboards or APIs, and being used as a pivot point into internal networks. These risks can lead to contract penalties, loss of customers, reputational damage, and incident response costs. For small businesses, a single misconfigured S3 bucket or outdated CMS plugin is a common route to breach—these are low-effort targets for opportunistic attackers.
Compliance tips and best practices
Keep the checklist lightweight and repeatable: automate periodic scans (use AWS Trusted Advisor, open-source scanners like Trivy for images, Nikto or OWASP ZAP for web scans) and schedule a quarterly review. Use templates: a baseline hardening checklist for servers/web apps, a cloud storage policy template, and an incident response contact list. Document accepted risks as formal exceptions with compensating controls and review them at least every 90 days. Finally, train staff on phishing and credential hygiene—most breaches start with compromised credentials, not exotic exploits.
Summary: By inventorying publicly accessible assets, applying basic hardening (TLS, MFA, patching), using managed edge controls (WAF, CDN), and collecting simple evidence artifacts, a small business can satisfy FAR 52.204-21 / CMMC 2.0 Level 1 AC.L1-B.1.IV requirements without heavy investment; start with an actionable checklist, automate where possible, and document everything to make audits straightforward and to reduce real-world risk.
