CMMC Readiness Is an Engineering Problem: The NIST 800-171 Logging Controls Your SIEM Doesn't Satisfy

There is a specific moment in most CMMC readiness engagements where the conversation stops being about compliance and starts being about engineering. It is the moment somebody says "we have a SIEM, so logging is covered" — and then someone opens the actual control text.

NIST SP 800-171's Audit and Accountability family is nine separate controls, 3.3.1 through 3.3.9. A default SIEM deployment — agents installed, events flowing, dashboards lighting up — substantively addresses about three of them. The other six are not features you turn on. They are properties of how the system is built and operated, and an assessor will ask you to demonstrate each one.

This is a walkthrough of that gap, from the engineering side. It is not a compliance checklist and it will not make you certified. It is the set of things we keep finding still open after the SIEM is running.

Key Takeaways

• 3.3 is nine controls, not one. "We have a SIEM" maps cleanly to roughly 3.3.1, 3.3.5, and 3.3.6. The rest need deliberate engineering.
• 3.3.4 — alerting on audit process failure — is the one that fails silently. A dead agent and a quiet network produce identical dashboards. If you have not built a dead-man's switch, you cannot demonstrate this control.
• Unique traceability (3.3.2) dies at the shared administrator account, and containers make it worse by default.
• Clock synchronisation (3.3.7) is a logging control. Without an authoritative time source, cross-host correlation is not merely harder — the evidence is not defensible.
• 3.3.8 and 3.3.9 mean your administrators must not be able to quietly delete the evidence. Most default installs give them exactly that.
• Automation determines how much evidence is ready when the assessor arrives. It does not determine the outcome, and nothing in this post makes anyone compliant.

The Control Text Is Not "Have a SIEM"

Read as engineering requirements rather than compliance prose, the nine controls fall into three groups.

What a SIEM genuinely gives you. 3.3.1 (create and retain audit records sufficient to investigate unauthorised activity), 3.3.5 (correlate audit review and analysis across sources), and 3.3.6 (audit record reduction and on-demand report generation) are close to what a log pipeline is for. Deploy the thing, point agents at it, and you have a real, non-trivial claim to make against all three — with the retention caveat below.

What a SIEM assumes you already did. 3.3.2 (uniquely trace actions to individual users) and 3.3.7 (synchronise clocks to an authoritative source) are upstream of the SIEM entirely. No amount of log aggregation fixes a shared login or a drifting clock; it faithfully records the ambiguity.

What a SIEM actively works against by default. 3.3.4 (alert on audit logging process failure), 3.3.8 (protect audit information and tooling from unauthorised access, modification, and deletion), and 3.3.9 (limit management of audit functionality to a subset of privileged users) all require constraining the platform your administrators just installed and own root on. 3.3.3 (review and update logged events) is a process control that needs an artefact, not a feature.

The rest of this post is the second and third groups.

3.3.2: Unique Traceability Dies at the Shared Root Account

The control asks that the actions of individual users be traceable to those users. The failure mode is not exotic. It is four engineers who all ssh in as a service account, or sudo su - on arrival, after which every subsequent log line is attributable to root and nothing else.

The engineering is unglamorous and well understood:

• Named accounts to the edge. Interactive logins are individual; shared accounts are for services, and services do not log in interactively.
• sudo as the attribution boundary. sudo records the invoking user; sudo su - throws that away one line later. The distinction between "we log sudo" and "we log what happened after sudo" is exactly what an assessor probes.
• Shell session capture where it matters. On hosts in scope, auditd with pam_tty_audit records the command stream tied to the originating login, which is the difference between "root ran a command" and "this person ran this command at this time."

Containers deserve a specific warning. A process inside a container logs its container-local identity, and unless you are deliberately propagating the human identity that triggered the deployment, the audit trail terminates at an orchestrator service account. Everything downstream is uniquely traceable to a robot. When we wrote up running Odoo CRM on Proxmox in production, this was the piece that took the most deliberate design: keeping a human name attached to an action that crosses three abstraction layers.

3.3.4: The Control Everyone Fails, Because Failing It Looks Like Success

If you take one thing from this post, take this one.

3.3.4 requires alerting in the event of an audit logging process failure. Not alerting on security events — alerting on the logging itself breaking. And the reason it is the most commonly open control we find is structural:

A dead agent and a quiet network produce identical dashboards.

Silence is the expected steady state of a well-behaved environment. Silence is also what you get when the forwarder segfaulted three weeks ago, when the disk filled and the log rotated into nothing, when a certificate expired, when a firewall change orphaned a subnet, or when someone bounced a host and the service did not come back because it was never enabled at boot.

None of those raise an alert by default, because there is no event to alert on. The absence of events is the signal, and absence has to be detected deliberately.

What that looks like in practice:

• Agent connectivity as a monitored condition. Wazuh, for instance, exposes disconnection handling at the manager level — agents_disconnection_time sets how long without a keepalive marks an agent disconnected, and agents_disconnection_alert_time controls how long after that it raises an alert. Both have defaults. Neither default is a decision you made, and an assessor is entitled to ask which value you chose and why.
• A dead-man's switch on the pipeline itself. A heartbeat event emitted on a fixed interval, with an alert on its absence, is the only way to prove the path from source to index is alive end to end. Monitoring the SIEM from inside the SIEM has an obvious circularity problem — if the pipeline is down, so is the alert about the pipeline being down. The check must be external to the thing being checked.
• Ingest-volume anomaly detection. Events-per-source-per-hour dropping to zero, or falling off a cliff, is the cheapest early warning available and catches the partial failures a binary up/down check misses.
• Loss accounting you can show. If your forwarders drop events under backpressure, you want a counter for that. "We do not believe we lose events" is a much weaker statement than "here is the dropped-event counter, and here is its value."

