7.1 Audit & Accountability (AU) Domain: Logging, Review & Non-Repudiation

Audit & Accountability: Events, Attribution, Time & Protection

Audit and Accountability contains nine Level 2 requirements and no Level 1 mappings. The family makes system activity available for monitoring, investigation, and accountability. It does not prescribe one SIEM, log schema, event catalog, retention period, or staffing model.

Create the records that the purpose requires

Requirement 3.3.1 creates and retains system audit logs and records to the extent needed to enable monitoring, analysis, investigation, and reporting of unlawful or unauthorized activity. The organization identifies relevant systems and events based on its architecture, risk, contract, and objectives. Authentication, privilege, configuration, data access, boundary, security-tool, and administrative events are common candidates, but the published requirement does not declare a universal list.

Evidence should connect policy and event-selection decisions to enabled settings and actual records. A long retention statement does not help if critical sources never generate or forward events. Conversely, an assessor should not invent a fixed one-year retention period when no governing source in the scenario requires it.

Requirement 3.3.2 ensures individual system-user actions can be uniquely traced to those users. Generic shared administrator credentials with no individual checkout or session attribution undermine the objective. A controlled privileged-access mechanism may support a shared technical function if it reliably records the individual responsible. The assessment tests attribution, not account-label folklore.

Review, failure, correlation, and reporting

Requirement 3.3.3 reviews and updates the events being logged. This keeps event selection aligned with system and threat changes. 3.3.4 alerts when an audit-logging process fails. Failure can involve disabled collection, storage exhaustion, forwarding interruption, agent error, or another condition relevant to the design.

Requirement 3.3.5 correlates audit-record review, analysis, and reporting to investigate and respond to indications of unlawful, unauthorized, suspicious, or unusual activity. 3.3.6 provides audit-record reduction and report generation for on-demand analysis and reporting. A SIEM can provide these capabilities, but native tools, scripts, or other controlled mechanisms may also work.

A dashboard screenshot is not enough by itself. The team can examine source coverage and rules, interview analysts, trace a representative event through collection and correlation, generate a report, and test a logging-failure alert when safe and appropriate.

Time synchronization

Requirement 3.3.7 provides a system capability that compares and synchronizes internal system clocks with an authoritative source to generate audit-record timestamps. The organization chooses the authoritative source and architecture. Internal time tiers, authenticated sources, domain services, appliances, or other mechanisms may be appropriate.

The objective is reliable comparison and synchronization across the evidence chain. It does not require every device to contact the same public NTP server. Assessors should evaluate source authority, configuration, drift, time zones or normalization, failure behavior, and representative timestamps.

Protect logs and limit logging management

Requirement 3.3.8 protects audit information and audit-logging tools from unauthorized access, modification, and deletion. Access controls, write protection, centralized copies, integrity checks, backups, and monitoring are potential safeguards. The team verifies effective permissions and data paths rather than assuming central storage is immutable.

Requirement 3.3.9 limits management of audit-logging functionality to a subset of privileged users. “Subset” matters: not every privileged user should automatically be able to change what is logged. The requirement does not say that only employees with a dedicated auditor job title may administer a SIEM, nor does it automatically prohibit all system administrators from every audit-related action. The organization defines and enforces authorized logging-management roles.

Evidence sequence

1. Inventory systems and audit sources in the CMMC Assessment Scope.
2. Trace selected events to the purpose in 3.3.1 and review records for 3.3.3.
3. Verify user attribution under 3.3.2.
4. Evaluate failure alerts, correlation, reduction, and reports under 3.3.4–3.3.6.
5. Compare timestamps and authoritative-source configuration under 3.3.7.
6. Inspect access, modification, deletion, and logging-management roles under 3.3.8–3.3.9.

A technically rich log program can still fail if users are not attributable or logging administrators can silently disable sources without control. A small environment can satisfy the objectives with proportionate tooling when the complete evidence chain operates.

Reconciliation example

If a privileged change appears in a firewall log but the identity platform records only a generic account, correlate the privileged-access checkout, session record, ticket, and timestamps. The result may establish the responsible individual—or reveal that traceability is missing. Likewise, if a logging agent stopped for six hours, compare the local source, failure alert, collection gap, response ticket, and restored event flow. This cross-source method evaluates 3.3.2, 3.3.4, 3.3.5, and time consistency without assuming that a polished SIEM dashboard proves them.