This post provides a practical, implementation-focused checklist for AC.L1-B.1.IV under FAR 52.204-21 and CMMC 2.0 Level 1 — the requirement addressing controls for information posted or processed on public systems — with concrete steps, technical controls, and small-business scenarios to turn compliance intent into repeatable operational controls within your Compliance Framework.
Practice, Requirement & Key Objectives
The practice AC.L1-B.1.IV directs organizations to ensure that Federal Contract Information (FCI) or other controlled information is not unintentionally exposed or processed on public systems without appropriate protections. Key objectives are: 1) identify what information is permitted to be public, 2) prevent accidental publication of FCI on public services (public cloud buckets, public file shares, code repos, SaaS file stores), and 3) apply compensating controls (sanitization, access controls, monitoring) where public processing or posting is unavoidable. Within your Compliance Framework, this practice sits under access control and information protection activities.
What this means for small businesses
For a small business with limited security staff, the practical interpretation is simple: treat any system accessible over the public internet as hostile by default. Examples include marketing websites, public S3 buckets, shared Google Drive folders, GitHub/GitLab repositories, and third-party SaaS apps. Your Compliance Framework must define which content is allowed publicly, create clear approval gates before publishing, and implement technical guards to stop common misconfigurations that lead to data exposure.
Step-by-step Implementation Checklist (practical actions)
Use the following checklist as discrete tasks in your Compliance Framework: 1) Inventory and classify assets and content so you know where FCI might reside (scan cloud storage, code repos, web servers). 2) Enforce a "no FCI on public systems" policy except via approved, documented exceptions. 3) Harden public-facing services with minimal permissions (disable public-read on S3/Azure Blob/GCS by default; enable AWS S3 Block Public Access/Azure Blob public access prohibition; set Google Cloud Storage uniform bucket-level access). 4) Implement pre-publish approvals and automation (CI/CD checks, pre-commit hooks that run gitleaks/trufflehog/git-secrets) to block credentials/PII/FCI from being pushed. 5) For approved public processing, implement content sanitization (PDF redaction, metadata stripping via exiftool), encrypt-at-rest and in transit, and use short-lived signed URLs or OAuth-limited access tokens rather than permanent public objects.
Technical controls and configuration examples
Technical specifics matter: for AWS S3, enable Block Public Access at account and bucket level, set bucket policies to deny s3:GetObject except for specified principals, enable server-side encryption (SSE-S3 or SSE-KMS), and enable access logging (S3 server access logs or CloudTrail). For web servers, disable directory listing, remove .git and backup files, and add HTTP security headers (Content-Security-Policy, Referrer-Policy, X-Content-Type-Options). For SaaS file sharing (Google Drive/Box/OneDrive), enforce organization-wide sharing defaults to "restricted" and require DLP rules to scan uploads for keywords or patterns that indicate FCI; integrate with CASB if possible. For CMSs (WordPress/Joomla), lock down uploads directory, use file type whitelists, and run file integrity monitoring to detect unexpected public-facing files.
Monitoring, detection, and response
Detection is as important as prevention. Add automated scans (cloud bucket scanners, GitHub secret scanning, web crawlers) to your Compliance Framework with a schedule (daily/weekly based on risk). Forward logs to a central log collector or SIEM: CloudTrail, S3 access logs, web server logs, and WAF logs. Create alert playbooks for high-severity findings (exposed bucket containing contract PDFs) that include immediate takedown steps (revoke public permissions, rotate keys, obtain forensic copies) and notification steps (inform contracting officer per FAR clause if FCI was exposed). Document an incident response runbook with roles defined for small teams (who revokes access, who notifies customers or contracting officers, who conducts root cause analysis).
Real-world small-business scenarios and remediation
Scenario 1: A marketing employee uploads a vendor contract PDF with pricing to a company Google Drive folder set to "Anyone with the link." Remediation: immediately switch the folder to restricted, remove the shared link, run a search for other similar files, redact or remove sensitive pages, notify the contracting officer if FCI was involved, and add a short training module for staff. Scenario 2: Developer pushes credentials to a public GitHub repo. Remediation: remove the secret from the commit history (git filter-repo or BFG), revoke and rotate exposed credentials, enable mandatory pre-commit hooks and secret scanning in CI, and make public repositories read-only for the main branch until the team follows the commit hygiene checklist. Scenario 3: S3 bucket accidentally set to public-read exposing invoices. Remediation: enable S3 Block Public Access, set the bucket policy to deny public access, audit access logs to determine exposure window, rotate any keys and credentials found in exposed objects, and update your Compliance Framework to require automated bucket policy checks as part of CI/CD or cloud infra-as-code validation (e.g., terraform plan + checkov).
Compliance tips, best practices and risks of non-implementation
Best practices: automate as much as possible (prevention is scaleable), keep an up-to-date asset inventory, require documented exceptions with compensating controls, include compliance checks in procurement and vendor onboarding, and train non-technical staff quarterly on what not to publish. Use simple, low-cost tooling that works for small teams: Cloud provider built-ins (AWS Config rules, Azure Policy), free scanners (gitleaks, trufflehog), and automated redaction scripts. The risk of not implementing AC.L1-B.1.IV is significant: inadvertent exposure can lead to contract penalties, loss of future government work, reputational damage, and potential legal obligations to notify customers or contracting officers. Even if the information is not CUI, the contractor must show due care under FAR 52.204-21 to avoid audit findings or loss of eligibility.
Summary: Turn AC.L1-B.1.IV from a policy statement into a set of repeatable operations — inventory and classify public systems and content, default-block public exposure, automate pre-publish and detection controls, apply technical hardening (bucket policies, encryption, signed URLs), and document incident response and approval processes inside your Compliance Framework. For small businesses, prioritize low-cost automation, clear publishing approvals, and staff training so you can demonstrate to auditors and contracting officers that public systems are treated as hostile and FCI is actively controlled.
