This post explains how to build an audit-ready inventory that satisfies FAR 52.204-21 and CMMC 2.0 Level 1 control IA.L1-B.1.V by identifying and documenting users, processes acting for users (service accounts, scheduled tasks, application identities), and devices—giving small businesses practical discovery steps, technical commands, evidence templates, and operational practices to stay compliant and audit-ready.
Why an audit-ready inventory matters (and the risk of not doing it)
At Level 1, IA.L1-B.1.V requires you to know who can access Controlled Unclassified Information (CUI) or government-covered data, what automated processes act with user authority, and which devices access that information. Without a reliable inventory you face increased risk of unauthorized access, undetected lateral movement, failed contract audits, corrective action plans, or loss of government work. For small businesses, the financial and reputational hit from a failed audit or breach can be existential—so your inventory is both a security control and a contracting asset.
Step 1 — Define scope and a data model for your inventory
Begin by scoping what "in-scope" means for your contract or project: systems that store, process, or transmit covered information, and the user population (employees, contractors, privileged admins, service accounts). Define the canonical data model fields you'll capture for every record: unique ID, type (user / service-account / device), owner/business custodian, contact, affiliation (employee/contractor), source system (AD, Azure AD, G Suite, AWS, Jamf), OS, hostname, IP/MAC, asset tag/serial, enrollment (MDM/EDR), last-seen timestamp, account creation date, last login, and evidence pointer (export filename, SIEM query ID, API snapshot). Keep this model in a simple CMDB or spreadsheet as a starting point, then migrate to a database or IT asset tool as scale requires.
Step 2 — Discovery methods (practical, tool-driven approaches)
Discovery should be automated where possible and redundant across sources to provide cross-validation evidence for audits. Use identity directories, endpoint management, EDR, DHCP/NAC logs, cloud IAM, and application logs to build a convergent picture. Below are practical discovery techniques grouped by environment with suggested commands and outputs to collect as evidence.
On‑prem and endpoints (Windows / Linux / macOS)
For Windows AD environments: export user and computer lists and group membership with PowerShell: Get-ADUser -Filter * -Properties whenCreated,lastLogonTimestamp,memberOf | Export-Csv users.csv. For local Windows hosts: Get-LocalUser and Get-CimInstance -ClassName Win32_ComputerSystem. For devices inventory from EDR or MDM (e.g., CrowdStrike, Defender for Endpoint, Intune), schedule API exports (device list with last-seen timestamps). On Linux/macOS, use getent passwd, last, and ps -eo user,pid,cmd to find processes with user contexts; list service accounts with cat /etc/passwd and examine cron jobs with crontab -l and /etc/cron.*. Collect DHCP server lease exports and ARP tables (arp -a) for network evidence of device presence.
Cloud and SaaS (Azure, AWS, GCP, Google Workspace)
For cloud IAM: use CLI exports as evidence. Examples: AWS: aws iam list-users > aws-users.json and aws iam list-roles > aws-roles.json to identify human vs. role/service identities; Azure: az ad user list --query '[].{displayName:displayName, id:id}' > azure-users.json and az ad sp list for service principals; GCP: gcloud iam service-accounts list. For SaaS (Google Workspace, Office365), export user lists and device management reports (e.g., Google Admin reports and Intune device lists). Also capture application-level identities (API keys, service accounts) and store them in your inventory with the evidence export name and timestamp.
Step 3 — Identify processes acting for users (service accounts, scheduled tasks, app identities)
Processes acting for users are often the blind spots auditors focus on. Common examples: database jobs using a shared SQL account, CI/CD runners with broad cloud permissions, IIS app pools running under a service account, or scheduled Windows tasks. Detect them by searching for non-interactive logins, long-lived access tokens, and service principals. Useful techniques: inspect AD for managed service accounts (Get-ADServiceAccount), query Active Directory for accounts with 'Password never expires' flags, scan crontab and systemd units for scripts running under specific users (systemctl list-units --type=service; ps -eo user,pid,cmd | grep app). In cloud, reconcile IAM roles attached to compute instances and Kubernetes service accounts (kubectl get serviceaccounts --all-namespaces) and capture role bindings. Document each service identity with its purpose, owner, scope of access, and mitigation (rotate credentials, apply least privilege, use managed identities where possible).
Step 4 — Assemble the inventory and produce audit evidence
Consolidate the discovery outputs into your canonical inventory (CMDB or CSV). For audit readiness, produce a recurring "inventory snapshot" that includes: timestamp, export filenames, queries used (PowerShell/CLI commands), counts (users, devices, service accounts), and a mapping of users -> devices -> processes. Example evidence bundle: users_2026-04-01.csv, devices_2026-04-01.json (from EDR), aws-iam-snapshot_2026-04-01.json, and a signed attestation by the IT manager confirming reconciliation. Keep SIEM queries and saved dashboards that show last logins and anomalous service-account activity; export these as PDFs or JSON for each snapshot. Ensure snapshots are tamper-evident: store them in an immutable or versioned repository (S3 with object-lock, Git with signed tags, or an archive with checksums) and retain per contract requirements.
Operationalize maintenance, reconciliation, and controls
Make the inventory a living process: integrate it into onboarding/offboarding workflows (automatically tag new users and devices), configure MDM and EDR to enforce enrollment before granting access, and schedule automated reconciliations (daily device sync, weekly user reconciliation). Establish change control and an owner for each inventory field. Small businesses should include a monthly attestation step where each application/business owner reviews and signs the inventory subset relevant to them. Also apply compensating controls: enforce MFA, remove default/shared accounts, and set alerts for new service accounts or long-lived tokens. Regularly test by simulating a contractor offboarding and verifying the inventory and access changes are reflected and evidence collected.
Compliance tips and best practices
- Start simple: a well-structured spreadsheet is better than no inventory—migrate to a CMDB as you scale.
- Automate exports and capture the exact commands/queries; auditors want repeatability and proof of method.
- Use multiple data sources for cross-validation (AD + EDR + DHCP + cloud IAM).
- Label each record with "evidence pointer" (filename, API response ID, SIEM query) and store snapshots in a versioned, access-controlled store.
- Eliminate or tightly control shared credentials; replace with managed identities and short-lived tokens.
- Document your process in a runbook so an independent reviewer or new staff member can reproduce snapshots.
In summary, meeting IA.L1-B.1.V for FAR 52.204-21 and CMMC 2.0 Level 1 is a practical combination of disciplined scoping, automated discovery across identity/cloud/endpoint systems, explicit documentation of processes that act for users, and an evidence-driven snapshot cadence. For small businesses the emphasis should be on repeatability, simplicity, and defensible evidence—automate where possible, keep a clear owner for each item, and ensure your inventory is usable for both security operations and auditors.
