3.3.1 — Log Everything

The One-Liner

If logging isn’t on across every CUI system, you’re flying blind — and the assessor will prove it in five minutes.

What It Says

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.

What It Actually Means

Three things must be in place, and all three are assessed independently:

1. Define what to log. Not “turn on logging and hope for the best.” You need a documented list of event types: authentication events, privilege escalation, file access to CUI, configuration changes, account management, and system start/stop as a minimum. The assessor will ask to see this list.

2. Generate the logs. Every CUI system — servers, workstations, network devices, cloud services — must actually produce audit records containing the defined content. At minimum each record needs: timestamp, source/destination, user or process ID, event description, success/fail, and affected resource. If a system can’t log what you’ve defined, that’s a finding.

3. Retain the logs. Define a retention period and enforce it. Industry standard for DIB: 90 days hot (searchable in your SIEM), one year cold (immutable archive). The assessor will ask for your retention policy and then check whether logs from three months ago actually exist.

This is the foundation for the entire Audit & Accountability family. Without logging, 3.3.2 through 3.3.9 are all automatic failures.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Have you specified which event types to log?	Documented list of auditable events — not just “everything” but specific categories tied to CUI system monitoring
2	Have you defined the content audit records must contain?	Field list: timestamp, user/process ID, source, destination, event description, success/fail, affected resource
3	Are audit records actually being generated?	Pull a live log from every CUI system — records exist and are current
4	Do the generated records contain the defined content?	Sample records contain all required fields — no missing timestamps, no blank user IDs
5	Are retention requirements defined?	Policy states hot and cold retention periods
6	Are audit records retained as defined?	Pull a log from six months ago — it exists and is searchable

---

What to Have Ready on Assessment Day

Documents they’ll review: Audit and accountability policy; list of auditable event types; audit record content requirements; retention policy; system security plan; system configuration settings showing logging is enabled; sample audit records from each system type

People they’ll talk to: Personnel with audit and accountability responsibilities; information security personnel; system or network administrators; anyone who reviews or reports on audit logs

Live demos they’ll ask for: “Show me logging is enabled on this server.” “Pull a record from 90 days ago.” “Show me the retention settings in your SIEM.” “Generate an event and show me the resulting log entry.”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “What event types are you logging? Show me the documented list.”
• “Show me a sample audit record — does it contain timestamps, user IDs, source addresses, and success/fail?”
• “How long do you retain logs? Show me your retention policy.”
• “Pull a log entry from three months ago — can you find it?”
• “Is there any CUI system that doesn’t have logging enabled? How do you know?”
• “What happens when a log reaches its retention limit — is it archived or deleted?”
• “Are your retention requirements appropriate to the level of risk?”

Real-World Example

A 60-person defense sub configures all CUI systems to log authentication events, privilege changes, file access, and configuration modifications. Each log record includes timestamp (UTC), user UPN, source IP, event description, success/fail, and resource name. Logs flow from Entra ID, Defender for Endpoint, Windows Event Logs, and the CUI file server into Microsoft Sentinel. Sentinel retains 90 days of hot searchable data; Log Analytics workspace archives to immutable blob storage for one year. The IT security lead pulls a sample from each source during quarterly reviews and confirms records contain all required fields. When the assessor asks for a record from four months ago, the team runs a Sentinel query and produces the result in under a minute.

---

Where Companies Trip Up

Logging not on all systems. Workstations and servers are covered, but the firewall, VPN appliance, or cloud tenant isn’t forwarding logs. Every CUI system means every CUI system — including network devices and cloud services.

No documented event types. Logging is on but nobody defined what events matter. The assessor will ask to see the list. “We log everything” isn’t a policy — it’s a hope.

Retention too short. Logs rolling off after 30 days because nobody configured retention. An incident discovered after 45 days means you’ve lost the evidence. Define retention, test it, and prove old records still exist.

No centralization. Logs exist on individual servers but aren’t forwarded to a central location. When an attacker compromises a server, the first thing they’ll clear is the local logs. A SIEM or central log repository solves this — and makes 3.3.5 and 3.3.6 achievable.

Missing required fields. Logs exist but don’t contain all required content. Windows Security logs might have user and timestamp but no source IP. Check your records against your defined content requirements before the assessor does.

---

How to Talk About This

To a CEO or Board

Every action on every CUI system is logged with who, what, when, and where. Logs are retained for one year in tamper-proof storage. We can investigate any incident going back twelve months.

To an Engineering Team

Centralized logging via SIEM (Sentinel/Splunk). All CUI systems forwarding: Entra ID, Defender, Windows events, network devices, cloud audit logs. Required fields: timestamp (UTC), UPN, source IP, event type, success/fail, resource. 90-day hot in SIEM, 1-year cold in immutable blob storage. Quarterly review confirms all sources active and retention intact.

---

Connected Requirements

Requirement	Why it matters here
3.3.2 — Trace Every Action	The records you create here must be traceable to individual users
3.3.5 — Connect the Dots	Centralized logs from this requirement feed correlation analysis
3.3.7 — Sync the Clocks	Timestamps in your records are only useful if clocks are synchronized
3.3.8 — Tamper-Proof Logs	The records you retain here must be protected from modification

---

Implementation

🔒

Step-by-step guides for Microsoft 365, AWS, Azure, and GCP are available to Ancitus clients.

Start a conversation →

---

CMMC Practice ID: AU.L2-3.3.1 | SPRS Weight: 5 points | POA&M Eligible: No