Audit Logging Under CMMC: What AU.L2 Requires and How Long You Actually Have to Keep Logs

Ask five compliance leads at defense contractors how long they need to retain audit logs, and you’ll get five different answers — six months, a year, three years, “whatever the SIEM defaults to,” or a shrug. That confusion isn’t accidental. CMMC doesn’t hand you a single retention number the way HIPAA or SOX sometimes feels like it does. Instead, AU.L2 spreads the requirement across a family of controls, and the actual retention period gets set by a combination of your system security plan, your contract flow-downs, and what a C3PAO assessor decides is “sufficient” during an Cybersecurity assessment. If you’ve been treating audit logging as a checkbox — “yes, we have logs” — this is where that approach falls apart.

This article walks through what the AU domain actually demands at Level 2, what “sufficient to support” really means in practice, and why the retention question has a defensible answer even though CMMC itself doesn’t print one on the page.

The AU Domain Isn’t One Control — It’s a System

CMMC Level 2 maps directly to NIST SP 800-171, and the Audit and Accountability family (AU) is one of the more operationally demanding domains in the whole catalog. It isn’t a single “turn on logging” requirement. It’s a chain: you have to determine which events need to be logged, generate records containing enough detail to support an investigation, protect those records from unauthorized access or modification, review them regularly, and retain them long enough to be useful when something goes wrong months later.

Most organizations we onboard have logging turned on somewhere — Windows Event Viewer is capturing something, a firewall is writing to a local buffer, maybe a cloud tenant has audit logs enabled by default. What they don’t have is a documented decision about which events matter, who reviews them, how long records live before rotation deletes them, and how those records get protected from tampering. That gap between “logging exists” and “logging satisfies AU.L2” is where most assessment findings originate.

What Counts as an Auditable Event

NIST SP 800-171 doesn’t hand you a universal list of events to log — it requires your organization to define that list based on your environment and risk. But in practice, across the defense industrial base, certain event categories show up in nearly every acceptable AU.L2 implementation:

• Authentication events, both successful and failed, across every system that touches CUI
• Privilege escalation and changes to user roles or group memberships
• Access to and modification of files or records containing CUI
• Changes to security configurations, firewall rules, or audit settings themselves
• System starts, stops, and reboots on servers and network devices in scope
• Account creation, deletion, and modification

The event list isn’t the hard part. The hard part is making sure the systems capturing those events actually record who did it, when, from where, and what the outcome was — the level of detail an investigator would need six months from now, not just a timestamp and a generic “event occurred” line. We’ve reviewed logging configurations that technically satisfied a checkbox but recorded so little context that reconstructing an incident timeline was functionally impossible. That’s a finding waiting to happen, and it’s the same failure mode we see recur in configuration management gaps — a control exists on paper but the operational reality doesn’t match the documentation.

Log Review Is a Requirement, Not an Aspiration

One of the most commonly missed pieces of AU.L2 isn’t generation — it’s review. NIST SP 800-171 requires that audit records be reviewed for indications of inappropriate or unusual activity, and that those reviews happen on a defined, repeatable cadence, not “whenever someone remembers to look.” An assessor isn’t just going to ask whether you have logs. They’re going to ask who reviews them, how often, what they’re looking for, and what happens when something suspicious turns up.

If your answer is “our MSP watches for alerts,” that can absolutely satisfy the requirement — but only if there’s a documented process behind it: defined thresholds, an escalation path, and evidence that reviews actually happened rather than a policy document asserting that they should. This is the exact same pattern we’ve flagged in incident response documentation — a policy statement describing what should happen is not evidence that it does happen. Assessors under the current assessment methodology are trained to ask for artifacts: review logs, ticket history, meeting notes, anything that proves the process is alive rather than theoretical.

Time Synchronization and Log Integrity

A detail that trips up more organizations than it should: audit records are only as trustworthy as the clock behind them. If your servers, workstations, network devices, and cloud tenants aren’t synchronized to a common, authoritative time source, correlating events across systems during an incident investigation becomes guesswork. NIST SP 800-171 requires that systems use internal clocks to generate timestamps for audit records and that those clocks be synchronized organization-wide.

