Every organization has logs. That’s not the hard part. The hard part is being able to walk an assessor through what you’re logging, where it goes, who looks at it, and what happens when they find something. Most companies can answer the first question. Almost nobody has a clean answer for the last three.
What the assessor is actually evaluating
The NIST language says “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.” In the assessment room, that breaks down to four things:
Do you know what’s being logged? Not “we have logging turned on.” The assessor wants to know specifically what events are being captured. Failed logins. Privilege escalations. File access in CUI repositories. Changes to security configurations. Group Policy audit settings. If you can’t list the categories of events you’re capturing across your CUI boundary systems, you’re not ready.
This goes deeper than most people realize. It’s not enough that your SIEM is collecting syslog from your firewall. Are the right events configured on the firewall to begin with? Are Group Policy audit policies set to capture both success and failure for the events that matter? Are your switches and network devices sending the logs they should be? There’s a difference between “logs are flowing” and “the right logs are flowing,” and the assessor may probe that distinction.
Where do the logs go, and for how long? The assessor will ask about centralization and retention. If your logs live only on the device that generated them, that’s a problem. They can be tampered with or lost. Centralizing logs in a SIEM or log management platform is the expected answer. Retention should be defined and documented. Ninety days is a common minimum, but your SSP needs to state what you’ve committed to and you need to be able to show that logs actually exist going back that far.
Who reviews them, and on what schedule? This is the question that ends conversations. The assessor will ask who is responsible for reviewing audit logs and how often. “Our SIEM sends alerts” is part of the answer, not all of it. Automated alerting catches known-bad patterns. The assessor wants to know that a human being is also looking at the logs on a regular basis, daily, weekly, whatever you’ve defined, and that there’s evidence it happened.
What’s your process for making sure the right things are being logged? This one catches people off guard. Your environment changes. New systems come online, configurations get modified, new applications get deployed. If nobody periodically checks that the log sources and audit policies are still capturing what they should be, gaps creep in. The assessor may ask when you last reviewed your log source inventory or validated your audit policy settings.
What a realistic SSP definition looks like
[Organization Name] maintains system audit logs for all systems within the CUI boundary. Audit events are configured to capture, at minimum: successful and failed authentication attempts, privilege escalation, changes to user accounts and security groups, access to CUI repositories, changes to audit policy configurations, and system-level events including service starts/stops and configuration changes.
Audit events are forwarded to a centralized [SIEM/log management platform] managed by [internal IT / MSSP name]. Logs are retained for a minimum of [retention period, e.g. 90 days / 1 year] in the centralized platform. Raw logs on source systems are retained for a minimum of [period] before rotation.
Log review is conducted [frequency, e.g. daily / weekly] by [role, e.g. the SOC team at our MSSP / the IT Director]. Reviews cover alerting output, anomalous activity, and baseline deviation. Review completion is documented via [method, e.g. ticketing system, signed review log, MSSP report].
The log source inventory and audit policy configurations are reviewed [frequency, e.g. quarterly] by [role] to ensure new systems are captured and audit policies remain aligned with requirements. Changes to the logging configuration are documented and approved by the IT Director.
A few things to notice:
It specifies what events are being captured. Not “we log system activity.” The assessor wants to see that you’ve thought about which events matter for your environment. Failed authentication, privilege changes, access to CUI. Those are the ones they’ll check for.
It addresses the log source review process. This is the piece most SSPs miss entirely. Environments change. People add servers, deploy new applications, replace firewalls. If nobody checks that the new stuff is feeding logs to the SIEM, you develop blind spots. Stating that you review log sources on a defined schedule shows the assessor you understand this.
It names who reviews and how often. “Logs are reviewed” is vague. “The SOC team reviews daily and provides a weekly summary report” is specific and verifiable. The assessor will follow up, and the answer needs to match what’s written.
How to present your evidence
When the assessor gets to AU.L2-3.3.1, have these ready:
A log source inventory. A document listing every system in your CUI boundary that generates audit logs, what events it’s configured to capture, and where those logs are sent. This is the foundation of everything else. If you can’t produce this list, the assessor has no way to verify that your logging is complete.
Audit policy configuration evidence. Screenshots or exports showing the actual audit policy settings on representative systems. For Windows environments, this means Group Policy audit settings showing what’s configured for success and failure auditing. For network devices, this means showing the logging configuration on your firewalls, switches, and other infrastructure. The assessor may ask to see these live.
Log review records. Evidence that someone actually reviewed the logs on the schedule you defined. This could be MSSP reports, ticketing system entries, signed review forms, or dated email confirmations. Whatever format it’s in, it needs to show the date, who did the review, and that it happened consistently over time.
A live demonstration. Be ready to show the assessor your SIEM or log management platform. They may ask to see logs in real time, run a query, or verify that a specific type of event is actually being captured. If you’ve defined that you log failed authentication attempts, they might ask you to show one.
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
"We have a SIEM, so we're covered." Having a SIEM is infrastructure, not a program. If nobody can explain what's configured to be captured, who reviews the output, or when the log sources were last validated, the SIEM is just collecting data into a void. The assessor will ask what happens after logs arrive, and "it generates alerts" is only half the answer.
No defined review frequency, or a defined one that isn't being met. If your SSP says logs are reviewed weekly and your last documented review was six weeks ago, that's a finding. It's better to commit to a realistic schedule and actually meet it than to write "daily" in your SSP and have no evidence to back it up.
Incomplete logging. Group Policy audit settings that only capture success events and not failures. Firewalls logging allowed traffic but not denied. Servers forwarding system logs but not security logs. The assessor may drill into this, especially if they're technical. The fix isn't hard. It's an audit policy setting. But you need to check it before they do.
No process for validating log sources over time. You added your file server to the SIEM two years ago. Since then you've deployed three new servers, replaced a firewall, and migrated a service to the cloud. Are all of those sending logs? If nobody checks, the answer is usually no. The assessor knows this pattern and will ask when you last validated your log source inventory.
Can't demonstrate logs live. If the assessor asks to see a failed login event in your SIEM and nobody in the room knows how to run the query, that undermines everything else you've presented. Someone in the room needs to be comfortable showing the logs in real time.
A log source inventory that's current and covers the CUI boundary. Audit policy configurations that capture the events that matter, with evidence showing the settings. A defined review schedule that's actually being met, with dated records. Someone in the room who can pull up the SIEM and show it working. When the paperwork, the configuration, and the live demo all tell the same story, the assessor moves on.
If you use an MSP/MSSP
Audit logging is one of the practices where the MSP/MSSP relationship matters most, because in many small organizations the MSSP is the one actually operating the SIEM and reviewing the logs.
That’s fine. It’s the right model for most small contractors, honestly. But you need to be able to explain the arrangement clearly, and you need to have evidence from your MSSP that demonstrates the review is happening.
Here’s what the split usually looks like:
What’s typically on you (the contractor):
- Defining what your audit requirements are (which events, what retention period)
- Reviewing the MSSP’s summary reports
- Escalating or acting on findings the MSSP identifies
- Knowing what’s being logged in your environment at a high level
What’s typically on the MSSP:
- Deploying and maintaining the SIEM
- Configuring audit policies and log collection
- Conducting daily/weekly log reviews
- Providing documented review reports
- Alerting on anomalous or unauthorized activity
- Maintaining the log source inventory and validating coverage
Your MSSP should be in the room during the assessment. Not optional, not “available by phone.” In the room. They’re the ones operating the SIEM, reviewing the logs, and maintaining the configurations. They should be able to explain all of that directly to the assessor. If your MSSP also handles compliance program management, they’ll already know what the assessor is going to ask and how to demonstrate it. That’s the model that works.
You still need a basic understanding of the arrangement. What events are being captured, where the logs go, who reviews them. But you shouldn’t be the one explaining the technical details of your MSSP’s operations. That’s their job, and if they can’t do it in the assessment room, that’s a problem with the MSSP.
A good MSSP handles log review internally, documents it at the defined frequency, and only alerts you when something actually needs your attention. You shouldn't be reviewing raw SIEM output yourself. That's their job. What you should see is a monthly or quarterly summary that covers what was reviewed, what was found, and what was done about it. Concise, dated, ready to hand to an assessor.
The MSSP should be fully capable of demonstrating all of this themselves in the assessment room without much input from you. If your MSSP gives you a 40-page automated dump from the platform and calls it a review, push back. You need evidence of human analysis, not evidence of software running.
This page covers AU.L2-3.3.1 from NIST SP 800-171 Rev 2 (3.3.1). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.