CMMC Audit and Accountability: The Evidence an Assessor Expects to See

This week Smithers published a C3PAO's view of assessments. It points out that every assessment is led by Certified CMMC Assessors who have finished formal training, passed exams and cleared background checks. Those assessors work from the NIST SP 800-171A assessment objectives. The nine AU requirements at Level 2 produce evidence that is easy to check live, so a gap here is hard to talk your way past.

Which Audit and Accountability requirements apply at CMMC Level 2?

Level 1 has no AU practices. Its 15 requirements come from FAR 52.204-21, and audit logging isn't one of them. The AU domain starts at Level 2 and follows NIST SP 800-171 Revision 2, section 3.3:

• AU.L2-3.3.1 System Auditing: create and keep audit logs and records so unlawful or unauthorized activity can be monitored, analyzed, investigated and reported.
• AU.L2-3.3.2 User Accountability: make sure each user's actions can be traced to that specific user.
• AU.L2-3.3.3 Event Review: review and update the list of events you log.
• AU.L2-3.3.4 Audit Failure Alerting: send an alert when the audit logging process fails.
• AU.L2-3.3.5 Audit Correlation: link the review, analysis and reporting of audit records so you can investigate and respond to suspicious activity.
• AU.L2-3.3.6 Reduction and Reporting: be able to filter audit records and produce reports on demand.
• AU.L2-3.3.7 Authoritative Time Source: compare and sync internal system clocks with an authoritative source so audit record time stamps are accurate.
• AU.L2-3.3.8 Audit Protection: protect audit information and logging tools from unauthorized access, modification and deletion.
• AU.L2-3.3.9 Audit Management: let only a defined subset of privileged users manage audit logging.

How does an assessor decide whether an AU requirement is met?

NIST SP 800-171A splits each requirement into lettered assessment objectives. The assessor scores each requirement MET or NOT MET (or not applicable, where justified). A requirement only counts as MET when every objective under it is satisfied. The assessor gathers evidence in three ways: examining documents and records, interviewing the people who do the work, and testing the mechanisms themselves.

For AU, those three methods usually look for three layers of evidence:

1. A documented decision. This is your System Security Plan (CA.L2-3.12.4) plus supporting procedures that state which events you log, what each record contains, how long you keep records, who reviews them and how often.
2. A configuration that carries out that decision. Examples are audit policy settings, log forwarding rules, time sync settings and permissions on the log store.
3. Records showing it happened. Examples are actual log entries, completed reviews, alerts that fired and reports someone produced.

Most AU findings happen when one of these layers doesn't match the others. A typical case is a policy that says logs are reviewed weekly when there is no record of any weekly review. 32 CFR Part 170 also requires you to keep the artifacts you used as assessment evidence for six years from the assessment date, so pull together your AU evidence knowing it has to last that long.

What evidence proves AU.L2-3.3.1 and AU.L2-3.3.2 are met?

AU.L2-3.3.1 has six objectives, and they come in pairs. You define the event types to log, then show they are actually logged. You define what each record must contain, then show records contain it. You define retention, then show you are meeting it. Strong evidence includes:

• A written list of event types tied to your CUI environment, such as logons, privilege use, account changes, access to CUI repositories and security tool events.
• A defined record format covering at least what happened, when, where, the source, the outcome and the identity involved.
• Sample log entries from in-scope systems that contain those fields.
• A written retention period, plus a demonstration that records as old as that period can still be retrieved.

AU.L2-3.3.2 depends on unique identification. An assessor will look for shared or generic accounts. If they find one, they will ask how actions taken through it trace to a specific person. This links directly to IA.L2-3.5.1, which requires you to identify system users, processes acting on their behalf and devices. Service accounts should have a named owner. Administrative actions should show up in logs under an individual's own credentials.

How do you show logs are reviewed, alerted on and correlated?

Collecting logs nobody reads doesn't meet the review, alerting and correlation requirements. To satisfy AU.L2-3.3.3, you need a defined process for when logged event types get reviewed. You also need evidence that the review took place and that the list of event types changed when the review found a reason to change it. Dated review records, tickets or change records that show the logging configuration being updated are the kind of artifacts that work.

AU.L2-3.3.4 calls for three things: named people or roles who receive the alert, defined types of logging failure that trigger it, and proof the alert actually reaches those people. One persuasive way to show this is to stop a log source or agent in a controlled test and show the resulting alert.

AU.L2-3.3.5 and AU.L2-3.3.6 are usually tested live. Expect the assessor to ask you to trace one user's activity across several systems, or to run a filtered report on the spot. Saved queries, report templates and a central place where records from different sources can be searched together are the practical evidence for both requirements.

How do you prove time synchronization and log protection?

For AU.L2-3.3.7, write down the authoritative time source you have chosen. Then show the settings that point your systems at it and an in-scope system that is actually synced. Clocks that drift make correlation across systems unreliable, so the assessor may check this requirement alongside AU.L2-3.3.5.

For AU.L2-3.3.8, the assessor checks six objectives: audit information is protected from unauthorized access, modification and deletion, and so are the logging tools. Useful evidence includes access control settings on the log store, settings that stop local administrators from clearing or changing forwarded records, and a list of who can reach the logging tools.

AU.L2-3.3.9 asks you to define the small group of privileged users who can manage logging, and then show that only that group can. A role assignment export compared against your documented list does the job. It also supports least privilege under AC.L2-3.1.5. An assessor will notice if every domain administrator can also turn off auditing.

Does the Phase 2 pause change what you need for Audit and Accountability?

No. The requirements and assessment objectives above are the same whatever the phase schedule, and an assessor applies them the same way in every Level 2 assessment. What is still undecided while Phase 2 is suspended is the timing: when C3PAO certification becomes a contract condition across more solicitations. No one can give a firm date for that right now. Since logging only produces evidence from the day it starts, the history your logs build up is part of what an assessor will examine.

Frequently Asked Questions

Sources

• NIST SP 800-171 Revision 2 (nvlpubs.nist.gov)
• NIST SP 800-171A, Assessing Security Requirements for CUI (nvlpubs.nist.gov)
• 32 CFR Part 170, CMMC Program (ecfr.gov)
• FAR 52.204-21 (acquisition.gov)
• DoD CIO CMMC Resources and Documentation (dodcio.defense.gov)
• Smithers, What to Expect During a CMMC Assessment: A C3PAO's Perspective (smithers.com)