Beyond timestamps, the integrity of the logs themselves matters. AU.L2 requires protection of audit information and audit logging tools from unauthorized access, modification, and deletion. If a local administrator on a compromised workstation can also clear that workstation’s event log, you’ve built a system where the attacker can erase the evidence of their own intrusion. That’s why centralized logging — shipping logs off the originating device to a separate, access-controlled repository — isn’t a nice-to-have architecture choice. It’s frequently the difference between a passing and failing AU.L2 posture. Organizations that have already invested in managed IT services with centralized monitoring tend to clear this bar without much additional work; organizations still running logging locally, device by device, almost never do.

So How Long Do You Actually Have to Keep Logs?

Here’s the part everyone wants a single number for, and here’s the honest answer: CMMC and NIST SP 800-171 do not specify a fixed retention period in days or years. What they require is that audit records be retained long enough to support after-the-fact investigations of security incidents and to meet regulatory and organizational information retention requirements. That’s intentionally flexible language, and it puts the burden on you to define and document a defensible period in your system security plan.

In practice, most defense contractors land on a 12-month online retention window with logs remaining searchable and immediately accessible, often paired with longer-term archival storage — sometimes two to three years — for records that may be needed for a delayed incident investigation, a legal hold, or a contract dispute. That longer window isn’t arbitrary. DFARS 252.204-7012 imposes its own preservation obligation: when a cyber incident affects covered defense information, contractors must preserve and protect images of affected systems and relevant monitoring and packet capture data for at least 90 days from the date of the report, and the government may request that data during an investigation. If your standard log rotation deletes records before that window closes, you’ve created a conflict between your IT operations and your contractual obligations — one that surfaces at the worst possible moment, mid-investigation, when the data you need has already aged out.

The practical takeaway: don’t try to find “the” CMMC retention number, because it doesn’t exist as a single figure. Instead, document a retention schedule that satisfies three things simultaneously — your own incident response needs, your DFARS flow-down obligations under DFARS 252.204-7012, and whatever your prime contractor’s flow-down clauses specify, since some primes impose stricter retention terms than the baseline federal requirement. Whatever number you land on, write it into your system security plan explicitly, and make sure your actual log storage configuration matches what the document says — a mismatch between stated policy and observed configuration is one of the fastest ways to turn a minor gap into a documented POA&M item during assessment.

Where Centralized Logging and SIEM Actually Pay Off

A surprising number of small and mid-sized defense contractors resist investing in a SIEM or centralized log management platform because it feels like enterprise-scale overhead for a company with fifty employees. But AU.L2 compliance without some form of aggregation becomes a manual, unsustainable burden — someone has to pull logs from a dozen different systems, correlate timestamps, and manually review activity across firewalls, endpoints, servers, and cloud tenants. That doesn’t scale, and it doesn’t survive turnover when the one person who understood the process leaves.

A properly configured SIEM does three things that matter directly for AU.L2: it centralizes collection so logs from disparate systems land in one access-controlled location, it applies correlation rules that surface the “unusual activity” reviews require without a human manually cross-referencing five different consoles, and it enforces retention automatically rather than relying on someone remembering not to let storage auto-purge records early. This is exactly the kind of infrastructure conversation that belongs in a broader cybersecurity strategy rather than being bolted on separately, and it’s often where cloud transformation planning and compliance planning intersect — moving workloads to platforms with built-in, exportable audit logging (Microsoft 365, Azure, AWS CloudTrail) can significantly reduce the lift compared to trying to retrofit logging onto aging on-premises infrastructure.

If your environment already runs on Microsoft 365, the distinction between GCC and GCC High matters here too — audit log retention defaults and export capabilities differ meaningfully between the two environments, which is a large part of why that decision deserves more scrutiny than most contractors give it upfront.

The Failure Points We See Most Often in Assessments

Across readiness assessments and mock C3PAO run-throughs, the same handful of AU.L2 gaps show up repeatedly:

