Skip to content
ControlVerdict
Sign in
AU.L2-3.3.3CMMC Level 2Level 2

Event Review

Submit your own example

Practice statement

Review and update logged events.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.3.3.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(3)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    a process for determining when to review logged events is defined;

    1 example covers this

  2. [b]

    event types being logged are reviewed in accordance with the defined review process; and

    1 example covers this

  3. [c]

    event types being logged are updated based on the review.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    AU.L2-3.3.3Event Review
    Review and update logged events.

    • [a]

      a process for determining when to review logged events is defined;

    • [b]

      event types being logged are reviewed in accordance with the defined review process; and

    • [c]

      event types being logged are updated based on the review.

    Quarterly logged-event review that actually changes the catalog

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses all three Event Review objectives: a review process with defined timing, review of the logged event types against it, and updates resulting from that review.

    Defined process [a]. The catalog is reviewed quarterly on a calendar-driven ticket, and additionally on three triggers: a new system enters the enclave, an incident or tabletop shows a blind spot, or a platform vendor changes its available event types. The reviewers are the security lead plus the platform owner for each source; the enclave owner signs the outcome.

    How the review runs [b]. For each source we compare three things: the event types the catalog says we collect, the event types the platform can emit today, and what actually arrived in the last 30 days. The third comparison is the one that finds problems — a source can be configured correctly and still be silent.

    Updates [c]. Every change to the catalog is a versioned edit with a change ticket recording the rationale. The last two revisions added privileged-role activation from a newly onboarded SaaS app, and dropped a chatty informational event that was crowding retention without investigative value — removals need the same justification as additions.

    Maintenance. Quarterly review closes with an updated catalog version and a diff. New-system intake includes a mandatory catalog entry before go-live, which is what stopped the drift that motivated this pattern.

    Accepted gap. One vendor platform exposes a fixed event set with no configuration surface. The review still records what it emits and what is therefore not collectible, so the blind spot is documented rather than rediscovered during an assessment.

    What the evidence looks like

    • Written review process with cadence and trigger conditions
    • Versioned event catalog with the diff between the last two revisions
    • Change tickets for the recent add and the recent removal, including rationale
    • 30-day observed-events query used in the last review
    • New-system intake checklist showing the catalog step

    Environment

    Two-person security function. The enclave grew from one SaaS app to four in a year, so the event catalog drifted behind the environment.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.