We learned the general shape of this the hard way in a different context: while building out DNS telemetry, we discovered a secondary resolver had been quietly dead for an unknown period — a failure that was invisible precisely because everything downstream kept working. That write-up is in the Pi-hole telemetry post, and the lesson transfers directly. If a component is part of your audit architecture, its silence must be alarming rather than reassuring.

3.3.7: Clock Synchronisation Is a Logging Control

3.3.7 requires the system to compare and synchronise internal clocks against an authoritative source for the purpose of generating audit timestamps. It is easy to read as boilerplate. It is not.

Correlation across hosts (3.3.5) is only meaningful if the timestamps are comparable. Two hosts thirty seconds apart will produce an incident timeline where the effect precedes the cause, and once an assessor — or an incident responder, or opposing counsel — notices that, the evidentiary value of the whole corpus drops.

The engineering: chrony or equivalent against a defined authoritative source, monitored. chronyc tracking reports the current offset and stratum, and that offset belongs in your monitoring alongside disk and memory. Virtualised and containerised hosts inherit the hypervisor's clock behaviour, which is worth verifying rather than assuming. Log in UTC, everywhere, and convert at the display layer; a timeline assembled from mixed local timestamps across a daylight-saving boundary is a genuinely miserable artefact to defend.

3.3.8 and 3.3.9: Your Administrators Can Delete the Evidence

These two controls, read together, say something uncomfortable about the default state of most deployments: audit information must be protected from unauthorised modification and deletion, and management of the audit logging function must be limited to a subset of privileged users.

In a fresh install, the administrators who own the infrastructure typically also own full delete rights over the indices holding the audit records. That is not a subset. That is everyone with the keys.

Closing it is ordinary systems work, and it is the part that requires the most organisational buy-in:

• Ship off-box, immediately. Audit records that live only on the host they describe are protected by exactly the machine an attacker has already compromised. Remote-first collection is the control.
• Separate the audit role from the infrastructure role. The person who administers the servers should not unilaterally administer the audit store. On the indexer side this is role and index-level access control, and it means the SIEM admin group is a deliberately different group from the platform admin group.
• Append-only and retention locks where the platform supports them. Index state management with a retention policy that an operator cannot casually shorten, plus immutability or object-lock on the archive tier, converts "we would notice deletion" into "deletion is not available."
• Audit the audit tooling. Changes to logging configuration, retention policy, and access grants are themselves events worth recording — and recording somewhere the person making the change does not control.

3.3.1's Quiet Trap: Retention Defaults Are Measured in Days

3.3.1 asks that audit records be created and retained to the extent needed to enable monitoring, analysis, investigation, and reporting. The control does not name a number, which means the number is yours to justify — against your contractual obligations, your incident response plan, and what your assessor expects to be able to look at.

The trap is that stock retention defaults are tuned for disk economy, not investigation. A default index lifecycle policy that keeps hot data for a couple of weeks is entirely sensible engineering and entirely inadequate as an audit-retention decision, and the gap is invisible until someone asks for records from four months ago.

The fix is a decision, written down, with the storage tiering to implement it: hot for active search, warm or cold for the long tail, archive for the remainder of the retention window. Then verify a restore. A retention policy nobody has ever restored from is a claim, not a control — the same principle as any backup, and it fails the same way.

What a SIEM Deployment Does Not Get You

Honest boundaries, in the same spirit as the detection-limits tables we publish for our network sensors:

And the boundary that matters most: none of this is certification. A CMMC Level 2 certification assessment is conducted by an authorised C3PAO. AIQSO is not a C3PAO and is not CMMC certified — we do readiness, gap analysis, and remediation engineering. Tooling and automation determine how much of your evidence is ready when the assessor arrives; they do not determine the verdict, and any vendor selling "automated CMMC certification" is selling something that does not exist.

Where This Leaves You

The useful reframe is that the Audit and Accountability family is mostly not a documentation exercise. Seven of the nine controls resolve to concrete engineering decisions — identity design, alerting on absence, time authority, access separation, retention economics — that a competent infrastructure team can specify, build, and demonstrate. The evidence an assessor wants is largely a by-product of having built it correctly.

If you want the companion piece on getting the pipeline itself stood up, we wrote up deploying Wazuh SIEM for small businesses, including the tuning phase and the honest cost picture, and the broader challenges of unified security monitoring. For the framework-level view of CMMC 2.0's levels and assessment path, see our CMMC 2.0 guide for defense contractors, and our CMMC readiness page for how the readiness, gap analysis, and remediation work is scoped.

Everything above is commodity engineering, and we publish it deliberately. The layer that sits on top of a telemetry pipeline — device attribution, AI-service inventory, risk scoring, and the dashboards that turn events into answers — ships as Faron, our agentless shadow-AI detection product.

If you are heading toward a Level 2 assessment and want to know which of the nine you can actually demonstrate today, book a call and we will walk your current logging architecture against the control text.