What Is This CMMC Control?
Organizations must periodically review and update the types of events being logged to ensure they remain relevant, necessary, and sufficient for security monitoring. This is not about reviewing individual log entries, but rather evaluating whether the categories of events being captured still align with current threats, system changes, and security needs.
Control Intent
Ensure that audit logging remains effective and relevant over time by periodically reassessing which event types should be captured, preventing both gaps in security monitoring and unnecessary log bloat that could obscure important security events.
Who This Control Applies To
- •All systems that process, store, or transmit CUI
- •Systems where audit logging is implemented per AC.L2-3.3.1 and AU.L2-3.3.2
- •Centralized logging infrastructure and SIEM platforms
- •Individual system logging configurations
- •Cloud service provider logging settings
- •Network devices, databases, and applications handling CUI
Not Applicable When
- •The organization has no systems processing CUI
- •Audit logging is not yet implemented (must implement AU.L2-3.3.1 and AU.L2-3.3.2 first)
- •The system is fully decommissioned and no longer in scope
Key Objectives
- 1Maintain an up-to-date list of event types that must be logged across all systems handling CUI
- 2Periodically evaluate whether currently logged events remain necessary and sufficient for security monitoring
- 3Adjust logging configurations to reflect changes in threats, system architecture, compliance requirements, and operational needs
- 4Prevent audit logging from becoming stale or irrelevant due to organizational or technical changes
Sample Self-Assessment Questions (Partial)
Do you have a documented list of event types that your systems are configured to log?
When was the last time you reviewed whether the events you're logging are still the right ones to capture?
Implementation Approaches (High-Level)
Scheduled Annual Logging Review
Conduct a formal annual review of all logged event types with documented decisions and implementation of changes
Event-Driven Logging Updates
Review and update logged events whenever significant changes occur to systems, threats, or requirements
Continuous Logging Optimization Program
Ongoing monitoring and tuning of logged events based on SIEM analytics, storage metrics, and security operations feedback
Risk-Based Logging Review
Periodic review of logged events based on system risk classification and data sensitivity
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If no review process exists, establish a documented procedure with defined frequency (at minimum annually) and assign responsibility If reviews have not occurred, schedule and conduct an initial review within 30-60 days and document findings If reviews occur but are not documented, implement a documentation template and conduct a documented review immediately If logged events have not been updated based on reviews, prioritize implementing changes identified in the most recent review Acceptable interim steps: conduct initial review and document current state, establish review schedule, implement high-priority logging changes first POA&M should specify review frequency, responsible parties, documentation requirements, and implementation timeline for changes Consider starting with high-risk systems or systems that have experienced incidents if full environment review is not immediately feasible Leverage existing change management and incident response processes to trigger logging reviews while formal periodic process is established
Frequently Asked Questions
What is the difference between reviewing logged events (AU.L2-3.3.3) and reviewing audit logs (AU.L2-3.3.4)?
AU.L2-3.3.3 requires reviewing and updating the types of events you configure systems to log (e.g., deciding whether to log failed login attempts, file deletions, or configuration changes). AU.L2-3.3.4 requires reviewing the actual log entries that are generated to detect security incidents. Think of 3.3.3 as reviewing your logging strategy and 3.3.4 as reviewing the logs themselves.
How often do we need to review and update our logged events?
CMMC does not specify an exact frequency, but assessors typically expect at least annual reviews. More frequent reviews may be necessary if you experience security incidents, add new systems, face new threats, or have compliance requirement changes. The key is having a documented process with a defined frequency appropriate to your environment's rate of change.
Do we need to review logged events for every individual system separately?
Not necessarily. You can establish centralized logging standards that define event types by system category (e.g., Windows servers, network devices, cloud services) and review those standards periodically. However, you must ensure that individual systems are actually configured according to those standards and that the standards cover all system types in your CUI environment.
What should we consider when reviewing which events to log?
Consider recent security incidents and whether you had sufficient logging to detect and investigate them, changes to your threat landscape or compliance requirements, new systems or technologies you've deployed, feedback from your security operations team about logging gaps or excessive noise, and whether your current logging aligns with your security monitoring use cases and detection capabilities.
What happens if our review identifies that we need to log additional event types?
You must update your logging configurations to capture the newly identified event types. This typically involves updating your logging standards documentation, implementing configuration changes across affected systems, and verifying that the new events are being captured. The implementation should occur within a reasonable timeframe (typically 30-90 days) and be tracked through your change management process.
Can we remove event types from our logging configuration during a review?
Yes, if your review determines that certain event types are no longer necessary or useful, you can remove them. However, you must document the rationale for removal and ensure that removing those events does not create gaps in your ability to detect security incidents or meet compliance requirements. Be cautious about removing events - it's generally safer to keep logging comprehensive.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.