This post gives a practical, audit-ready method to create an access control checklist mapped to NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control AC.L2-3.1.1 — limiting system access to authorized users, processes, or devices — with templates, real-world examples for small businesses, and the exact artifacts auditors expect.
Understanding AC.L2-3.1.1 and the Compliance Framework Objective
AC.L2-3.1.1 requires organizations to ensure only authorized identities, services, and devices can access systems that process or store Controlled Unclassified Information (CUI). Within the Compliance Framework context, the objective is to demonstrate policy + technical enforcement + recurring verification, so an auditor sees both preventive controls (MFA, RBAC, ACLs) and detective/administrative controls (access review logs, approval tickets, and change records).
Step-by-step: Build an Audit-Ready Access Control Checklist
Follow these steps to build the checklist: 1) map the control to your assets and data flows (identify where CUI lives and who touches it), 2) define access categories (privileged admins, standard users, service accounts, third-party vendors, devices), 3) document who owns each access domain, 4) define enforcement mechanisms (AD groups, IAM policies, conditional access), 5) specify verification frequency and evidence types, and 6) create remediation and exception tracking procedures. Each checklist row should map directly to an evidence artifact and an owner responsible for producing it.
Checklist Template (fields to include)
Use the following template fields for each checklist item — you can track this in a spreadsheet, ticketing system, or GRC tool:
- Control ID: AC.L2-3.1.1
- Asset/System: e.g., Office365 tenant / Azure AD / On-prem file server
- Access Category: e.g., Admin, Standard User, Service Account
- Requirement Statement: e.g., "Only authorized users may access CUI repositories"
- Enforcement Mechanism: e.g., Azure AD Conditional Access + MFA, AD group membership
- Owner: Name/email of responsible person
- Evidence Type: e.g., access list CSV export, approval ticket, screenshot of IAM policy
- Evidence Location: URL or file path
- Review Frequency: e.g., quarterly for standard users, monthly for privileged accounts
- Status/Notes: e.g., Compliant / Remediation ticket #
Practical Implementation Details (specific to Compliance Framework)
Technical steps to enforce AC.L2-3.1.1 in a Compliance Framework environment include: implement RBAC via your directory service (Azure AD / AD DS / Okta), enable MFA for all interactive logins (exclude only where documented exceptions exist), configure privileged access management (PIM or Vault) for administrative roles, create service account naming conventions and expiration policies, and apply device compliance checks (enforce managed device enrollment before granting access). Configure logging (Azure AD sign-in logs, Windows Security event logs, cloud service audit logs) with timestamps and export capability to a SIEM for retention and quick retrieval.
Small Business Scenario: Practical Example
Example: a 25-person engineering firm handling DoD subcontract CUI uses Microsoft 365 and Azure AD. They map CUI to a SharePoint site and limit access to a single AD security group (CUI-Access). Implementation steps: create the CUI-Access group, require manager approval via ticketing (e.g., ServiceNow) for membership changes, enable Conditional Access policy requiring MFA and compliant devices, schedule quarterly exports of group membership with CSV and timestamp, and keep approval tickets attached. For privileged admin roles, use Azure PIM for just-in-time (JIT) elevation and retain elevation approval logs for 12 months.
Evidence and Audit Artifacts — What to Collect
Auditors want traceable artifacts showing both enforcement and verification. Collect: policy documents (access control policy signed by CISO/owner), access request and approval tickets with timestamps, exported group membership CSVs with export timestamps, screenshots of IAM policies/conditional access rules, privileged access elevation records, recent access review reports, system logs showing login/authentication events, and remediation tickets for revoked access. Keep a central evidence index (spreadsheet or GRC record) that references each checklist item with a persistent link or file path.
Compliance Tips, Best Practices, and Frequency
Best practices: adopt least privilege and role-based access, enforce MFA and device compliance, automate evidence collection where possible (scheduled exports, SIEM retention), and use short-lived credentials for service accounts. Review privileged accounts monthly and all other accounts at least quarterly. Maintain exception records with rationale, compensating controls, and expiration dates. For small businesses without expensive PAM tools, use SSO + conditional access + ticketed temporary group membership to simulate JIT access.
Risk of Not Implementing AC.L2-3.1.1
Failing to implement this requirement increases the risk of unauthorized access to CUI, data exfiltration, account compromise, and regulatory penalties or lost contracts. For example, unmanaged service accounts can be leveraged by attackers for lateral movement; stale AD group membership can give ex-employees ongoing access. Noncompliance also leads auditors to raise findings that require formal remediation plans and can delay or block CMMC certification or contract awards.
Summary: build your checklist by mapping systems to CUI, categorizing access types, defining owners and enforcement mechanisms, and specifying evidence and review cadence; automate exports and logging where possible, use ticketed approvals for temporary access, and collect the artifacts auditors expect (policy, tickets, CSV exports, screenshots, log entries). With these steps and templates, a small business can create an audit-ready access control program that demonstrably meets AC.L2-3.1.1 under the Compliance Framework.
