This post shows how to assemble a practical, audit-ready evidence package for FAR 52.204‑21 and CMMC 2.0 Level 1 Control AC.L1‑B.1.I (access control-related requirement), including templates, sample artifacts, and concrete implementation proofs suitable for small businesses using typical cloud and endpoint stacks.
\n\nYour evidence package should be a curated collection of documents and technical artifacts that demonstrate you implemented the access control practices required by FAR 52.204‑21 and CMMC Level 1. At a minimum include: an evidence index (CSV or spreadsheet), access control policy (or section of your security policy), account management procedure, screenshots or exports of user accounts and group membership, recent access review records, configuration snapshots (GPOs, IAM policies, firewall rules), audit logs showing authentication/access events, training records for users, and a short implementation narrative tying each artifact to the control requirement.
\n\nCreate a simple index spreadsheet with these columns: Evidence_ID, Artifact_Name, Artifact_Type (policy, log, screenshot), System/Location, Date_Captured, Responsible_Person, Hash/Checksum, Brief_Explanation (how it maps to AC.L1‑B.1.I). Example row: EVID‑001, \"Access_Control_Policy_v1.pdf\", Policy, /repo/policies, 2026‑03‑15, SecurityOfficer@company.com, SHA256:abcd..., \"Defines account creation, revocation, and least privilege mapping to AC.L1‑B.1.I\". This index is the first artifact an assessor will open; make it precise and machine-readable.
\n\nCollect artifacts using reproducible technical commands and timestamped exports so you can show provenance. Examples: export Active Directory users and groups with PowerShell: Get‑ADUser -Filter * -Properties Enabled,LastLogonDate | Select Name,SamAccountName,Enabled,LastLogonDate | Export‑CSV UsersExport_2026‑03‑20.csv. For Microsoft 365/Azure AD: use AzureAD or Microsoft Graph to export users and role assignments (or screenshot the Azure portal showing an application of Conditional Access). For AWS customers: aws iam list‑users and aws iam list‑roles with CloudTrail event lookups (aws cloudtrail lookup‑events --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin --start-time 2026‑03‑01 --end-time 2026‑03‑20). Save server or endpoint configuration: gpresult /h GPOReport_2026‑03‑20.html or net localgroup administrators > LocalAdmins_2026‑03‑20.txt. Always record capture date/time and the account that produced the export.
\n\nScreenshots are fine if accompanied by metadata: file name with timestamp and a short signed narrative (.pdf) from the admin explaining what the screenshot shows and why it demonstrates compliance. For logs, include a short extraction showing the relevant event — e.g., a login attempt, account disablement, or MFA enrollment — with event ID, timestamp (UTC), and user PrincipalName. Where possible, include a cryptographic hash (SHA256) of each exported file and store both the file and its hash in your evidence repo to prove files were not modified after capture.
\n\nExample A — Small engineering firm using Microsoft 365 Business Premium: Evidence package includes the company's \"Access Control Policy\" PDF, Azure AD users export (UsersExport_2026‑03‑20.csv), Conditional Access policy screenshot requiring MFA for external access (CA_MFA_2026‑03‑20.png), Intune enrollment policy screenshot showing device compliance rules, an access review spreadsheet showing quarterly review with reviewer initials, and training sign-in sheet for \"Acceptable Use and Access Controls\" (Training_2026‑01‑15.pdf). Example B — Boutique software house using AWS and laptops: include IAM user/role export, CloudTrail excerpt showing an IAM user creation and access event, disk encryption confirmation for laptops (BitLocker status output), and a helpdesk ticket trail showing account provisioning and deprovisioning actions tied to employee onboarding/offboarding entries.
\n\nOrganize artifacts in a versioned, permissioned evidence repository (e.g., private SharePoint site, secured Git repo, or encrypted S3 bucket) with directory structure: /evidence/YYYY-MM-DD/{policies,configs,logs,screenshots,narratives}. Use consistent filename patterns: {YYYYMMDD}_{SYSTEM}_{ARTIFACTTYPE}_{SHORTDESC}.{ext}. Automate capture where possible: schedule scripts to export user lists and log summaries monthly, and commit them to the evidence repo with a commit message and hash. Create a one‑page assessor narrative that maps artifact IDs to control statements (e.g., \"AC.L1‑B.1.I — Evidence: EVID‑005 UsersExport_2026‑03‑20.csv demonstrates only authorized users have access to the corporate file share; EVID‑008 AccessReview_Q1_2026.xlsx shows quarterly review and revocations.\").
\n\n1) Keep artifacts minimal but sufficient — avoid flooding the assessor with raw log data; provide short extracts with references to full logs if requested. 2) Time‑bound snapshots are powerful — a current export plus a historical sample (e.g., current and prior quarter) shows continuity. 3) Demonstrate control operation, not just policy: show that account requests go through an approval ticket (ticketing system export), that access is removed within your stated SLA upon termination (deprovisioning ticket and timestamp), and that MFA is enforced where required. 4) Retain evidence per contract terms; if the contract does not prescribe retention, retain at least 6–12 months to support reviews and investigations.
\n\nFailing to implement AC.L1‑B.1.I and to provide evidence increases the risk of unauthorized access to government data or CUI, resulting in data exposure, contract disqualification, monetary penalties, and reputational harm. Operationally, poor account management can lead to orphaned accounts with privileged access, lateral movement during an intrusion, and prolonged recovery time after incidents. From an acquisition perspective, inability to produce evidence can remove you from competition for future contracts and trigger remediation demands or suspension.
\n\nIn summary, build a concise, well-indexed evidence package that combines policy, procedures, technical exports, screenshots, and signed narratives mapped directly to AC.L1‑B.1.I. Use reproducible export commands, consistent naming and hashing, automated snapshots where possible, and a central, access‑controlled repository to store artifacts. For small businesses, prioritize demonstrating operational practice (provisioning/deprovisioning, access reviews, MFA deployment) over excessive raw data — assessors want to see that controls work in practice and are repeatably demonstrable.
", "plain_text": "This post shows how to assemble a practical, audit-ready evidence package for FAR 52.204‑21 and CMMC 2.0 Level 1 Control AC.L1‑B.1.I (access control-related requirement), including templates, sample artifacts, and concrete implementation proofs suitable for small businesses using typical cloud and endpoint stacks.\n\nWhat to include in your evidence package\nYour evidence package should be a curated collection of documents and technical artifacts that demonstrate you implemented the access control practices required by FAR 52.204‑21 and CMMC Level 1. At a minimum include: an evidence index (CSV or spreadsheet), access control policy (or section of your security policy), account management procedure, screenshots or exports of user accounts and group membership, recent access review records, configuration snapshots (GPOs, IAM policies, firewall rules), audit logs showing authentication/access events, training records for users, and a short implementation narrative tying each artifact to the control requirement.\n\nEvidence Index (template)\nCreate a simple index spreadsheet with these columns: Evidence_ID, Artifact_Name, Artifact_Type (policy, log, screenshot), System/Location, Date_Captured, Responsible_Person, Hash/Checksum, Brief_Explanation (how it maps to AC.L1‑B.1.I). Example row: EVID‑001, \"Access_Control_Policy_v1.pdf\", Policy, /repo/policies, 2026‑03‑15, SecurityOfficer@company.com, SHA256:abcd..., \"Defines account creation, revocation, and least privilege mapping to AC.L1‑B.1.I\". This index is the first artifact an assessor will open; make it precise and machine-readable.\n\nPractical, technical collection methods (real artifacts)\nCollect artifacts using reproducible technical commands and timestamped exports so you can show provenance. Examples: export Active Directory users and groups with PowerShell: Get‑ADUser -Filter * -Properties Enabled,LastLogonDate | Select Name,SamAccountName,Enabled,LastLogonDate | Export‑CSV UsersExport_2026‑03‑20.csv. For Microsoft 365/Azure AD: use AzureAD or Microsoft Graph to export users and role assignments (or screenshot the Azure portal showing an application of Conditional Access). For AWS customers: aws iam list‑users and aws iam list‑roles with CloudTrail event lookups (aws cloudtrail lookup‑events --lookup-attributes AttributeKey=EventName,AttributeValue=ConsoleLogin --start-time 2026‑03‑01 --end-time 2026‑03‑20). Save server or endpoint configuration: gpresult /h GPOReport_2026‑03‑20.html or net localgroup administrators > LocalAdmins_2026‑03‑20.txt. Always record capture date/time and the account that produced the export.\n\nScreenshots, logs, and signed narratives\nScreenshots are fine if accompanied by metadata: file name with timestamp and a short signed narrative (.pdf) from the admin explaining what the screenshot shows and why it demonstrates compliance. For logs, include a short extraction showing the relevant event — e.g., a login attempt, account disablement, or MFA enrollment — with event ID, timestamp (UTC), and user PrincipalName. Where possible, include a cryptographic hash (SHA256) of each exported file and store both the file and its hash in your evidence repo to prove files were not modified after capture.\n\nSmall business scenarios and examples\nExample A — Small engineering firm using Microsoft 365 Business Premium: Evidence package includes the company's \"Access Control Policy\" PDF, Azure AD users export (UsersExport_2026‑03‑20.csv), Conditional Access policy screenshot requiring MFA for external access (CA_MFA_2026‑03‑20.png), Intune enrollment policy screenshot showing device compliance rules, an access review spreadsheet showing quarterly review with reviewer initials, and training sign-in sheet for \"Acceptable Use and Access Controls\" (Training_2026‑01‑15.pdf). Example B — Boutique software house using AWS and laptops: include IAM user/role export, CloudTrail excerpt showing an IAM user creation and access event, disk encryption confirmation for laptops (BitLocker status output), and a helpdesk ticket trail showing account provisioning and deprovisioning actions tied to employee onboarding/offboarding entries.\n\nImplementation tips and best practices\nOrganize artifacts in a versioned, permissioned evidence repository (e.g., private SharePoint site, secured Git repo, or encrypted S3 bucket) with directory structure: /evidence/YYYY-MM-DD/{policies,configs,logs,screenshots,narratives}. Use consistent filename patterns: {YYYYMMDD}_{SYSTEM}_{ARTIFACTTYPE}_{SHORTDESC}.{ext}. Automate capture where possible: schedule scripts to export user lists and log summaries monthly, and commit them to the evidence repo with a commit message and hash. Create a one‑page assessor narrative that maps artifact IDs to control statements (e.g., \"AC.L1‑B.1.I — Evidence: EVID‑005 UsersExport_2026‑03‑20.csv demonstrates only authorized users have access to the corporate file share; EVID‑008 AccessReview_Q1_2026.xlsx shows quarterly review and revocations.\").\n\nCompliance tips\n1) Keep artifacts minimal but sufficient — avoid flooding the assessor with raw log data; provide short extracts with references to full logs if requested. 2) Time‑bound snapshots are powerful — a current export plus a historical sample (e.g., current and prior quarter) shows continuity. 3) Demonstrate control operation, not just policy: show that account requests go through an approval ticket (ticketing system export), that access is removed within your stated SLA upon termination (deprovisioning ticket and timestamp), and that MFA is enforced where required. 4) Retain evidence per contract terms; if the contract does not prescribe retention, retain at least 6–12 months to support reviews and investigations.\n\nRisks of not implementing and documenting the control\nFailing to implement AC.L1‑B.1.I and to provide evidence increases the risk of unauthorized access to government data or CUI, resulting in data exposure, contract disqualification, monetary penalties, and reputational harm. Operationally, poor account management can lead to orphaned accounts with privileged access, lateral movement during an intrusion, and prolonged recovery time after incidents. From an acquisition perspective, inability to produce evidence can remove you from competition for future contracts and trigger remediation demands or suspension.\n\nIn summary, build a concise, well-indexed evidence package that combines policy, procedures, technical exports, screenshots, and signed narratives mapped directly to AC.L1‑B.1.I. Use reproducible export commands, consistent naming and hashing, automated snapshots where possible, and a central, access‑controlled repository to store artifacts. For small businesses, prioritize demonstrating operational practice (provisioning/deprovisioning, access reviews, MFA deployment) over excessive raw data — assessors want to see that controls work in practice and are repeatably demonstrable." }, "metadata": { "description": "Step‑by‑step guidance and ready‑to‑use templates for assembling an evidence package that proves compliance with FAR 52.204‑21 / CMMC 2.0 Level 1 AC.L1‑B.1.I access control requirements.", "permalink": "/how-to-prepare-a-compliance-evidence-package-for-far-52204-21-cmmc-20-level-1-control-acl1-b1i-templates-samples-and-implementation-proofs.json", "categories": [], "tags": [] } }