3.3.3 — Review What You Log
What It Says
Section titled “What It Says”Review and update logged events.
What It Actually Means
Section titled “What It Actually Means”This is about the logging configuration, not about reviewing the logs themselves (that’s 3.3.5 and 3.3.6). The question is: are you logging the right events?
What the assessor checks:
-
Defined review schedule. You have a documented process that says when and how you review your logging configuration — at a defined frequency (quarterly is standard), after significant system changes, and after security incidents that revealed logging gaps.
-
Actual reviews happen. You can show evidence of the last review: who performed it, what they checked, what they found. Meeting minutes, a completed checklist, a ticket — something dated and signed.
-
Updates result from reviews. When a review identifies a gap — new server not forwarding logs, new attack technique not captured, deprecated event source removed — the logging configuration changes. The assessor wants to see before-and-after evidence: “We added cloud audit log forwarding in Q3 after deploying our Azure tenant.”
This requirement exists because your threat landscape and system inventory change over time. The logging configuration you set up a year ago may be missing events from systems that didn’t exist then, or it may not capture attack patterns that have emerged since.
Pass or Fail
Section titled “Pass or Fail”Your assessor needs a “yes” to every row:
| # | Question | What “yes” looks like |
|---|---|---|
| 1 | Is there a defined process for when to review logged events? | Documented schedule — quarterly, after incidents, after major system changes |
| 2 | Are logged event types reviewed per the defined process? | Evidence of the last review: date, reviewer, what was checked |
| 3 | Are logged event types updated based on the review? | Change records showing logging config was adjusted — new sources added, stale sources removed, event types modified |
What to Have Ready on Assessment Day
Section titled “What to Have Ready on Assessment Day”Documents they’ll review: Audit and accountability policy; procedures addressing auditable event review; list of current logged event types; records of reviews and updates to that list; system security plan; system incident reports that triggered logging changes
People they’ll talk to: Personnel with audit and accountability responsibilities; information security personnel responsible for reviewing logging configuration
Live demos they’ll ask for: “Show me your list of logged event types. When was it last reviewed? What changed?”
The Assessor’s Playbook
Section titled “The Assessor’s Playbook”These are the actual questions. Have answers ready.
- “When did you last review your logging configuration? Show me the evidence.”
- “What triggered the review — a schedule, a system change, or an incident?”
- “Did the review result in any changes to what you’re logging? Show me the before and after.”
- “You deployed a new cloud service last quarter — did you update your logging configuration to include it?”
- “How do you identify when a new system or threat requires additional logging?”
- “Who is responsible for performing logging configuration reviews?”
Where Companies Trip Up
Section titled “Where Companies Trip Up”Set and forget. Logging was configured during initial setup and nobody’s touched it since. The assessor asks “when did you last review this?” and the answer is “when we set it up two years ago.” Schedule quarterly reviews at minimum.
No review evidence. Reviews happen informally — someone glances at the SIEM — but there’s no record. You need a dated artifact: a completed checklist, meeting minutes, or a ticket with notes on what was reviewed and what changed.
New systems not captured. A new server, cloud service, or SaaS tool was deployed but nobody updated the logging configuration to include it. Tie logging reviews to your change management process — every new CUI system deployment should trigger a logging configuration check.
Review without action. The review happens and identifies gaps, but nobody follows through. If the review finds issues, there should be change records showing the logging configuration was updated.
How to Talk About This
Section titled “How to Talk About This”Connected Requirements
Section titled “Connected Requirements”| Requirement | Why it matters here |
|---|---|
| 3.3.1 — Log Everything | Defines the baseline logging config that this requirement reviews and updates |
| 3.4.3 — Control Every Change | New system changes should trigger a logging review |
| 3.14.3 — Act on Advisories | Security advisories may reveal new event types you need to capture |
| 3.3.5 — Connect the Dots | Log review and correlation — this requirement tunes the config, 3.3.5 reviews the output |
Implementation (coming soon)
Section titled “Implementation (coming soon)”Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.
CMMC Practice ID: AU.L2-3.3.3 | SPRS Weight: 1 point | POA&M Eligible: Yes