This post gives a practical, implementation-focused checklist for AC.L1-B.1.I — an Access Control practice within the Compliance Framework commonly used to satisfy FAR 52.204-21 / CMMC 2.0 Level 1 basic safeguarding requirements — showing the policies you need, the technical controls to implement, and the audit evidence to collect for a small business to demonstrate compliance.
\n\nAt a high level AC.L1-B.1.I is an access-control practice: ensure only authorized users have access to covered systems and data, and that access is controlled and auditable. For organizations subject to FAR 52.204-21 and CMMC 2.0 Level 1, this practice typically maps to basic controls like unique user IDs, access limitation, and simple session/account management; the goal is to provide demonstrable, repeatable controls that protect Federal Contract Information (FCI) or other sensitive business information.
\n\nStart by documenting policy and procedure items that are concise, actionable, and tailored to the Compliance Framework scope. Minimum checklist items: an Access Control Policy (scope, roles, responsibilities), Account Management Procedure (provisioning/deprovisioning workflow and owner), Password/Authentication Standard (complexity, rotation, reuse), Remote Access Policy (VPN/remote desktop controls), and an Audit & Logging Retention Policy (what logs are retained and for how long). For each policy include: effective date, approver, review cadence (annually or on major change), and mapping to the practice AC.L1-B.1.I.
\n\nExample small-business policy entry: \"All user accounts must be uniquely identifiable; shared accounts are allowed only for service accounts and must be documented, approved by IT and reviewed quarterly.\" Include a short checklist item in procurement/HR handbooks so new hires are provisioned with the correct level of access and departing employees are deprovisioned within 24 hours.
\n\nTranslate policies into technical controls you can implement with minimal cost. Key technical controls: unique user accounts, account disablement after inactivity, session timeout, principle of least privilege (role-based groups), and basic logging of authentication and access events. Concrete examples: On Windows use Group Policy to set password complexity (Minimum password length 12), account lockout threshold (5 invalid attempts), and maximum password age (90 days). Command-line examples: Windows – \"net accounts /minpwlen:12 /lockoutthreshold:5 /lockoutwindow:30\". On Linux, enforce pwquality via /etc/pam.d/common-password and set chage -M 90 for maximum password age; use faillock or pam_faillock.so to lock after failed attempts. In cloud (Azure AD/Okta), create a Conditional Access policy enforcing MFA for administrative roles and for any remote access to corporate resources, and enable Sign-in logs retention for 90 days.
\n\nDocument and technically enforce how service accounts are handled: mark them as non-interactive, store credentials in a password vault (e.g., HashiCorp Vault, Azure Key Vault, 1Password Business), and rotate credentials on a schedule. For network-level access, implement simple firewall rules and VLAN segmentation so contractor laptops cannot directly access management networks. Example firewall ACL snippet (Cisco IOS): \"access-list 101 permit tcp any host 10.10.10.5 eq 3389\" to restrict RDP to a single jump box, then log hits with \"ip access-list extended 101\" and \"log\".
\n\nAuditors want clear, objective evidence that controls exist and work. Collect policy documents with signatures and review dates, account inventory exports (CSV of active accounts, creation date, last login), group membership snapshots showing least-privilege assignments, screenshots or export of group policy objects, system configuration files (/etc/login.defs, pam configs), and logs showing account disablement or access events. Include a sample deprovisioning ticket trail from your helpdesk (ticket ID, time stamp, account disabled) and a record of quarterly access reviews signed by the reviewer. Keep evidence organized in a folder structure (Policies/, Configs/, Logs/, Tickets/) and retain evidence per your Audit & Logging Retention Policy (commonly 1–3 years for Level 1 evidence unless contract requires otherwise).
\n\nScenario: a 20-person engineering consultant with a single on-prem server, cloud file storage (Microsoft 365), and remote workers. Practical steps: (1) scope systems that process or store FCI, (2) create a simple Access Control Policy and an account provisioning checklist, (3) enable unique accounts in Azure AD and set self-service password reset, (4) enforce SSO+MFA for remote access and cloud apps, (5) implement GPO/password and lockout settings on Windows endpoints, (6) configure logging (Windows Event Forwarding to a lightweight SIEM or central log store), and (7) schedule quarterly access reviews and backlog deprovisioning tickets. Example timeline: policy + inventory (week 1), apply technical configs and MFA (week 2–3), collect baseline evidence and run simulated access-review (week 4).
\n\nFailing to implement these controls exposes the organization to unauthorized access, data leakage, accidental or malicious exfiltration of FCI, contract penalties, and loss of future government contracts. For a small business the most likely real-world consequences are a compromised employee account being used to access sensitive proposals or client data, reputational damage, and the administrative cost of breach response — all avoidable with basic, well-documented access controls and audit trails.
\n\nKeep the checklist lean and evidence-focused: auditors want to see \"do\" and \"prove.\" Automate evidence collection where possible (scripts to export user lists, scheduled reports from Azure AD), keep a live asset/account inventory, and use role-based groups so access reviews are efficient. Retain logs for the retention period stated in your policy, and test deprovisioning by doing randomized quarterly checks that remove access for a sample of former employees. Train staff on the provisioning/deprovisioning process and make the request workflow part of onboarding/offboarding checklists to reduce human error.
\n\nSummary: Build your AC.L1-B.1.I checklist by documenting simple, targeted policies; implementing cost-effective technical controls (unique IDs, password/lockout settings, MFA for remote/admin access, and logging); and collecting clear audit evidence (policy docs, account exports, configuration files, ticket trails, and logs). For a small business, focus on repeatability and automation so you can demonstrate compliance with FAR 52.204-21 / CMMC 2.0 Level 1 quickly and maintain it with low operational overhead.
", "plain_text": "This post gives a practical, implementation-focused checklist for AC.L1-B.1.I — an Access Control practice within the Compliance Framework commonly used to satisfy FAR 52.204-21 / CMMC 2.0 Level 1 basic safeguarding requirements — showing the policies you need, the technical controls to implement, and the audit evidence to collect for a small business to demonstrate compliance.\n\nWhat AC.L1-B.1.I is and how it maps to your obligations\nAt a high level AC.L1-B.1.I is an access-control practice: ensure only authorized users have access to covered systems and data, and that access is controlled and auditable. For organizations subject to FAR 52.204-21 and CMMC 2.0 Level 1, this practice typically maps to basic controls like unique user IDs, access limitation, and simple session/account management; the goal is to provide demonstrable, repeatable controls that protect Federal Contract Information (FCI) or other sensitive business information.\n\nPolicies and procedural checklist items\nStart by documenting policy and procedure items that are concise, actionable, and tailored to the Compliance Framework scope. Minimum checklist items: an Access Control Policy (scope, roles, responsibilities), Account Management Procedure (provisioning/deprovisioning workflow and owner), Password/Authentication Standard (complexity, rotation, reuse), Remote Access Policy (VPN/remote desktop controls), and an Audit & Logging Retention Policy (what logs are retained and for how long). For each policy include: effective date, approver, review cadence (annually or on major change), and mapping to the practice AC.L1-B.1.I.\n\nExample policy entries\nExample small-business policy entry: \"All user accounts must be uniquely identifiable; shared accounts are allowed only for service accounts and must be documented, approved by IT and reviewed quarterly.\" Include a short checklist item in procurement/HR handbooks so new hires are provisioned with the correct level of access and departing employees are deprovisioned within 24 hours.\n\nTechnical controls and specific configurations\nTranslate policies into technical controls you can implement with minimal cost. Key technical controls: unique user accounts, account disablement after inactivity, session timeout, principle of least privilege (role-based groups), and basic logging of authentication and access events. Concrete examples: On Windows use Group Policy to set password complexity (Minimum password length 12), account lockout threshold (5 invalid attempts), and maximum password age (90 days). Command-line examples: Windows – \"net accounts /minpwlen:12 /lockoutthreshold:5 /lockoutwindow:30\". On Linux, enforce pwquality via /etc/pam.d/common-password and set chage -M 90 for maximum password age; use faillock or pam_faillock.so to lock after failed attempts. In cloud (Azure AD/Okta), create a Conditional Access policy enforcing MFA for administrative roles and for any remote access to corporate resources, and enable Sign-in logs retention for 90 days.\n\nService accounts, privileged accounts, and network controls\nDocument and technically enforce how service accounts are handled: mark them as non-interactive, store credentials in a password vault (e.g., HashiCorp Vault, Azure Key Vault, 1Password Business), and rotate credentials on a schedule. For network-level access, implement simple firewall rules and VLAN segmentation so contractor laptops cannot directly access management networks. Example firewall ACL snippet (Cisco IOS): \"access-list 101 permit tcp any host 10.10.10.5 eq 3389\" to restrict RDP to a single jump box, then log hits with \"ip access-list extended 101\" and \"log\".\n\nAudit evidence: what to collect and how to present it\nAuditors want clear, objective evidence that controls exist and work. Collect policy documents with signatures and review dates, account inventory exports (CSV of active accounts, creation date, last login), group membership snapshots showing least-privilege assignments, screenshots or export of group policy objects, system configuration files (/etc/login.defs, pam configs), and logs showing account disablement or access events. Include a sample deprovisioning ticket trail from your helpdesk (ticket ID, time stamp, account disabled) and a record of quarterly access reviews signed by the reviewer. Keep evidence organized in a folder structure (Policies/, Configs/, Logs/, Tickets/) and retain evidence per your Audit & Logging Retention Policy (commonly 1–3 years for Level 1 evidence unless contract requires otherwise).\n\nSmall business use case — practical implementation plan\nScenario: a 20-person engineering consultant with a single on-prem server, cloud file storage (Microsoft 365), and remote workers. Practical steps: (1) scope systems that process or store FCI, (2) create a simple Access Control Policy and an account provisioning checklist, (3) enable unique accounts in Azure AD and set self-service password reset, (4) enforce SSO+MFA for remote access and cloud apps, (5) implement GPO/password and lockout settings on Windows endpoints, (6) configure logging (Windows Event Forwarding to a lightweight SIEM or central log store), and (7) schedule quarterly access reviews and backlog deprovisioning tickets. Example timeline: policy + inventory (week 1), apply technical configs and MFA (week 2–3), collect baseline evidence and run simulated access-review (week 4).\n\nRisks of not implementing AC.L1-B.1.I\nFailing to implement these controls exposes the organization to unauthorized access, data leakage, accidental or malicious exfiltration of FCI, contract penalties, and loss of future government contracts. For a small business the most likely real-world consequences are a compromised employee account being used to access sensitive proposals or client data, reputational damage, and the administrative cost of breach response — all avoidable with basic, well-documented access controls and audit trails.\n\nCompliance tips and best practices\nKeep the checklist lean and evidence-focused: auditors want to see \"do\" and \"prove.\" Automate evidence collection where possible (scripts to export user lists, scheduled reports from Azure AD), keep a live asset/account inventory, and use role-based groups so access reviews are efficient. Retain logs for the retention period stated in your policy, and test deprovisioning by doing randomized quarterly checks that remove access for a sample of former employees. Train staff on the provisioning/deprovisioning process and make the request workflow part of onboarding/offboarding checklists to reduce human error.\n\nSummary: Build your AC.L1-B.1.I checklist by documenting simple, targeted policies; implementing cost-effective technical controls (unique IDs, password/lockout settings, MFA for remote/admin access, and logging); and collecting clear audit evidence (policy docs, account exports, configuration files, ticket trails, and logs). For a small business, focus on repeatability and automation so you can demonstrate compliance with FAR 52.204-21 / CMMC 2.0 Level 1 quickly and maintain it with low operational overhead." }, "metadata": { "description": "Step-by-step guide to build an AC.L1-B.1.I compliance checklist aligned to FAR 52.204-21/CMMC 2.0 Level 1 with policies, technical controls, and concrete audit evidence examples.", "permalink": "/how-to-build-an-acl1-b1i-compliance-checklist-for-far-52204-21-cmmc-20-level-1-policies-technical-controls-and-audit-evidence.json", "categories": [], "tags": [] } }