AU.L2-3.3.6

AU.L2-3.3.6: Audit Reduction and Report Generation

Create tools and processes to filter audit logs and generate reports that focus on security-relevant events rather than routine system activity.

Raw logs are noise. An active endpoint generates hundreds of events per hour. A busy file server logs tens of thousands of access events per day. Without filtering, your analysts spend their time reading the system performing routine housekeeping instead of finding actual threats. AU.L2-3.3.6 requires you to reduce the log volume to the events that matter for security.

Log reduction doesn’t mean discarding data. It means filtering. You keep all logs for a defined retention period, but for analysis purposes, you present only the events that are likely to indicate a problem. A failed authentication attempt is relevant. A user opening a file they normally access is noise. This filtering is what makes AU.L2-3.3.3 (log review) practical. Without it, reviewers drown in volume.

Family Audit and Accountability
Practice AU.L2-3.3.6
Difficulty Medium
Key evidence Reduction criteria documentation, SIEM filters, reduction rules, sample reports

What the assessor is actually evaluating

The assessor wants to understand two things. First: “How do you decide what’s worth analyzing?” Your answer should include specific categories of events you filter for. Examples: authentication failures, privilege escalations, failed data access, configuration changes, firewall policy violations, or antivirus detections. If you can’t explain why an event is important, it shouldn’t be in your filtered view.

Second: “Do you have the full logs available if you need them?” The reduction is a convenience for analysis, not a deletion. All data is retained in its original form and queryable. If an incident investigation requires examining events you normally filter out, you have them. The assessor will ask you to retrieve an event that’s normally outside your filtered set. Being able to do so proves you haven’t actually deleted anything.

What a realistic SSP definition looks like

Example SSP Language: AU.L2-3.3.6
"Our organization implements log reduction and filtering to make audit data manageable while retaining all collected logs for security analysis and forensic investigation. All audit records are retained in their original form for a minimum of [X] months in our centralized SIEM.

For daily analysis and reporting, we apply filters that focus on security-relevant events:

  • Authentication and access control events: failed logins, privilege escalations, account creation or modification, password changes
  • Data access anomalies: access to sensitive systems or data repositories from unusual sources, unusual access patterns for individual users
  • Configuration or policy changes: changes to security controls, firewall rules, or system configurations
  • Malware and threat detection: antivirus or endpoint detection alerts, intrusion detection system matches
  • System or service failures related to security systems: logging system failures, security software disabled, service outages

Events below the threshold for analysis (successful routine logins from expected sources, normal file access) are not displayed in routine analysis dashboards but remain in the underlying log store. Analysts can query the complete unfiltered dataset at any time for investigation or compliance verification.

Automated reports are generated [weekly/monthly] summarizing security-relevant events by category and severity, with trends and notable patterns highlighted. Report templates are reviewed [quarterly/annually] to ensure relevance."

The critical phrase: all logs are retained, but analysis focuses on signal.

How to present your evidence

Evidence checklist
  • Log reduction criteria documentation with justification for each category
  • SIEM filters or saved searches showing what's included and excluded
  • Sample reports showing before/after metrics (raw events vs. filtered)
  • Query examples demonstrating unfiltered data is still available

Prepare three elements:

  1. Log reduction criteria documentation. A written document or section of your security procedures that explains the categories of events you consider security-relevant for analysis purposes. For each category, explain why it matters. This becomes your baseline for what your SIEM filters should do.

  2. SIEM filters or queries. Screenshots or exports from your SIEM showing the filters, saved searches, or dashboards you use for analysis. Document which events they include and exclude. If you use whitelisting (explicitly exclude known good activity), document what’s whitelisted and why.

  3. Sample reduced reports. Generate a report of security-relevant events from a recent period (one week to one month). This shows the assessor what your analysts actually look at. Include the event count before and after reduction. For example: “Raw logs from this period: 5.2 million events. After reduction: 1,247 security-relevant events.” This demonstrates the signal-to-noise improvement.

Also demonstrate that you can retrieve unfiltered data. Run a query that pulls a specific event type that you normally exclude. Show the full details. This proves the data exists and is queryable.

Get assessment room tips in your inbox

Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.

Assessment room tips

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.

Q: "What events do you consider security-relevant enough to include in analysis? Why?"
List your categories and justify each. "Failed authentication attempts because they indicate password guessing. Privilege escalations because they precede lateral movement. Antivirus detections because they indicate malware presence." Specific justification beats generic lists.
Q: "Show me an event you normally filter out. Can you retrieve it from your logs if needed?"
Pick a routine event like a successful login to a common system. Query your logs to retrieve it. The ability to go from filtered analysis back to raw data proves your reduction is filtering, not deleting.
Q: "How do you prevent your filters from hiding real attacks?"
Explain your tuning process. You review alerts and analyst feedback. If an important event is regularly missed because it falls into a filtered category, you adjust. Mention that your IR team provides feedback on detection gaps discovered during incident investigations.

Common failures

Reduction without documentation: You filter logs, but you can't explain the criteria. Why is this event included and that one excluded? The assessor can't verify that your filters are reasonable or complete. Write it down first, then implement it.
Over-reduction hiding real events: You filter so aggressively that important security events are excluded from analysis. A month passes with no alerts in your reports. Real incidents occurred but were filtered out. Test your reduction criteria against known bad behavior from your organization's past incidents.
Clear before/after metrics: Your sample reports show "Raw: 4.8M events, Reduced: 1,356 events." This quantification helps the assessor understand the noise reduction while confirming that signal remains.
Baseline understanding of normal: Your reduction criteria account for what's normal in your organization. You understand that a file server naturally has thousands of daily access events. Your filters acknowledge this baseline and highlight deviations from it, not all access.

If you use an MSSP

Your MSSP implements log reduction on your behalf. They set the filter criteria in consultation with you, apply them in their SIEM, and provide you monthly or quarterly reports of the filtered, security-relevant events. They maintain a full unfiltered log store for your use if needed. The reduction criteria should be jointly defined so that you both understand what’s being analyzed and what’s being filtered out.

Your role is oversight. You review their reduction approach, understand their filter justifications, and approve or challenge the criteria. They maintain and tune the filters. You ensure the process aligns with your organization’s risk tolerance and compliance requirements. A good MSSP proactively optimizes filters based on threat environment changes and feedback from your organization.

Review MSSP reduction criteria with your organization

Request documentation of your MSSP's reduction criteria and filter configuration. Understand why each event type is included or excluded. Their monthly or quarterly reports should show the before/after metrics (total events vs. filtered events). In the assessment room, your MSSP should walk through their reduction process and filter decisions. You confirm you understand and approve of their criteria.

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.

New practice breakdowns and assessment tips every week. Follow on Substack to stay current as the November 2026 deadline gets closer.

← AU.L2-3.3.7: Authoritative Time Source All Practices AU.L2-3.3.5: Audit Correlation →