Mastering NIST SP 800-171 Audit and Accountability (AU) Controls

Eric Marquette

Alright, welcome back to CMMC Unlocked. I’m Eric Marquette, here with Paul Netopski and Roz the Rulemaker. We’re going deep into the Audit and Accountability, or AU, controls in NIST SP 800-171 today—so if you’re in defense contracting or handling CUI, this is the episode for you.

Roz the Rulemaker

Audit and Accountability is a foundational domain, right? The whole AU family is really about making sure you don’t just have security controls in theory, but you’ve got a way to prove it—or to find out when something goes sideways. If you can’t create and retain effective audit logs, there’s no real way to monitor, analyze, or investigate suspicious activity. You’re essentially flying blind, from a regulatory and legal standpoint.

Paul Netopski

Exactly, Roz. And that lens—proving what happened and holding people accountable—drives the entire AU family. The controls here aren’t just about logging for the sake of logging. They answer core compliance questions: What happened? Who did it? When? Can you look back and see if there was any unlawful or unauthorized activity? And, just as important, can you spot it in time to respond?

Eric Marquette

I get a lot of folks asking me, like, “Eric, is logging really that important if you never actually have a breach?” The answer, every single time, is "yes." Logs are as much for building trust and accountability as they are for catching the bad guys in the act. Paul, didn’t you have a real-world story on this from your Navy days?

Paul Netopski

Yeah, sure do. It wasn’t a sophisticated attack either—just a case of someone accessing something they shouldn’t’ve. But our audit logs at the time were barely there. We didn't have the right event types logged, the content was vague, and retention? Let's say, not defined. That meant when we were trying to investigate, the trail went cold. Days lost just piecing things together from scraps instead of having everything right in front of us. I always come back to this: if you don’t take audit records seriously and set those requirements up properly, you’re risking downtime, missed accountability, and compliance penalties down the line.

Roz the Rulemaker

That’s the crux of it! And now, CMMC actually requires you to define not just what you log, but how long you keep it, who watches over it, and how you use it—no more vague "log everything" but never check or manage it.

Eric Marquette

Alright, let’s start picking those AU requirements apart one by one because there are some tricky nuances here. Paul, wanna kick off the breakdown?

Paul Netopski

Sure thing. Let’s walk through the requirements—AU.L2-3.3.1 through AU.L2-3.3.9—because each one layers on the next to build a complete picture. Start with 3.3.1, which is basically, “Create and retain those system audit logs.” You gotta specify what event types are needed—think login attempts, file access, permission changes. Then, you define the content you need: who did what, when, and where. And it’s all gotta be generated and stored according to your retention policy.

Eric Marquette

Right, and then you move into traceability, which—remind me, that’s 3.3.2, right? Ensuring the actions of individual users can be traced back to them. I always tell clients: it’s not enough to know someone modified a file, you’ve gotta know which user account did it, and whether that’s tied to a real person.

Roz the Rulemaker

Absolutely. It’s much like public comment tracking in administrative law—every comment, every revision has to be attributed for future accountability. If you just track “changes made,” with no author, you lose the trail. In regulatory work, that’s a nonstarter. In cyber, it’s a compliance violation and a security risk.

Paul Netopski

Moving on to 3.3.3, this one often gets overlooked: you have to review and update which event types you log. The threat landscape changes, your systems evolve, so it can’t just be a set-it-and-forget-it approach. Regular reviews are a requirement, not a nice-to-have.

Eric Marquette

And when you hit 3.3.4, now you’re talking about alerting on audit logging failures. So, if your audit process stops logging events, or the storage fills up, someone’s got to get an alert. I always say: “If no one knows it broke, you’re not compliant.” And I see this all the time—where logging stalls out and nobody notices for weeks.

Roz the Rulemaker

3.3.5 is interesting. It’s about correlating review, analysis, and reporting, not just doing things in silos. You have to bring this information together for investigation and response, similar to how, in regulatory processes, we correlate public input, legal guidance, and impact assessments for a full view.

Paul Netopski

Exactly—and for 3.3.6, you’ve gotta support audit record reduction and on-demand report generation. This is mostly for the analysts—so they aren’t buried in gigabytes of log data but can distill what matters and respond quickly.

Eric Marquette

Then you hit timestamps—3.3.7. You need to generate and synchronize timestamps with an authoritative source, otherwise correlating events across systems falls apart. Log data’s only as good as its clock, right?

Paul Netopski

And then, for the last two—3.3.8 and 3.3.9—protect your audit info and tools from unauthorized tinkering, and only allow a defined, limited group of privileged users to manage those logging functions. Least privilege is the name of the game; you don’t want everyone in IT having the keys to change, delete, or view sensitive log data.

Roz the Rulemaker

And just like in rulemaking, if you don’t sharply limit who can modify the record or process, you risk both accidental and intentional noncompliance. That’s why codifying controls—whether for regulations or audit logs—matters so much.

Eric Marquette

Let’s get practical—what are people actually using to meet these controls? There are a ton of open-source solutions, right? One that stands out for me is FAT Forensics. Now, that’s a Python library that focuses on fairness, accountability, and transparency—mostly in predictive systems and machine learning settings, but the accountability part totally carries over to system logging.

