CMMC Audit Log Requirements: What to Capture, Keep and Review (3.3.1 to 3.3.9)

CMMC audit log requirements are the nine requirements in the Audit and Accountability family of NIST SP 800-171 Rev 2, numbered 3.3.1 to 3.3.9. In short: decide which events you log and what each record contains, keep those records for a period you define, review them on a schedule, make sure every action traces to one named person, sync your clocks, protect the logs, and let only a few administrators change the logging settings.

The rule does not hand you a list of events or a retention number. It asks you to define both, write them down, and then prove you follow your own definitions. That is good news for a small shop: you get to set the bar, as long as it is reasonable and you can show the records. This post covers each requirement, what the assessment objectives in NIST SP 800-171A check, and a setup a 10 person company can run without a security team.

Why audit logs matter for your SPRS score

Three of the nine requirements carry most of the weight in the DoD Assessment Methodology used for your Supplier Performance Risk System (SPRS) score.

Requirement	Plain English	SPRS points
3.3.1	Create and keep audit logs good enough to investigate unauthorized activity	5
3.3.2	Every logged action traces to one individual user	3
3.3.3	Review and update the list of logged events	1
3.3.4	Alert someone when logging fails	1
3.3.5	Correlate review, analysis and reporting across log sources	5
3.3.6	Be able to filter logs and produce reports on demand	1
3.3.7	Sync system clocks to an authoritative time source	1
3.3.8	Protect logs and logging tools from access, change and deletion	1
3.3.9	Limit who can manage logging to a few privileged users	1

That is 18 points in one family, and 13 of them sit in 3.3.1, 3.3.2 and 3.3.5. Under 32 CFR 170.21, requirements worth more than 1 point cannot be left on a plan of action and milestones (POA&M) for a conditional Level 2 status, so these three need to be met, not planned. Our post on the 5-point controls explains why fixing those first moves your score fastest. You can see the effect on your own number with the free SPRS calculator.

3.3.1: What to capture

The requirement reads: create and retain system audit logs and records to the extent needed to enable the monitoring, analysis, investigation, and reporting of unlawful or unauthorized system activity. 800-171A breaks it into six objectives. You must specify the event types you log [a], define the content of each record [b], actually generate the records [c], show the records contain that content [d], define a retention requirement [e], and keep records as defined [f].

For a small shop the event list does not need to be long. A defensible starting list for the systems that hold controlled unclassified information (CUI):

• Sign-ins, successful and failed, including multifactor prompts and lockouts
• Account changes: created, disabled, deleted, password reset, group or role changed
• Use of administrator rights and changes to security settings
• Access to, sharing of, and deletion of files in the CUI location
• Changes to the logging configuration itself
• Firewall and remote access connections, allowed and blocked

For content [b], each record should answer who, what, when, where and whether it worked: the user account, the event type, a timestamp, the source device or address, and the outcome. Most cloud suites and Windows already write these fields. Your job is to turn the right logs on and write the list down in your system security plan (SSP).

How long to keep CMMC audit logs

NIST does not set a number. Objective 3.3.1[e] says retention requirements are defined, and 3.3.1[f] says records are retained as defined. An assessor checks that you picked a period, wrote it down, and that logs from that far back actually exist.

There is one floor set by contract. DFARS 252.204-7012(e) requires that after a cyber incident you preserve images of affected systems and all relevant monitoring and packet capture data for at least 90 days from the day you submit the incident report. You cannot preserve logs you already rotated away, so your normal retention has to reach back far enough to cover an incident you discover weeks after it started. Our guide to the 72-hour reporting rule covers the rest of that clause.

Our suggestion, not a rule: pick a period you can afford to store and that comfortably covers slow discovery, and check what your cloud plan keeps by default before you write the number down. Default retention varies by product and licence, and vendors change it. If the default is shorter than your policy, export the logs to storage you control.

3.3.2: One person per account

Logs are useless if the user is "shop-pc" or "admin". The objectives ask you to define the record content needed to trace actions to individual users [a] and to show records contain it [b]. In practice that means no shared accounts on anything in scope. The shared front office login, the generic admin account, and the CNC workstation everyone signs into under one name all fail this. Give each person their own account, and give admins a separate named admin account.

3.3.3 and 3.3.5: Review, and connect the dots

3.3.3 is about the event list, not the events. You define when you review what gets logged [a], do the review [b], and update the list from it [c]. A dated note once a year, or after any significant change, is enough evidence.

3.3.5 is the heavier one at 5 points. You define your audit review, analysis and reporting processes for suspicious or unusual activity [a], and those processes must be correlated [b]. Correlated means you look across sources together, so a failed sign-in burst in your email logs and a new remote connection on your firewall land in front of the same person at the same time. A small shop can meet this with a defined weekly review that pulls alerts from the identity system, the endpoint protection console and the firewall into one checklist, with a named reviewer and a short record of what was found. A managed security provider or a log tool that collects everything into one place makes it easier, but the written process and the review record are what the assessor asks for.

The 1-point requirements: 3.3.4, 3.3.6 to 3.3.9

3.3.4: Alert when logging fails

Name who gets alerted [a], define which failures trigger an alert, such as logging turned off or storage full [b], and show that the alert reaches them [c]. Many cloud consoles can send an email when audit settings change.

3.3.6: Report on demand

You need a way to filter logs down to what matters and produce a report when asked. The search and export features in your cloud admin console usually satisfy this. Be ready to demonstrate it: "show me every sign-in by this user last month".

3.3.7: Synchronized clocks

Timestamps must come from internal clocks [a] that are compared against a specified authoritative source [b] and kept in sync with it [c]. Windows and macOS sync time automatically. Write down the source, check that network devices point to the same one, and keep a screenshot of the setting.

3.3.8: Protect the logs

This one has six objectives: audit information and the logging tools are each protected from unauthorized access, modification and deletion. Ordinary users should not be able to read, edit or clear logs, and an attacker with one stolen account should not be able to wipe the trail. Sending logs to a separate store with restricted access covers most of it.

3.3.9: A short list of log admins

Define the subset of privileged users who may manage logging [a] and limit it to them [b]. In a small company that is usually one or two named people, listed in the SSP.

What to do this week

1. Write your event list and record content into the SSP, using the list above as a starting point.
2. Check that audit logging is turned on in your email and file system, identity provider, endpoints and firewall.
3. Find your current retention for each source, choose your policy period, and set up export where the default falls short.
4. Remove or rename every shared account in scope.
5. Schedule a weekly review with a named reviewer and a one-line record of each review.
6. Set an alert for logging changes and failures, and list the one or two people who can manage logging.

Each of these produces evidence an assessor can examine, which is what the 800-171A objectives are built around. Our explainer on 800-171A assessment objectives shows how "met" is judged one objective at a time.

CMMC Map, CMMC compliance software for small defense contractors, scores the nine audit requirements alongside the rest of the 110 for free. The $149 a month plan generates the SSP sections, POA&M and policies that document your logging decisions. CMMC still sits on three self-assessed paths today, Level 1 (Self), Level 2 (Self) and the SPRS score, and audit logging matters on every Level 2 and SPRS path. This post is explanatory content, not legal advice.