Every commercial aircraft carries a flight data recorder. Nobody looks at it on a normal flight. It only matters the moment something goes wrong, and at that point it’s the difference between knowing exactly what happened and guessing. Your CUI environment needs the same thing: a continuous, reliable record of activity that nobody checks day to day but that had better be there, intact and readable, the moment you actually need it.
That’s what this nugget covers: seven controls from the Audit and Accountability (AU) family (the other two, AU.L2-3.3.7 and AU.L2-3.3.9, were already covered in Nuggets #11 and #19) plus two controls from System and Information Integrity (SI) that work alongside them to catch problems in near real time rather than after the fact (a third, SI.L2-3.14.7, was already covered in Nugget #6).
Building the Flight Recorder (AU Controls)
AU.L2-3.3.1: Create and retain system audit logs and records
The foundation. Logs need to capture enough detail to support monitoring, investigation, and reporting of unauthorized activity, and they need to be retained, not just generated and immediately overwritten. A common baseline organizations use is 90 days of readily accessible online storage plus at least a year of archived logs, though your specific retention requirement should be defined in policy and tied to your incident response and investigative needs, not picked arbitrarily.
AU.L2-3.3.2: Ensure that the actions of individual system users can be uniquely traced to those users
Logs are only useful for accountability if every action ties back to an individual, not a shared service account or a generic “admin” login that five different people use.
AU.L2-3.3.3: Review and update logged events
Here’s a correction worth making: this control is about periodically reviewing and updating which event types your systems are configured to log, not about maintaining the integrity of the records themselves once they’re created. Are you still logging the right things as your environment changes? New systems, new applications, new risk areas may all need their own logging coverage that wasn’t relevant a year ago. (Integrity protection of the logs themselves is further down in 3.3.8)
AU.L2-3.3.4: Alert in the event of an audit logging process failure
If your logging silently stops working, you won’t know you’re flying blind until you need the recording that isn’t there. This requires active alerting, not a dashboard someone might glance at eventually.
AU.L2-3.3.5: Correlate audit record review, analysis, and reporting processes for investigation and response
This is more than “we have logs from different systems.” Assessors expect to see actual correlation capability, commonly implemented via a SIEM (Security Information and Event Management) platform, that pulls logs from multiple sources together so patterns and suspicious activity across your environment become visible, not just visible within each individual system in isolation.
AU.L2-3.3.6: Provide audit record reduction and report generation
The practical side of having a mountain of logs: an automated capability that filters, summarizes, and generates reports on demand so analysts aren’t manually combing through raw data during an investigation. Reduction extracts what’s meaningful without touching the underlying records; keeping those records safe from tampering is a separate job, handled by AU.L2-3.3.8 next.
AU.L2-3.3.8: Protect audit information and audit logging tools from unauthorized access, modification, and deletion
This is where log integrity actually lives. If someone can edit or delete the record after the fact, you don’t have a reliable flight recorder, you have a suggestion box. Access to logs and logging infrastructure should be tightly restricted, and AU.L2-3.3.9 (Nugget #19) is what governs exactly who’s allowed to manage that logging functionality in the first place.
Watching for Trouble in Real Time (SI Controls)
SI.L2-3.14.3: Monitor system security alerts and advisories and take action in response
Staying current on vendor security bulletins, CVE advisories, and threat intelligence relevant to your environment, and actually acting on them, not just receiving them.
SI.L2-3.14.6: Monitor organizational systems to detect attacks and indicators of potential attacks
Active, ongoing monitoring for signs of compromise, not a once-a-quarter check-in. This is where your AU logging and your SI monitoring meet: the logs are the raw material, this control is the active watching.
Common Failures Across This Control Set
AU.L2-3.3.4 Logging failure alerts not configured; outages go unnoticed
AU.L2-3.3.5 Logs collected from multiple systems but never actually correlated (no SIEM or equivalent)
AU.L2-3.3.6 Reduction/reporting capability exists but can’t be produced on demand, or doesn’t cover all in-scope log sources
SI.L2-3.14.3 Security advisories received but no documented process for acting on them
SSP Mapping Note
The AU and SI controls in this nugget are separate families and belong in separate SSP sections, even though they’re discussed together here because they function as a system. Don’t combine them into a single “monitoring” section; assessors expect to see them mapped to their correct families with their own assessment objectives addressed individually.
For each control your SSP should document:
- The specific technical implementation (SIEM platform, NTP source, retention configuration, etc.)
- The policy governing retention periods, review cadence, and alert response procedures
- Who is responsible for reviewing logs and responding to alerts
- How compliance is verified and how often
A flight recorder nobody maintains isn’t a safety feature, it’s just expensive cargo. Get these seven AU controls and two SI controls working together and you’ve actually got situational awareness, not just a pile of logs waiting to disappoint you during an investigation. Send questions to DTC’s C3PAO team; we’d rather help you check the recorder now than read it with you later.