{
  "title": "How to Build an Audit-Ready Inventory for FAR 52.204-21 / CMMC 2.0 Level 1 - Control - IA.L1-B.1.V: Practical Steps to Identify Information System Users, Processes, and Devices",
  "date": "2026-04-10",
  "author": "Lakeridge Technologies",
  "featured_image": "/assets/images/blog/2026/4/how-to-build-an-audit-ready-inventory-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v-practical-steps-to-identify-information-system-users-processes-and-devices.jpg",
  "content": {
    "full_html": "<p>FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V require contractors to be able to identify information system users, processes acting on behalf of users, and devices — and to present auditable evidence that those entities are known, managed, and controlled; this post gives practical, step-by-step guidance for small businesses to build an audit-ready inventory that meets those requirements within a Compliance Framework context.</p>\n\n<h2>Why identification matters and what auditors look for</h2>\n<p>Auditors are looking for a single system-of-record (or clearly reconciled sources) that shows who has access, which processes run with user context, and which devices connect to systems that touch Controlled Unclassified Information (CUI) or government data. For Compliance Framework assessments, the objective is demonstrable traceability: you must show the inventory, show how it is maintained, and provide time-stamped evidence (exports, logs, screenshots, tickets) linking inventory records to actual accounts and endpoints. Failure to do so can result in adverse findings, loss of contracts, or standing vulnerabilities such as orphaned accounts and unmanaged devices.</p>\n\n<h2>Step 1 — Define scope and system boundaries</h2>\n<p>Start by scoping what counts as \"information system\" under your contract: cloud services (SaaS, IaaS), corporate endpoints (laptops, phones), servers, and network gear that process or store CUI. For small businesses, a practical approach is to list the top 10 systems (e.g., Office 365 tenant, Azure subscription, AWS account, corporate AD, Intune, file servers, key SaaS apps) and map which handle CUI. Create a boundary diagram (simple box-and-arrow) and record it in your Compliance Framework artifacts. The scope determines which users and devices must be inventoried and how processes are attributed to user identities (e.g., service accounts vs. interactive users).</p>\n\n<h2>Step 2 — Design an inventory data model and system of record</h2>\n<h3>Recommended inventory attributes</h3>\n<p>Your inventory must include at minimum: asset ID, hostname, device type, MAC address, IP (last seen), OS and version, owner (person, role), user account(s) mapped to the device, purpose/processes running (e.g., \"backup agent\", \"svc-mailsync\"), management tool (Intune/SCCM/JAMF), CUI handling flag, location, serial/model, last scanned timestamp, and evidentiary pointer (export filename, ticket ID). For users include: user ID, full name, email, role, manager, groups, authentication method (SSO/MFA), account status, and source (AD/AzureAD/Okta).</p>\n<p>Store this model in a system-of-record: a simple CSV with consistent column headers or, for more mature shops, a CMDB or asset management tool. The Compliance Framework assessment values consistent naming conventions and a unique identifier for each record so auditors can trace exports back to system logs and tickets.</p>\n\n<h2>Step 3 — Discovery approaches and practical tooling</h2>\n<p>Use a layered discovery approach: authoritative sources first (IdP, AD, cloud IAM APIs), then passive and active discovery for devices. For users: export from your IdP (Okta, Azure AD, Google Workspace) or use PowerShell (Get-AzureADUser or Get-MgUser) and include group membership. For devices: use Intune/JAMF/SCCM inventories, EDR/antivirus management consoles (CrowdStrike, Defender ATP), and network scans. Useful commands and APIs for small teams: PowerShell Get-CimInstance Win32_ComputerSystem on Windows endpoints, lshw or hostnamectl and dmidecode on Linux; aws iam list-users and aws ec2 describe-instances for AWS; and nmap --script broadcast-arp-discovery or arp-scan for local network discovery. Open-source tools like Open-AudIT, OCS Inventory, or GLPI provide low-cost discovery and reporting for small businesses.</p>\n\n<h2>Step 4 — Map processes and service accounts to user context</h2>\n<p>Auditors want to see which processes act with user privilege (interactive sessions) versus service accounts. Collect process lists from EDR or endpoint management (pslist/wmic tasklist on Windows, ps aux on Linux) and tag processes that access CUI. Maintain a register of service accounts with purpose, owner, and credential handling method. In practice, for a small consultancy with a backup server, include evidence such as a scheduled task entry screenshot, the backup service account in AD, and a ticket documenting the account creation and approval. This demonstrates linkage among process, account, and device.</p>\n\n<h2>Operational practices: maintenance, verification, and evidence for audits</h2>\n<p>Operationalize the inventory: schedule automated exports (weekly/monthly) and a manual reconciliation quarterly. Keep an evidence bundle per audit window: dated CSV export from the IdP, endpoint inventory export, a reconciliation checklist signed by the IT manager, and change control tickets for onboarding/offboarding. Use versioned filenames with timestamps (e.g., ad-users-2026-04-01.csv) and store them in immutable/controlled storage (WORM or access-controlled archive). Best practices include assigning asset owners, enforcing standard naming conventions, and using automated alerts for \"last seen\" > 30 days to identify stale devices or dormant accounts.</p>\n\n<h2>Compliance tips, small-business scenarios, and low-cost implementation</h2>\n<p>For a small business of 20–50 employees: you can meet IA.L1-B.1.V using low-cost or built-in tools — Azure AD exports, Microsoft Intune device inventory, and a simple CMDB (Google Sheet/CSV) as the system-of-record. Example scenario: a 25-person engineering firm uses Azure AD + Intune; they automate a weekly export of users (Get-AzureADUser -All $true | Export-Csv) and Intune device inventory via Graph API, reconcile in a Google Sheet, and keep screenshots of the Graph export and a JIRA ticket showing the quarterly reconciliation. Compliance tips: (1) automate exports with scheduled scripts and store outputs with checksums, (2) document the reconciliation process and who signed off, (3) keep at least the contractually specified retention and snapshots for the previous assessment period, and (4) centralize evidence in a secure audit folder with access controls.</p>\n\n<h2>Risks of not implementing a proper inventory</h2>\n<p>Without an auditable inventory you face both compliance and security risks: failed assessments or corrective actions under FAR 52.204-21/CMMC, lost or delayed contracts, and increased exposure to data leaks from unmanaged devices or orphaned accounts. Operationally, lack of device visibility slows incident response; lack of user/process attribution makes privilege misuse harder to detect. Auditors often flag incomplete inventories as a control gap because it directly undermines other controls like access management and configuration management.</p>\n\n<p>Summary: Build a scoped, consistent inventory data model; pull authoritative user data from IdPs and authoritative device data from endpoint/cloud management; map processes and service accounts to owners; automate exports, reconcile regularly, and bundle time-stamped evidence (exports, screenshots, tickets) into an auditable package. For small businesses, practical choices like Intune/AzureAD exports, lightweight CMDBs, and scheduled scripts deliver compliance with FAR 52.204-21 and CMMC 2.0 IA.L1-B.1.V without large investments — as long as you maintain discipline around ownership, reconciliation, and evidence retention.</p>",
    "plain_text": "FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V require contractors to be able to identify information system users, processes acting on behalf of users, and devices — and to present auditable evidence that those entities are known, managed, and controlled; this post gives practical, step-by-step guidance for small businesses to build an audit-ready inventory that meets those requirements within a Compliance Framework context.\n\nWhy identification matters and what auditors look for\nAuditors are looking for a single system-of-record (or clearly reconciled sources) that shows who has access, which processes run with user context, and which devices connect to systems that touch Controlled Unclassified Information (CUI) or government data. For Compliance Framework assessments, the objective is demonstrable traceability: you must show the inventory, show how it is maintained, and provide time-stamped evidence (exports, logs, screenshots, tickets) linking inventory records to actual accounts and endpoints. Failure to do so can result in adverse findings, loss of contracts, or standing vulnerabilities such as orphaned accounts and unmanaged devices.\n\nStep 1 — Define scope and system boundaries\nStart by scoping what counts as \"information system\" under your contract: cloud services (SaaS, IaaS), corporate endpoints (laptops, phones), servers, and network gear that process or store CUI. For small businesses, a practical approach is to list the top 10 systems (e.g., Office 365 tenant, Azure subscription, AWS account, corporate AD, Intune, file servers, key SaaS apps) and map which handle CUI. Create a boundary diagram (simple box-and-arrow) and record it in your Compliance Framework artifacts. The scope determines which users and devices must be inventoried and how processes are attributed to user identities (e.g., service accounts vs. interactive users).\n\nStep 2 — Design an inventory data model and system of record\nRecommended inventory attributes\nYour inventory must include at minimum: asset ID, hostname, device type, MAC address, IP (last seen), OS and version, owner (person, role), user account(s) mapped to the device, purpose/processes running (e.g., \"backup agent\", \"svc-mailsync\"), management tool (Intune/SCCM/JAMF), CUI handling flag, location, serial/model, last scanned timestamp, and evidentiary pointer (export filename, ticket ID). For users include: user ID, full name, email, role, manager, groups, authentication method (SSO/MFA), account status, and source (AD/AzureAD/Okta).\nStore this model in a system-of-record: a simple CSV with consistent column headers or, for more mature shops, a CMDB or asset management tool. The Compliance Framework assessment values consistent naming conventions and a unique identifier for each record so auditors can trace exports back to system logs and tickets.\n\nStep 3 — Discovery approaches and practical tooling\nUse a layered discovery approach: authoritative sources first (IdP, AD, cloud IAM APIs), then passive and active discovery for devices. For users: export from your IdP (Okta, Azure AD, Google Workspace) or use PowerShell (Get-AzureADUser or Get-MgUser) and include group membership. For devices: use Intune/JAMF/SCCM inventories, EDR/antivirus management consoles (CrowdStrike, Defender ATP), and network scans. Useful commands and APIs for small teams: PowerShell Get-CimInstance Win32_ComputerSystem on Windows endpoints, lshw or hostnamectl and dmidecode on Linux; aws iam list-users and aws ec2 describe-instances for AWS; and nmap --script broadcast-arp-discovery or arp-scan for local network discovery. Open-source tools like Open-AudIT, OCS Inventory, or GLPI provide low-cost discovery and reporting for small businesses.\n\nStep 4 — Map processes and service accounts to user context\nAuditors want to see which processes act with user privilege (interactive sessions) versus service accounts. Collect process lists from EDR or endpoint management (pslist/wmic tasklist on Windows, ps aux on Linux) and tag processes that access CUI. Maintain a register of service accounts with purpose, owner, and credential handling method. In practice, for a small consultancy with a backup server, include evidence such as a scheduled task entry screenshot, the backup service account in AD, and a ticket documenting the account creation and approval. This demonstrates linkage among process, account, and device.\n\nOperational practices: maintenance, verification, and evidence for audits\nOperationalize the inventory: schedule automated exports (weekly/monthly) and a manual reconciliation quarterly. Keep an evidence bundle per audit window: dated CSV export from the IdP, endpoint inventory export, a reconciliation checklist signed by the IT manager, and change control tickets for onboarding/offboarding. Use versioned filenames with timestamps (e.g., ad-users-2026-04-01.csv) and store them in immutable/controlled storage (WORM or access-controlled archive). Best practices include assigning asset owners, enforcing standard naming conventions, and using automated alerts for \"last seen\" > 30 days to identify stale devices or dormant accounts.\n\nCompliance tips, small-business scenarios, and low-cost implementation\nFor a small business of 20–50 employees: you can meet IA.L1-B.1.V using low-cost or built-in tools — Azure AD exports, Microsoft Intune device inventory, and a simple CMDB (Google Sheet/CSV) as the system-of-record. Example scenario: a 25-person engineering firm uses Azure AD + Intune; they automate a weekly export of users (Get-AzureADUser -All $true | Export-Csv) and Intune device inventory via Graph API, reconcile in a Google Sheet, and keep screenshots of the Graph export and a JIRA ticket showing the quarterly reconciliation. Compliance tips: (1) automate exports with scheduled scripts and store outputs with checksums, (2) document the reconciliation process and who signed off, (3) keep at least the contractually specified retention and snapshots for the previous assessment period, and (4) centralize evidence in a secure audit folder with access controls.\n\nRisks of not implementing a proper inventory\nWithout an auditable inventory you face both compliance and security risks: failed assessments or corrective actions under FAR 52.204-21/CMMC, lost or delayed contracts, and increased exposure to data leaks from unmanaged devices or orphaned accounts. Operationally, lack of device visibility slows incident response; lack of user/process attribution makes privilege misuse harder to detect. Auditors often flag incomplete inventories as a control gap because it directly undermines other controls like access management and configuration management.\n\nSummary: Build a scoped, consistent inventory data model; pull authoritative user data from IdPs and authoritative device data from endpoint/cloud management; map processes and service accounts to owners; automate exports, reconcile regularly, and bundle time-stamped evidence (exports, screenshots, tickets) into an auditable package. For small businesses, practical choices like Intune/AzureAD exports, lightweight CMDBs, and scheduled scripts deliver compliance with FAR 52.204-21 and CMMC 2.0 IA.L1-B.1.V without large investments — as long as you maintain discipline around ownership, reconciliation, and evidence retention."
  },
  "metadata": {
    "description": "Step-by-step guidance for small businesses to create an audit-ready inventory that satisfies FAR 52.204-21 and CMMC 2.0 Level 1 IA.L1-B.1.V by identifying users, processes, and devices with verifiable evidence.",
    "permalink": "/how-to-build-an-audit-ready-inventory-for-far-52204-21-cmmc-20-level-1-control-ial1-b1v-practical-steps-to-identify-information-system-users-processes-and-devices.json",
    "categories": [],
    "tags": []
  }
}