Paul Netopski

Yeah, FAT Forensics is great for accountability reviews—automating the process of checking what’s being logged, how the logging pipelines work, and ensuring transparency in how decisions are made by algorithms. Of course, for “regular” audit logs, a lot of folks in defense use the ELK Stack—Elasticsearch, Logstash, Kibana—for aggregation, searching, visualization, and correlation. Also, Wazuh is really popular because it’s open-source, and you can set it up to hit almost all the AU controls pretty easily.

Roz the Rulemaker

I always encourage organizations: don’t default to some monolithic, expensive solution if you don’t have to. The important criteria are: does it allow granular collection and retention, can you generate on-demand reports for regulatory review, and can you subset or redact logs for privacy or compliance? Especially important for smaller contractors with lean resources.

Eric Marquette

Speaking of resource-lean, when we were rolling out Jellypod, we actually started out with Wazuh. It was super low-overhead for the IT folks and let us check the compliance boxes around log creation, retention, and reporting with minimal manual intervention. If you’re just getting started, open-source might get you 80% of the way there for free—as long as you configure it right.

Paul Netopski

Just make sure you’re picking based on compliance fit, not just features. Does your environment require integration with SIEMs, alerting tools, or ticketing systems? Are you supporting on-demand reduction and reporting per 3.3.6? Always run through your actual requirements.

Eric Marquette

Alright, so, let’s shift to managed security service providers—the MSSPs. A lot of contractors figure, “Let’s just hand off the audit logging stuff to an MSSP and cross it off the list.” But that’s, uh, not exactly cyber best practice unless you spell out the requirements.

Paul Netopski

Yeah, that’s the thing—I see plenty of cases where people think they can fully offload compliance. But you can’t outsource accountability, you can only delegate parts of it. MSSPs can seriously help with centralized log management, alerting on failures, correlating and analyzing logs, even automating a lot of the reporting. But you have to define the ground rules. I put together a checklist for vetting MSSPs. It covers: Do they define SLAs for log retention? Is there a commitment to alert on failures and generate notifications in real-time? Who’s allowed to review or manage privileged access? If you get those answers in writing, you reduce your risk.

Roz the Rulemaker

It comes down to transparency, due diligence, and ongoing verification. When you’re outsourcing, always ask: How will the MSSP demonstrate compliance? How can you independently review evidence or pull records in the event of an audit? Are you still limiting privileged access appropriately, or does the MSSP have a thousand admins? And do they protect the data and tools from unauthorized access, as required by 3.3.8?

Eric Marquette

And don’t forget, even with a great provider, the responsibility to produce evidence for an assessment still falls to you. Ask for sample reporting, review how ticket escalation and incident notification will work, and check how quickly you’ll get data when needed. Otherwise, all that outsourcing can give a false sense of security.

Paul Netopski

Right—and there’s nothing worse than failing an audit because the logs are locked up in someone else’s system, or worse, deleted before you could pull them. Always clarify retention periods and incident response SLAs up front.

Eric Marquette

Let’s bring this home by talking future-proofing. AU isn’t a "set it and forget it" domain. You have to periodically review and adjust which events you’re logging—per 3.3.3—and keep up as NIST standards evolve. Rev. 2 is effective now, but Rev. 3 is coming. So, you gotta be agile.

Roz the Rulemaker

The most effective compliance programs I’ve seen set a recurring review cycle, at least annually, and document any changes—what events are logged, how retention is managed, and how audit tools are protected. That aligns both with legal due diligence and technical best practice. If you do that, you're covered whether NIST tweaks something or a regulator comes knocking.

Paul Netopski

And don’t overlook documentation—define those retention periods, limit who can manage the logging functionality, and make sure you actually protect the logging tools from tampering or unauthorized access. That’s straight out of 3.3.8 and 3.3.9. Plus, in every assessment I’ve done, if the log review process isn’t clear and periodic, it gets flagged. It’s low-hanging fruit for auditors.

Eric Marquette

Sounds like what we covered on policies and continual improvement in past episodes. It all ties together—incident response, access control, monitoring, it’s a cycle. You can’t get lazy and expect to stay compliant or secure.

Roz the Rulemaker

Exactly. Whether you’re building a new program or updating an old one, put those cycles on the calendar—legal, technical, procedural. Compliance is as much about keeping processes alive as it is about documentation.

Paul Netopski

So, the big takeaways: review and update, document everything, check your retention, protect the tools, and always keep a short list for privileged log managers. Stay proactive, and you’ll stay ahead.

Eric Marquette

Alright, that’s a wrap for today’s dive into AU controls. Thanks so much, Paul and Roz, for sharing your experience and strategies. We hope everyone listening picked up something useful for their compliance journey.

Roz the Rulemaker

Always a pleasure. Keep iterating, keep documenting, and keep those logs alive.

Paul Netopski

Absolutely, thanks Eric, thanks Roz. Catch you all next time—let’s keep the mission moving forward.

Eric Marquette

We’ll be back soon with more insights. Until then, stay secure and stay compliant. Bye for now.