3.3 AU
797 paragraphs across eight sections. Here is the structure and the design decisions that carry the most weight in this family.
Document structure
Section 3 — the log source inventory is the operational centrepiece, covering four tiers of log sources across 20 individual source types. It is split by priority: identity and authentication sources (Critical — these must be forwarding before any AU control can be considered implemented), network boundary sources (Critical), endpoint and server sources (High), and application and data access sources (Medium-High). Each source entry specifies the required event categories, the forwarding mechanism, and an expected daily volume indicator — that volume indicator is what the SIEM health monitoring uses to detect when a source goes silent versus when it legitimately generates no events.
Section 4 — the SIEM configuration specification contains three sub-sections that are more operationally specific than most ISMS documentation produces. The core settings table (4A) defines the retention tiers, tamper evidence configuration, access control settings, and health monitoring requirements with enough specificity that an engineer can configure any SIEM platform against it. The log review procedure (4B) is a seven-step structured procedure that produces EV-F01 — it specifies exactly what each step should document, ensuring review records contain actual content rather than being templated placeholders. The SIEM health report specification (4C) defines what EV-F06 must contain and which control each component satisfies.
The separation of EV-F01 and EV-F06 into two distinct evidence items is a deliberate architectural decision. EV-F01 answers "what did we find in the logs this month?" EV-F06 answers "was the audit infrastructure capable of producing reliable logs this month?" Both questions must be answerable independently. This distinction directly addresses finding six in the common findings section.
The two evidence items that define AU family readiness
Before any external assessment, these two items must exist for every month in the assessment period:
EV-F01 (monthly log review records) is the document most closely scrutinised in AU family assessments. Assessors will take the past three months of EV-F01 records and work through them systematically: is there a named analyst for each review? Do the alert counts match the SIEM export they can pull live? Are there unexplained gaps between alerts found and alerts dispositioned? Does the record show what was reviewed rather than just asserting that everything was clean? A review record that takes 10 minutes to produce and says "no anomalies" for every single month will be challenged — not because anomalies are guaranteed but because a thorough review should identify at least some items requiring disposition, even if they are all false positives.
EV-F06 (SIEM health reports) is the second item that most organisations discover they are missing only when asked for it. It is not enough to run a SIEM — the SIEM must be demonstrably healthy. The log source status table (every expected source, with last event timestamp and status) is the evidence that the scope of logging is maintained month to month. The retention verification (confirming that logs from 11 months ago are still retrievable) is the evidence that retention settings are working as configured, not just as documented. The hash verification of archived logs is the evidence that log integrity is preserved over the full retention period.
Why 12 months retention and where it comes from
The document specifies 12 months hot/warm retention plus 24 months archive (36 months total). The NIST 800-171 control text says "to the extent needed to enable monitoring, analysis, investigation, and reporting." It does not name a specific number. The 12-month minimum comes from the NCSC guidance for UK organisations on log retention for incident investigation, which notes that many advanced persistent threats (APTs) establish persistence months before being detected — logs that go back only 90 days cannot support investigation of a compromise that began six months ago.
The 36-month total retention is driven by the CMMC assessment cycle: a CMMC Level 2 assessment covers a three-year period, and assessors can request any log from within that period as evidence. An organisation that retains logs for only 12 months cannot respond to an evidence request for an event that occurred 18 months ago. The three-tier retention architecture (hot, warm, archive) in section 4A keeps costs manageable while satisfying the full 36-month window.
Clock synchronisation — the control that enables every other control
Control 3.3.7 appears simple (synchronise clocks with NTP) and is often treated as low-priority. It is not. Every other AU control depends on trustworthy timestamps. A SIEM that receives logs with inconsistent or drifted timestamps cannot reliably correlate events across systems, cannot establish reliable event timelines for incident investigation, and cannot produce the "system capability for comparing and auditing user activity" that 3.3.7 specifically requires.
The SIEM clock offset alert described in the 3.3.7 implementation — alerting if any log source's timestamp deviates more than 60 seconds from UTC — provides continuous monitoring of clock health between the quarterly configuration audits. This is the difference between discovering a 15-minute clock drift at the quarterly audit (after three months of potentially uncorrelatable logs) and discovering it within an hour of the drift developing.
Cross-linking in Confluence
The AT-AU page has more upstream dependencies than any other family in the library, because every other family's evidence depends on AU's logging infrastructure working correctly.
Link to AT-SI (the attack detection controls in 3.14.6 and 3.14.7 — those SIEM correlation rules for attack detection are specified in AT-SI but run on the AU-maintained SIEM infrastructure). Link to AT-AC (the access control reviews in EV-D01 extend to SIEM role holders — the quarterly privileged account review covers both AD admin roles and SIEM admin roles). Link to AT-IA (the authentication logs from Entra ID and Active Directory are the highest-volume and highest-value AU log sources — the identity platform configuration in AT-IA determines what events are available to log). Link to AT-SC-BDY (the firewall and IDS/IPS in that family are two of the Critical-priority log sources in the AU inventory). And link to AT-CM (any change to SIEM configuration — adding a log source, changing retention, modifying alert rules — must pass through the change management process defined in AT-CM 3.4.3, with a security impact assessment as required by 3.4.4).
Updated library status
Nine of the fourteen family pages are now complete:
| Page | Controls | CMMC L1 |
|---|---|---|
| AT-AC · Access Control | 22 | 4 |
| AT-AT · Awareness and Training | 3 | 0 |
| AT-AU · Audit and Accountability | 9 | 0 |
| AT-CM · Configuration Management | 9 | 0 |
| AT-IA · Identification and Authentication | 11 | 2 |
| AT-MP · Media Protection | 9 | 1 |
| AT-SC · System and Comms Protection | 16 | 2 |
| AT-SI · System and Info Integrity | 7 | 4 |
| AT-AU · Awareness and Training | 3 | 0 |
Five families remain: AT-IR (Incident Response, 3 controls), AT-MA (Maintenance, 6 controls), AT-PE (Physical Protection, 6 controls), AT-PS (Personnel Security, 2 controls), AT-RA (Risk Assessment, 3 controls), and AT-CA (Security Assessment, 4 controls — the SSP master document that references every other family page).