AU.L2-3.3.2 requires that audit records include sufficient information to establish what events occurred, when and where they occurred, and who or what caused the events — a foundational control for user traceability under NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2. This post provides a practical, implementation-oriented checklist for small and medium organizations to configure audit trails, including concrete technical examples (Linux auditd, Windows Event Forwarding, rsyslog/syslog-ng, CloudTrail/Azure Monitor), retention and integrity controls, and operational recommendations to demonstrate compliance to assessors and to enable effective incident response.
Key objectives and implementation notes (Compliance Framework context)
The primary objective is to produce reliable, tamper-evident audit records that answer: what happened, when did it happen (with accurate timestamps), where did it occur (host, application, IP), and who or what caused it (user ID, process, service account, session ID). Implementation notes: map all systems that process Controlled Unclassified Information (CUI) into your logging scope, ensure centralized collection, protect log integrity and confidentiality, and define retention and review policies in your System Security Plan (SSP). AU.L2-3.3.2 does not prescribe vendor-specific tooling — it requires evidence that logs contain the necessary attributes and are protected and reviewed.
Implementation checklist — step-by-step
1) Scope and sources
Inventory assets that store, process, or transmit CUI and include the following log sources: OS audit logs (Linux/Windows), application logs (web apps, ERP), authentication services (Active Directory, SSO), network devices (firewalls, VPN concentrators, switches), cloud provider audit logs (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs), and database audit trails. For a small business: start with endpoints, domain controllers/IdP, perimeter firewall, key servers, and cloud consoles. Document the scope and note any systems excluded and why.
2) Log content and format — ensure "who, what, when, where, why"
Define minimum fields your logs must contain and standardize formats (ISO 8601 timestamps, UTC): timestamp, timezone, hostname, fully qualified username (avoid shared accounts), source IP, destination resource, event type (login, file access, privilege change), success/failure indicator, application/process name, event ID, session ID or correlation ID. Example Linux auditd rule to capture exec and sudo changes: auditctl -a always,exit -F arch=b64 -S execve -k execve && auditctl -w /etc/sudoers -p wa -k sudoers_change. For Windows, enable Advanced Audit Policy: Audit Logon Events, Audit Account Management, Audit Process Creation and forward Security and System channels via Windows Event Forwarding (WEF) to a collector.
3) Centralization, integrity, retention and time sync
Centralize logs to a hardened collection point or SIEM (open-source: Wazuh/ELK/Graylog; managed: Splunk Cloud, Azure Sentinel). Use secure transport (TLS) and authentication for syslog (rsyslog example: *.* @@siem.example.com:6514; with TLS and certs). Protect integrity: enable log-file validation (CloudTrail), use append-only storage, or write-once-read-many (WORM) buckets with server-side encryption (SSE-KMS). Set NTP on all hosts and enforce authenticated time sources; inaccurate clocks break traceability. Define retention: a practical default is 90 days of hot storage for monitoring, 1 year archived for investigations, and longer if contractually required — each retention decision must be in policy and justified in the SSP.
4) Monitoring, alerting, and review processes
Implement automated alerts for high-priority events (privilege escalation, repeated failed logins, exfiltration indicators) and daily/weekly log reviews for exceptions. Use correlation rules in your SIEM to link authentication events with subsequent file accesses or configuration changes. Define review frequency and assign responsibility (e.g., IT lead or managed provider). For small teams, start with a shortlist of critical alerts tuned to avoid noise (e.g., multiple failed MFA attempts, new admin account creation, changes to CUI repositories) and escalate to incident response playbooks.
Real-world example: a 25-employee engineering firm
Scenario: the firm has Azure AD SSO, three Windows servers on-prem, three Linux build servers, a perimeter firewall, and an AWS account used for backups. Practical steps: enable Azure Diagnostics to send sign-in and audit logs to a Log Analytics workspace with retention policy set and enable Diagnostic Settings to forward to a secure storage account (SSE-KMS) and to Sentinel. On Windows, configure Group Policy to enable Advanced Audit Policies and set up a Windows Event Collector VM to gather logs and forward them via TLS to an ELK stack hosted in Azure. For Linux build servers, install auditd and push events through syslog-ng to the same ELK cluster. In AWS, enable an organization-wide CloudTrail with S3 bucket enforce MFA for console access to the bucket and enable CloudTrail log file validation. Document mapping of collected fields to AU.L2-3.3.2 requirements and capture screenshots/config snippets in your evidence folder for assessors.
Risks of not implementing or implementing poorly
Without adequate audit trails you cannot demonstrate user traceability: investigations are slow or inconclusive, insider threats remain undetected, and you cannot attribute activity to individuals or systems. Risks include failed CMMC assessments, loss of DoD contracts, data breaches with undetected exfiltration, and regulatory penalties. Operational risks include missed intrusions, inability to rollback malicious changes, and poor forensic quality due to unsynchronized clocks or missing fields (e.g., no source IP, anonymous service accounts used everywhere).
Compliance tips and best practices
Enforce unique, non-shared user accounts and avoid using generic service accounts except where strictly controlled and logged. Instrument custom applications to include user IDs and session/correlation IDs in logs; log at the application layer for business events (file downloads, access to CUI) that system logs won't show. Regularly test your pipeline: run tabletop incidents, validate logs contain required fields, and ensure you can reconstruct user activity end-to-end. Keep an evidence bundle: configuration files, policy excerpts, screenshots of log entries proving fields exist, retention settings, and procedures for log review. Finally, include repository hashing or log signing in the SSP to show integrity controls.
Summary
Meeting AU.L2-3.3.2 is practical for small businesses if approached methodically: inventory log sources, standardize required fields (who/what/when/where), centralize and protect logs, enforce time synchronization, set retention and review policies, and document everything in your SSP and evidence package. Start small (critical systems first), use cost-effective tooling (open-source SIEMs or cloud-native logging), and iterate — the combination of technical controls (auditd, WEF, CloudTrail) and operational processes (review, tuning, incident playbooks) will provide the traceability auditors and incident responders require.
