Building a Defensible Audit & Accountability Program (800-171 Family 3.3)
Author: Leonard Esere, Senior Security Architect
Date: April 2026
Organization: Aeolitech
Abstract
Audit logs are the forensic foundation of a defensible CUI security program. They answer the questions that matter most in an incident — who accessed what, when, from where, and whether the action was authorized. NIST SP 800-171's Audit and Accountability family (3.3) contains nine controls that collectively define what must be logged, how logs must be protected, how long they must be retained, and how they must be reviewed. These controls are among the most scrutinized in a CMMC Level 2 assessment, because they are testable in a way that few other controls are: either the logs exist, are protected, and are being reviewed — or they are not.
This whitepaper provides security engineers, compliance managers, and system owners with a complete, technically grounded guide to building an 800-171 family 3.3 compliant audit program. It specifies what events must be logged, how log aggregation in a SIEM (Microsoft Sentinel, Splunk, Elastic) should be architected, how to protect logs against tampering, and what a defensible log review cadence looks like. A sample logging architecture for Azure GCC High environments is included. The guidance draws on direct experience with ATO packages at Los Alamos National Laboratory (LANL) and DoD Secret-level systems where comprehensive audit trails were a foundational security requirement.
Table of Contents
1. The 3.3 Family — Nine Controls, One Purpose
2. What Must Be Logged — Event Categories for CUI Systems
4. Log Aggregation and SIEM Architecture
5. Log Protection — Integrity and Access Control (3.3.8 and 3.3.9)
6. Log Review Cadence — Daily Automation, Weekly Human Review
7. Sample Architecture — Azure GCC High
8. Assessor Expectations — What C3PAOs Look For
9. Common Gaps and How to Close Them
10. Conclusion
1. The 3.3 Family — Nine Controls, One Purpose
The Audit and Accountability family in NIST SP 800-171 Rev. 2 contains nine requirements organized into two basic requirements and seven derived requirements. The single purpose they collectively serve: create an irrefutable, tamper-resistant record of what happened on systems that touch CUI.
| Control | Text | Type |
|---------|------|------|
| 3.3.1 | Create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. | Basic |
| 3.3.2 | Ensure that the actions of individual system users can be uniquely traced to those users so they can be held accountable for their actions. | Basic |
| 3.3.3 | Review and update logged events. | Derived |
| 3.3.4 | Alert in the event of an audit logging process failure. | Derived |
| 3.3.5 | Correlate audit record review, analysis, and reporting processes for investigation and response to indications of unlawful, unauthorized, suspicious, or unusual activity. | Derived |
| 3.3.6 | Provide audit record reduction and report generation to support on-demand analysis and reporting. | Derived |
| 3.3.7 | Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records. | Derived |
| 3.3.8 | Protect audit information and audit logging tools from unauthorized access, modification, and deletion. | Derived |
| 3.3.9 | Limit management of audit logging functionality to a subset of privileged users. | Derived |
Reading the Controls as a System
The nine controls form an interlocking system: 3.3.1 requires the logs to exist; 3.3.2 requires them to be attributable to specific users; 3.3.3 requires that the logged event set be maintained and updated; 3.3.4 ensures the logging pipeline itself is monitored; 3.3.5 requires correlation (i.e., a SIEM that can connect related events); 3.3.6 enables query and reporting; 3.3.7 ensures timestamps are trustworthy; 3.3.8 and 3.3.9 protect the logs from the very people being logged.
A logging program that satisfies 3.3.1 (logs exist) but fails 3.3.2 (logs cannot be attributed to individual users), 3.3.5 (logs are not correlated), or 3.3.8 (logs are not protected from tampering) does not satisfy the family. Assessors will test each control individually.
2. What Must Be Logged — Event Categories for CUI Systems
NIST SP 800-171 does not prescribe an exhaustive event list, but its reference to NIST SP 800-92 (Guide to Computer Security Log Management) and the assessment objectives in NIST SP 800-171A make the intended scope clear. For CUI systems, the following event categories are required:
Authentication Events
Every authentication attempt — successful and failed — against CUI systems must be logged with sufficient context to identify the user, the system, the time, and the outcome.
| Event | Log Fields Required |
|-------|-------------------|
| Successful login | Username, source IP, timestamp, authentication method (password, MFA, certificate) |
| Failed login | Username, source IP, timestamp, failure reason, attempt count |
| MFA challenge / bypass | Username, timestamp, factor used, outcome |
| Account lockout | Username, timestamp, triggering condition |
| Session creation / termination | Username, session ID, source, duration |
| Privilege elevation | Username, elevated privilege claimed, authorizing mechanism, timestamp |
Administrative Actions
All actions performed by privileged accounts must be logged — including configuration changes, user account management, and policy modifications.
| Event | Log Fields Required |
|-------|-------------------|
| User account creation / deletion / modification | Admin username, target account, action, timestamp |
| Group membership changes | Admin username, group, member added/removed, timestamp |
| Permission / role assignment | Admin username, resource, permission granted/revoked, timestamp |
| Security policy changes | Admin username, policy changed, old value, new value, timestamp |
| Audit policy changes | Admin username, change made, timestamp (especially important — per 3.3.9) |
| System configuration changes | Admin username, component, change description, timestamp |
CUI Data Access
Access to resources that store, process, or transmit CUI must be logged at the access level.
| Event | Log Fields Required |
|-------|-------------------|
| File/object read | Username, resource path, timestamp, result |
| File/object write / create / delete | Username, resource path, action, timestamp |
| Database query against CUI tables | Username, query (or query hash), row count, timestamp |
| CUI export / download | Username, destination, file name, size, timestamp |
| Email/transfer of CUI | Username, recipient, subject, attachment names, timestamp |
| Print / screen capture of CUI | Username, device, document, timestamp |
System and Network Events
Infrastructure events that could indicate compromise or unauthorized access:
- Network connection attempts to CUI servers (firewall logs)
- DNS queries from CUI network segments
- Patch application and failure events
- Antivirus / EDR alert and quarantine events
- Service start/stop events
- Software installation and removal
- Certificate issuance, renewal, and revocation
Negative Events: What Does NOT Need to Be Logged
Not everything needs to be in the SIEM. Excessive logging creates noise that undermines effective review. Events that do not need individual log records include routine scheduled task executions (without error), successful TLS session renegotiations (the session creation/termination is sufficient), and health check pings from load balancers.
3. Log Retention Requirements
The 800-171 control 3.3.1 requires logs be retained "to the extent needed to enable monitoring, analysis, investigation, and reporting." It does not specify a number. However, overlaying obligations provide concrete minimums:
DFARS 252.204-7012 — The Baseline
The DFARS clause requires DoD contractors to:
- Preserve images of compromised systems and all relevant logs for at least 90 days following a cyber incident, to support DoD forensic analysis.
- For cloud service providers handling CUI, retain audit logs for at least 90 days and make them available to the contracting agency.
The 90-day DFARS minimum is a forensic preservation floor, not a general retention target. It answers the question: "How far back can we investigate after we discover a breach?"
Industry Practice and Regulatory Convergence
For CUI environments that are subject to multiple regulatory frameworks (NIST 800-171, FedRAMP, HIPAA, SOX, PCI DSS in some contexts), the convergent retention standard is:
- Active / immediately searchable: 90 days minimum (DFARS baseline)
- Archived / retrievable within 24–48 hours: 12 months (FISMA, SOC 2 common practice, 1-year standard for most regulatory regimes)
- Cold archive / retrievable within days: 3–7 years (for contractual, litigation hold, or specific CUI category requirements)
Recommendation: For CUI environments, implement 12 months as the standard retention period for SIEM-indexed logs, with cold archival for an additional 2 years. This satisfies DFARS, meets the common 1-year standard cited in FISMA and most audit frameworks, and provides reasonable forensic reach for the advanced persistent threats (APTs) that may dwell in a CUI environment for months before detection.
Time Synchronization (3.3.7)
Log retention is meaningless if the timestamps are wrong. Control 3.3.7 requires all systems to synchronize their clocks with an authoritative time source. In practice:
- All CUI systems should point to NIST's Network Time Protocol (NTP) servers (
time.nist.gov) or a DoD-authorized equivalent as their NTP source. - NTP synchronization should be monitored; drift or NTP failure should generate an alert.
- Log timestamps should be in UTC; local timezone display is a presentation layer concern, not a storage concern.
- SIEM ingestion should normalize timestamps at collection time to prevent gaps from clock drift.
4. Log Aggregation and SIEM Architecture
Control 3.3.5 requires correlation of audit records, which in practice requires a Security Information and Event Management (SIEM) platform. A SIEM collects logs from all sources, normalizes them into a common schema, and provides the query, alerting, and correlation capabilities needed to detect threats and satisfy assessors.
SIEM Platform Options for CUI Environments
| Platform | Key Characteristics | CUI/CMMC Suitability |
|----------|--------------------|-----------------------|
| Microsoft Sentinel (Azure GCC High) | Native Azure integration; FedRAMP High authorized in GCC High; built-in CMMC workbooks; low barrier for M365-centric environments | Optimal for Azure/M365 GCC High environments |
| Splunk Enterprise Security | Mature, feature-rich; available on-premises and in GovCloud; extensive connector ecosystem | Strong choice for hybrid or on-prem CUI environments |
| Elastic Security (on-prem or Cloud) | Open-source foundation; cost-effective; requires more engineering investment; FedRAMP Moderate for Elastic Cloud | Cost-effective for technically mature teams |
| IBM QRadar | Long-standing federal market presence; SIEM and SOAR combined; available in GovCloud | Enterprise DoD environments |
Log Source Coverage
A SIEM for CUI compliance must collect from all systems in the CUI boundary:
| Source Category | Examples | Collection Method |
|----------------|----------|-------------------|
| Identity / Directory | Azure AD / Entra ID sign-in logs, MFA logs | Azure Monitor / Diagnostic Settings |
| Endpoints | Windows Security Event logs (Event IDs 4624, 4625, 4648, 4688, etc.), EDR telemetry | Microsoft Defender for Endpoint / AMA agent |
| Network | Firewall logs, NSG flow logs, DNS query logs | Azure Monitor / Syslog forwarder |
| Applications | Web server access logs, database audit logs, custom application logs | Log Analytics agent / Filebeat |
| Cloud platform | Azure Activity Log (admin actions), Azure Resource Logs | Azure Diagnostic Settings (automatic in GCC High) |
| Email | Microsoft 365 Unified Audit Log (mail flow, access, sharing) | Office 365 connector for Sentinel |
| Cloud storage | Azure Storage access logs, SharePoint access logs | M365 Defender / Purview |
Critical Log Sources Often Missed
From ATO work and CMMC assessments, the log sources most frequently absent: Azure AD Conditional Access policy evaluation logs (which access attempts were blocked and why); Azure Key Vault audit logs (who accessed cryptographic keys, essential for 3.13.11); backup and replication job logs (failures are ransomware indicators); and DNS query logs (C2 communication and data exfiltration often appear here first).
5. Log Protection — Integrity and Access Control (3.3.8 and 3.3.9)
Controls 3.3.8 and 3.3.9 address the integrity and access control of logs themselves. These controls exist because an attacker who compromises a system will often attempt to delete or modify logs to cover their tracks.
3.3.8 — Protection from Unauthorized Access, Modification, and Deletion
Hash-based integrity verification: Each log file or log batch should be signed or hashed upon creation using a FIPS-validated algorithm (SHA-256 or SHA-384). Storing the hash separately from the log — in a different system or cloud storage account — means that modification of the log invalidates the hash, providing forensic evidence of tampering.
Immutable storage: Cloud-native immutable storage is the modern standard:
- Azure Blob Storage with immutability policies (WORM): Time-based retention locks prevent deletion or modification for the specified period. Available in GCC High.
- AWS S3 Object Lock (GovCloud): Compliance mode prevents deletion by any user, including administrators, for the lock duration.
- Splunk SmartStore with WORM storage backends.
Access controls: The SIEM and log storage must be configured so that:
- System users (including CUI system administrators) cannot access or modify log data.
- SIEM administrative access is restricted to a dedicated security team.
- All access to the SIEM administrative interface is itself logged.
3.3.9 — Limiting Audit Log Management to Privileged Users
The management of audit logging functionality — defining what events are logged, modifying log retention settings, accessing log management interfaces — must be restricted to a subset of privileged users distinct from the general system administration population.
Implementation:
- Create a dedicated "Log Administrator" or "Security Operations" role with access to SIEM management.
- Separate this role from the "System Administrator" role — a system admin who can modify the audit policy can erase evidence of their own misconduct.
- Enforce separation of duties: the same individual should not have both system administration rights and log management rights in the CUI environment.
- All changes to audit policy must themselves be logged (control 3.3.3 requires the logged event set to be reviewed and updated; these changes are auditable events).
6. Log Review Cadence — Daily Automation, Weekly Human Review
Control 3.3.5 requires correlation and review. "Review" without cadence, ownership, and documentation is not review — it is a policy claim without evidence. A defensible review program has two tiers:
Tier 1: Daily Automated Review
The SIEM runs continuous and scheduled detection rules that fire alerts when threshold conditions are met. Practitioners should configure, at minimum:
| Alert Category | Example Rule | Threshold |
|---------------|-------------|-----------|
| Authentication anomaly | Failed login attempts | 10+ failures in 5 minutes for a single account |
| Privilege abuse | Privileged actions by non-privileged accounts | Any |
| After-hours CUI access | CUI data access outside business hours by non-approved users | Any |
| Bulk data access | File/record count exceeding normal baseline | >500 records in one session |
| Audit logging failure | Gap in log ingestion from any required source | Any gap >15 minutes |
| Impossible travel | Login from location A and B within time window impossible for travel | Any |
| Malware detection | EDR alert escalation | High/Critical severity |
| New privileged account | Admin account creation | Any |
Every alert must have a designated owner (typically a Security Operations function) and a documented response procedure. CMMC assessors will ask: "What do you do when this alert fires?" An alert that fires into a void does not satisfy 3.3.5.
Tier 2: Weekly Human Review
In addition to automated alerting, a human analyst should review aggregated SIEM dashboards weekly, covering: (1) alert summary — which alerts fired, which were investigated, and which resulted in action; (2) top failed authentications and privileged account activity; (3) unusual CUI access patterns (new users, bulk downloads, after-hours access); (4) log source health confirming all sources are flowing; and (5) new accounts or permission changes during the period.
Documentation: The weekly review must be documented — a signed review log, a dated SIEM report export, or a ticketing system entry. This is the evidence assessors will request to demonstrate that 3.3.5 is operational, not merely configured.
Monthly and Quarterly Reviews
- Monthly: Audit the list of logged events (3.3.3) — are there new systems, new applications, or new CUI data stores that should be added to the log source inventory?
- Quarterly: Review and test the SIEM alert rules — which rules have never fired? Are they correctly configured? Which fired frequently without finding real threats (false positive review)?
7. Sample Architecture — Azure GCC High
The following architecture describes a defensible audit and accountability program for a CUI environment hosted in Azure GCC High, the Microsoft cloud environment authorized for DoD CUI under DFARS 252.204-7012.
Architecture Overview
`
CUI Systems (Azure GCC High)
├── Entra ID → Sign-in logs, Audit logs, Conditional Access logs
│ → Log Analytics Workspace (GCC High)
├── Azure VMs → Windows Security Events (AMA agent) + App logs
│ → Log Analytics Workspace
├── Microsoft 365 GCC High → Unified Audit Log, Defender, Purview DLP
│ → Sentinel via M365 connector
├── Network → NSG Flow Logs, Azure Firewall, DNS Query logs
│ → Log Analytics Workspace
└── Azure Storage → Access logs → Log Analytics Workspace
`
Microsoft Sentinel (GCC High)
Microsoft Sentinel serves as the SIEM and SOAR platform:
- Log Analytics Workspace: The data plane for all log ingestion. Configure workspace retention to 12 months (or the organization's defined retention period) in GCC High settings.
- Sentinel Analytic Rules: Deploy CMMC-aligned detection rules. Microsoft publishes a CMMC content hub solution for Sentinel that includes pre-built rules aligned to 800-171 controls.
- Sentinel Workbooks: The CMMC workbook provides a compliance dashboard view of 3.3 control implementation.
- Automation Playbooks (Logic Apps): Automated response to high-priority alerts (e.g., auto-lock account on brute force detection).
Log Immutability in Azure GCC High
- Log Analytics Workspace lock: Apply Azure Resource Lock (CanNotDelete) to prevent workspace deletion.
- Azure Blob Storage (archive tier): Export Log Analytics data to an Azure Storage account with an immutability policy (WORM, time-based retention lock) for the cold archive tier.
- Dedicated storage account: The log archive storage account should be in a separate Azure subscription or resource group from the CUI workloads, with access restricted to the security operations team via Azure RBAC.
Time Synchronization
Azure VMs automatically synchronize with Azure's NTP infrastructure, which is synchronized with authoritative sources. Verify that:
- Custom NTP configurations have not overridden the default Azure time sync.
- Windows VMs use the W32tm service; verify with
w32tm /query /status. - Log Analytics timestamps are in UTC (default behavior).
Key Windows Event IDs for CUI Environments
| Event ID | Event | Required For |
|----------|-------|-------------|
| 4624 | Successful logon | 3.3.1, 3.3.2 |
| 4625 | Failed logon | 3.3.1, 3.3.5 |
| 4648 | Logon using explicit credentials | 3.3.1, 3.3.2 |
| 4672 | Special privileges assigned | 3.3.1, 3.1.5 |
| 4720 | User account created | 3.3.1 |
| 4740 | User account locked out | 3.3.1, 3.3.5 |
| 4907 | Audit policy change | 3.3.3, 3.3.9 |
| 5140 | Network share object accessed | 3.3.1 |
8. Assessor Expectations — What C3PAOs Look For
CMMC Level 2 assessors reviewing the 3.3 family will request specific evidence for each control. The following table maps controls to expected evidence:
| Control | Evidence Assessors Request |
|---------|--------------------------|
| 3.3.1 | List of log sources; sample logs; retention configuration showing period; log system architecture |
| 3.3.2 | Evidence that logs include individual user identity (not shared accounts); demo of attributing a specific action to a specific user |
| 3.3.3 | Dated record of logged event review (e.g., quarterly review meeting notes or ticketing system entries showing event list updates) |
| 3.3.4 | Alert rule showing notification when log source goes silent; test evidence that alert fires |
| 3.3.5 | SIEM correlation rules; sample incident where correlation identified a threat; review documentation |
| 3.3.6 | Demonstration of ad hoc query capability; sample reports generated; incident investigation workflow |
| 3.3.7 | NTP configuration on all in-scope systems; monitoring evidence that sync is maintained |
| 3.3.8 | Log storage access control configuration; immutability policy settings; hash integrity verification procedure |
| 3.3.9 | Role-based access control configuration showing log management restricted to security personnel; separation from system admin role |
A note on shared accounts: Control 3.3.2 fails completely if CUI systems use shared administrator accounts (e.g., a single "admin" password shared among IT staff). Shared accounts cannot trace actions to individuals. CMMC assessors treat this as a showstopper finding that affects both 3.3.2 and the broader identity and access management family.
9. Common Gaps and How to Close Them
From CMMC readiness assessments and ATO package reviews, the following gaps appear most frequently in the 3.3 family:
Gap 1: Logs exist but are not searched. The SIEM is configured and logs flow, but no alert rules are enabled and no one reviews dashboards. The SIEM is functioning as an expensive log archiver. Remediation: configure at minimum the alert set in Section 6; establish documented weekly review procedure with assigned ownership.
Gap 2: Shared service accounts. Multiple administrators share credentials; CUI database access uses a single application service account that is not attributed to individual users. Remediation: eliminate shared credentials; use individual service accounts with managed identity where possible; enable enhanced logging at the application level that records which individual triggered an application action.
Gap 3: Cloud service logs not collected. On-premises systems are in the SIEM; Azure/M365 logs are not. The "shadow CUI" — SharePoint, Teams, Exchange Online — often handles more CUI than the formal on-premises systems. Remediation: connect M365 Unified Audit Log, Entra ID, and Defender to Sentinel via native connectors.
Gap 4: Log retention misconfigured. Default Log Analytics workspace retention is 30 days; organizations forget to extend it. Remediation: set workspace retention to the required period (90-day minimum, 12 months recommended) in the Azure Portal.
Gap 5: No alerting on audit logging failures (3.3.4). Most organizations have never thought to alert on the absence of expected logs. Remediation: create a heartbeat rule for each required log source that alerts if no events are received within a defined window (e.g., 30 minutes silence from a required source).
Gap 6: Administrators can delete logs. SIEM administrators with unrestricted access can delete log data. Remediation: apply Azure RBAC to restrict delete permissions on Log Analytics workspaces; apply resource locks; use WORM storage for archives.
10. Conclusion
The nine controls of NIST 800-171 family 3.3 are among the most tractable in the CUI compliance framework — concrete, testable, and achievable with commercially available technology. Microsoft Sentinel in GCC High satisfies all nine controls when properly configured. The challenge is discipline: logging the right events, retaining them for the right period, protecting them from tampering, and reviewing them on a documented cadence.
From LANL ATO experience and DoD Secret-level system work, the value extends beyond compliance. When an incident occurs — and in the current threat environment, incidents will occur — the audit program is the difference between a clean 72-hour DFARS forensic narrative and a months-long investigation with no answers. Audit infrastructure is operational resilience.
About the Author
Leonard Esere is a senior security architect with deep experience in federal compliance, incident response, and security architecture for CUI and classified environments. His work supporting ATO packages at Los Alamos National Laboratory (LANL) included building and validating audit programs that met the demanding standards of DoE/NNSA oversight. He has worked on systems requiring DoD Secret and DoE Q clearance levels, where audit trail integrity was a non-negotiable security control. His broader practice includes CMMC Level 2 readiness support, MITRE ATT&CK-aligned threat modeling, and PCI DSS compliance architecture for large-scale computing environments.
References
1. National Institute of Standards and Technology. (2021). NIST SP 800-171 Rev. 2, Family 3.3: Audit and Accountability. https://doi.org/10.6028/NIST.SP.800-171r2
2. National Institute of Standards and Technology. (2006). NIST SP 800-92: Guide to Computer Security Log Management. https://doi.org/10.6028/NIST.SP.800-92
3. Defense Federal Acquisition Regulation Supplement. DFARS 252.204-7012: Safeguarding Covered Defense Information and Cyber Incident Reporting. https://www.acquisition.gov/dfars/252.204-7012
4. Microsoft Learn. Connect Microsoft 365 Defender to Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/sentinel/connect-microsoft-365-defender
5. Microsoft Tech Community. (2020). CMMC Compliance with Azure Sentinel. https://techcommunity.microsoft.com/blog/publicsectorblog/cmmc-compliance-with-azure-sentinel/1303993
6. NeQter Labs. (2022). NIST SP 800-171 Requirement 3.3: Audit & Accountability. https://neqterlabs.com/nist-sp-800-171-requirement-3-3-audit-accountability/
7. DTS Consulting. (2022). Guidance on NIST 800-171 Log Retention. https://consultdts.com/article/nist-800-171-log-retention/
8. National Institute of Standards and Technology. (2022). NIST SP 800-171A: Assessing Security Requirements for Controlled Unclassified Information. https://doi.org/10.6028/NIST.SP.800-171Ar2
9. Cybersecurity and Infrastructure Security Agency. (2023). Zero Trust Maturity Model 2.0. https://www.cisa.gov/zero-trust-maturity-model
10. Microsoft Learn. Azure Monitor Logs Overview. https://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-platform-logs
Take the Next Step
Building a defensible 3.3 audit program requires careful planning, the right tooling, and ongoing operational discipline. If your organization needs help designing a SIEM architecture for GCC High, configuring CMMC-aligned alert rules in Microsoft Sentinel, or preparing audit log documentation for a C3PAO assessment, Aeolitech's security engineering team is ready to assist.
Contact Aeolitech to schedule an audit and accountability gap assessment or to discuss your CMMC Level 2 readiness.