Audit log review is the center of gravity for the entire AU family. You collect logs from endpoints, networks, identity systems, and applications. Then you need to actually look at them regularly, find the problems, and tell leadership what you found. This isn’t a technical detail. It’s the main mechanism for detecting incidents, compliance violations, and security failures in real time.
AU.L2-3.3.3 requires three specific components: regular review, analysis for anomalies, and management reporting. If your organization has an MSSP or internal security operations center (SOC), they typically own the daily review work. But you still need to document what happened and what decisions were made. The logs you create under AU.L2-3.3.1 are worthless if nobody reviews them. This practice is where logs become intelligence.
What the assessor is actually evaluating
The assessor will ask two real questions. First: “Show me the documentation that you reviewed audit logs during the period we’re assessing.” This means they want evidence that audit review happened on the schedule you defined. Not raw logs. Not a SIEM screenshot. A document that says “We reviewed logs from [date range], found [X] anomalies, and took [Y] action.”
Second: “How do you distinguish normal activity from anomalies?” They want to see that you have criteria for what matters. If everything is an anomaly, nothing is. If nothing is flagged, you’re not looking carefully. The middle ground is a defined set of detection rules or risk thresholds that guide your analysis. This is where AU.L2-3.3.5 (correlation) becomes powerful. Single-source alerts are noise. Multi-source patterns reveal real attacks.
Third, unstated but checked: “Did you report findings to someone with authority to act?” If the analysis stays in the SOC and never reaches leadership, it fails this practice. Management needs a summary at the frequency your SSP defines. Monthly is standard. Quarterly is defensible. Yearly is usually not.
What a realistic SSP definition looks like
- Failed authentication attempts exceeding [X] per account per day
- Privilege escalation events
- Data access to sensitive systems from unusual network locations or times
- Configuration changes to security controls
- Deletion or modification of audit logs
- User account creation, modification, or deletion
- File or data transfers exceeding normal thresholds
Anomalies and potential security events are documented in a monthly audit review log with timestamps, affected systems, severity assessment, and action taken. This summary is reported to [title] and [title] within [X] days of month end. Corrective actions are tracked through [system/process] and verified by [responsible party]."
Note the specifics: monthly, named person, specific criteria, documentation format, reporting timeline. This is what assessors expect to see.
How to present your evidence
- Monthly audit review summaries or logs (12 months)
- Management reports showing findings and actions taken
- Documentation of analysis criteria or detection rules
- Evidence of management notification (emails, meeting notes)
Pull together your actual audit review documentation for the past 12 months (or since last assessment). This should include:
Monthly audit summaries or review logs. These don’t need to be lengthy. Include date range, systems reviewed, number of events processed, anomalies identified, severity levels, and actions taken.
Management reports. These are the distilled versions sent to leadership. Focus on risk. Include findings, trends, and what was done in response.
Criteria or rules documentation. Show the assessor the specific conditions that trigger your analysis focus. This can be a SIEM rule set printout, an internal procedure document, or your security operations playbook.
Evidence of management notification. Email copies, meeting notes, or a review log that shows findings reached the right people on schedule.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
If you use an MSSP
Your MSSP typically owns log collection, aggregation, daily review, and initial analysis. They handle the continuous monitoring and flag anomalies. What they provide to you is a documented summary of their findings and recommendations. You review their summary, understand their conclusions, and sign off on corrective actions. The final approval of responses stays with you.
A good MSSP maintains their own analysis logs showing what they reviewed, what they found, and what they escalated. They send you a monthly or quarterly summary explaining their analysis methodology, what they reviewed, what they found (even if nothing significant), and any items that required your attention. Your role is oversight and decision-making, not daily log review.
Have your MSSP provide monthly or quarterly summaries that clearly state what they reviewed, what their analysis methodology is, what they found, and what they escalated. This documentation becomes your evidence of review. In the assessment room, the MSSP should be able to walk the assessor through their analysis process. You confirm you received and reviewed their reports.
Disclaimer: This guide is educational and not official CMMC documentation. Always refer to NIST SP 800-171 and the official CMMC Assessment Guide for authoritative requirements. Individual assessment results depend on implementation details specific to your organization.