Meeting FAR 52.204-21 and CMMC 2.0 Level 1 requirements for access control (AC.L1-B.1.IV / Control 547) is about proving that only authorized users and processes can access Federal Contract Information (FCI) and that those controls are implemented, tracked, and reproducible; this post explains the exact artifacts assessors want to see, step-by-step implementation tips for small businesses, practical technical examples, and the risks of not getting it right under the Compliance Framework.
Understanding the requirement and key objectives
The key objective for this access-control requirement under the Compliance Framework is simple: ensure that accounts, privileges, and access mechanisms are controlled and demonstrably restricted to authorized users, and that access decisions are auditable. For a CMMC Level 1 / FAR 52.204-21 posture you must show basic safeguarding of FCI — not enterprise-grade zero-trust architecture, but clear evidence that access is granted on a need-to-know basis, authentication is enforced, and access activities are logged.
Evidence and artifacts you must collect
Assessors will expect tangible artifacts. Prepare the following items in searchable, timestamped formats: an Access Control Policy (access_control_policy_v1.docx), Account Provisioning Procedures (acct_provisioning SOP.pdf), exports of group membership and ACLs (AD_GroupExport_2026-03-01.csv), screenshots or reports proving MFA is enabled (MFA_Report.png), authentication and access logs (Windows_Security_Events_Q1.zip or AzureSignInLogs_202603.csv), periodic user access review records (UserAccessReview_2026-Q1.xlsx), a current system inventory showing where FCI resides (system_inventory.yaml), and any exception or temporary-access approvals (temp_access_approvals.pdf). Name, date, and store these artifacts in your evidence repository (for example, a dedicated SharePoint folder or a secure evidence bucket in S3 with versioning enabled).
Practical implementation steps (Compliance Framework specific)
Small businesses can meet this requirement quickly by following a prioritized implementation plan that aligns with the Compliance Framework: 1) Identify systems that store/process/transmit FCI and map users to those systems. 2) Enforce authentication — enable MFA for all accounts that access those systems (Azure AD Conditional Access policy, Google Workspace 2-step enforcement, or Okta policy). 3) Implement least privilege: create role-based groups (e.g., FCI_ReadOnly, FCI_Edit) and assign rights via group membership rather than direct ACL edits. 4) Record and retain logs: configure Windows Event Forwarding or cloud audit log export so security events (successful and failed logons, privilege escalation) are retained for at least 90 days. 5) Formalize procedures: use a simple SOP for account creation/deactivation, and require periodic (quarterly) reviews. For small Windows-centric shops, example PowerShell command to export an access list: Get-ADGroupMember -Identity "FCI_Editors" | Export-Csv .\FCI_Editors_Export_2026-03-01.csv -NoTypeInformation. For Linux systems, document /etc/sudoers entries, run sudo -l for privileged users, and capture output to evidence files.
Real-world small-business scenarios
Scenario A — 25-person engineering firm using Microsoft 365 and a single Windows file server: the firm creates two AD groups (FCI_View, FCI_Edit), moves all FCI into a clearly named share (\\fileserver\FCI), sets NTFS permissions to group-based access only, enables Azure AD MFA for all accounts, and exports group membership + NTFS ACLs as CSVs/screenshots. Evidence folder includes the Access Control Policy, the group export, a screenshot of Azure AD Conditional Access policy, and access-review spreadsheets signed by the IT manager. Scenario B — 12-person subcontractor using Google Workspace and third-party project tools: the subcontractor centralizes FCI in a single Google Drive folder, uses Workspace groups to control sharing, enables 2-step verification enrollment report, documents the onboarding/offboarding checklist, and retains Drive activity logs for 90 days for export to the evidence repository.
What assessors will verify — technical detail
Assessors will validate: policy existence and applicability; actual system configuration matching the policy; logs showing authentication events; evidence of periodic access reviews; and that temporary access was granted with approvals and expiry. Technically, be prepared to provide time-bound logs (with timestamps in UTC), evidence that MFA was enforced (conditional access policy export or vendor report), ACL exports (AD/Unix/Cloud service) showing group names and membership, and any automation scripts used for provisioning (PowerShell, Terraform, or Google Workspace admin APIs). Example command for Windows event export: Get-WinEvent -FilterHashtable @{LogName='Security';Id=4624;StartTime=(Get-Date).AddDays(-90)} | Export-Csv .\LogonEvents_90days.csv -NoTypeInformation. Ensure log integrity by noting collection times and storing originals; if you truncate logs, retain hashes or copies to prove completeness.
Best practices and compliance tips
Keep evidence simple, consistent, and self-descriptive — name files with timestamps and brief descriptions. Automate routine evidence collection where possible (scheduled scripts that export group membership and sign them with a hash). Enforce least privilege and use groups/roles instead of per-user ACLs. Schedule quarterly user access reviews and save the signed review spreadsheets. Maintain an exceptions register with justification and expiration dates. For small teams, leverage managed services (Azure AD, Google Workspace, Okta, Duo) to reduce operational burden and produce built-in reports that map directly to auditor queries. Finally, document retention policy for evidence (e.g., logs 90 days, policies 3 years) and reflect that in your Compliance Framework paperwork.
Risks of not implementing the requirement
Failure to implement and demonstrate control 547 can expose FCI to unauthorized disclosure, increase the likelihood of account misuse, and create audit findings that delay contract award or result in corrective actions such as a Plan of Action and Milestones (POA&M). Beyond contractual risk, there are real operational and reputational consequences: a breach could lead to remediation costs, loss of subcontracting opportunities, and in some cases legal or contractual penalties. From an assessor perspective, incomplete or inconsistent evidence is often treated the same as ineffective controls, so sloppy documentation is as risky as misconfiguration.
Summary: To prepare for a CMMC 2.0 Level 1 assessment of AC.L1-B.1.IV (Control 547) under FAR 52.204-21, small businesses should inventory FCI, enforce authentication (MFA), apply least-privilege via groups/roles, collect and retain access/configuration logs, and assemble a clear evidence package (policies, ACL exports, MFA reports, access reviews). Automate exports, keep timestamps and file hashes, and run quarterly reviews — these practical steps align to the Compliance Framework and drastically reduce assessor friction while lowering your risk of data exposure.