• Logs exist but retention is set by a default configuration nobody reviewed, often 30 or 90 days, well short of what’s defensible
• Log review is described in policy but there’s no artifact — no ticket, no email, no dashboard export — proving reviews actually happen on schedule
• Time synchronization isn’t enforced organization-wide, so correlating events across systems produces conflicting timelines
• Local administrators can clear or modify logs on their own endpoints, meaning the audit trail isn’t tamper-resistant
• The system security plan states a retention period that doesn’t match what the logging platform is actually configured to keep

Every one of these is fixable, and none of them requires exotic tooling. What they require is someone actually walking through the AU family control by control, comparing the documented policy against the live configuration, and closing the gap before an assessor finds it instead. This is the same discipline that shows up across every domain in a mature compliance program — the gap between what’s written and what’s configured is almost always where findings live, not in some exotic missing control nobody thought of.

Building a Program That Survives the Assessment, Not Just the Audit Prep

The organizations that pass AU.L2 cleanly on the first attempt tend to share a pattern: they didn’t treat audit logging as a document exercise done in the weeks before assessment. They built it as an operating process — a defined event list, centralized collection, a documented and enforced retention schedule, a recurring review cadence with evidence, and clock synchronization baked into the network standard. That’s infrastructure and discipline working together, and it’s rarely something an internal IT team of one or two people can sustain alongside their day-to-day support load.

This is where a vCIO relationship earns its keep — someone whose job includes stepping back from the day-to-day ticket queue to ask whether the logging architecture, retention policy, and review process actually align with what the SSP claims, and whether that alignment will hold up under an assessor’s questions. It’s also where co-managed IT arrangements make sense for contractors with an internal team that needs augmentation on the compliance-specific pieces without handing over the whole environment. Manufacturing and engineering firms in particular — heavy on CAD systems, PLM platforms, and OT-adjacent networks — tend to have the widest variety of log sources and the least standardization across them, which makes centralization a bigger lift but also a bigger payoff once it’s done. If that sounds like your environment, it’s worth reading how we approach it for manufacturing and engineering clients specifically.

Backup and log retention also intersect more than people expect. If your backup and data recovery strategy already includes long-term archival storage, extending that same architecture to audit log archives is often a lighter lift than standing up a separate retention system from scratch — the storage, encryption, and access control requirements overlap significantly.

And none of this happens in isolation from the rest of your CMMC posture. Weak audit logging tends to travel with weak incident response, because you can’t investigate what you can’t reconstruct, and it tends to travel with unclear MSP responsibility boundaries — a point we’ve covered in detail when it comes to what an MSP serving defense contractors is actually contractually on the hook for versus what stays with the contractor. If your logging program is thin, it’s worth asking the same question about your SPRS score — AU family gaps are a common and often underestimated point deduction.

What Assessors Are Actually Verifying

Under the assessment methodology laid out alongside the DoD CMMC Program, an assessor working through the AU domain isn’t just checking a box that says logging exists. The assessment objectives derived from NIST SP 800-171 and detailed further in the assessment procedures of NIST SP 800-171A require evidence — configuration screenshots, sample log exports, review artifacts, retention policy documents that match observed system settings. An assessor who asks to see 90 days of authentication logs and finds that your system only retains 30 has just found a gap regardless of what your policy document claims.

This is also where CISA’s cybersecurity resources are worth reviewing independently of CMMC itself — much of their guidance on logging best practices for critical infrastructure and federal contractors overlaps directly with what AU.L2 expects, and it’s a useful sanity check when you’re trying to decide whether your event list and retention schedule are actually adequate rather than just technically compliant.

Conclusion

Audit logging under CMMC isn’t about flipping a switch and hoping the defaults hold up. It’s a system of decisions — what to log, how long to keep it, who reviews it, and how you prove any of that actually happens rather than just exists on paper. Get the retention schedule wrong, or leave it undocumented, and you’ve built a gap that surfaces at the worst possible time: mid-assessment, or worse, mid-investigation after an actual incident. Get it right, and audit logging becomes one of the more straightforward domains to defend, because the evidence either exists or it doesn’t.

If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.