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.

• 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