How do quarterly, nightly and change-triggered compliance evaluations differ in what they detect?

## The rule is the same; the schedule changes the answer One encoded control can be run three ways, and the three produce different evidence. ### Per-audit-period sweep One full evaluation of the estate per reporting period, usually timed near the period boundary. Its virtues are cost and alignment: a single pass over every resource, producing exactly the snapshot the reporting cycle wants. Its weakness is that the detection lag equals the period. A violation introduced the day after a sweep survives until the next one, and a violation that opens and closes between sweeps is never seen at all. It also creates a predictable incentive: when everyone knows the sweep runs in the last week of the quarter, what gets measured is the state of the estate in the last week of the quarter, which is not the same thing as the state of the estate. ### Scheduled run (nightly, hourly) A full or partial evaluation on a fixed timer. Two things change qualitatively. First, the lag is bounded by the interval: no claim on your dashboard is ever older than one interval, which is what makes "compliant as observed in the last 24 hours" a sentence you can actually defend. Second, you now have a *series* rather than a snapshot - counts per day, first-seen and last-seen per finding, and a burn-down that shows whether remediation is outrunning introduction. The costs are real and worth naming: every run reads live state, so cost scales with estate size times frequency, and the read load lands on the same control planes your engineers use. Rate limits and pagination over a large estate are the usual reason a "nightly" run quietly becomes a nightly-ish one. ### Change-triggered evaluation The evaluator subscribes to a stream of resource-change events and re-evaluates just the resource that changed. Lag drops to seconds or minutes, the work per event is tiny, and the finding arrives while the person who caused it still remembers doing it - which is the single biggest factor in whether it gets fixed. It has two structural blind spots, and an interviewer is usually probing for these: - **No change, no evaluation.** A control whose truth moves with the calendar produces no event to trigger on. Under "credentials rotated within 90 days", the key that crosses the threshold tonight was not modified - it aged. A purely event-driven programme reports that control green forever. - **Coverage equals the feed's coverage.** Resource types the event stream does not emit for, regions or accounts not wired up, dropped or delayed events, and resources created before the subscription existed are all invisible. Event-driven evaluation tells you about changes; it cannot tell you about the estate. ### Putting them together The answer that lands in an interview is that these are layers, not alternatives: | Cadence | Detection lag | What it is good for | Blind to | |---|---|---|---| | Per-period sweep | Up to one period | Cheap, defensible snapshot at the reporting boundary | Anything inside the period | | Scheduled run | One interval | Trends, burn-down, bounded freshness | Violations shorter than the interval | | Change-triggered | Seconds | Fast feedback to the person who caused it | Clock-driven controls; anything the event feed misses | Run change-triggered evaluation for latency, a periodic sweep for coverage and for the controls that decay by date, and treat the period-aligned run as the artefact you report from. Crucially, use the sweep to *reconcile*: findings the sweep produces that the event path never raised are a direct measurement of your event feed's gaps. ## Choosing per control Cadence is a per-control decision, not a programme-wide one. Ask two questions of each control: 1. **How does it become false?** By somebody acting - event-driven is the right primary. By the calendar - only a timer can find it, and you can even calculate in advance the day each resource will cross the line. 2. **How bad is exposure per unit time?** A short window of a badly exposed data store justifies expensive, frequent evaluation. A missing owner tag does not; a per-period sweep is proportionate, and running it hourly buys nothing but load and noise. A final subtlety on interval choice: shortening the interval mostly improves how quickly you *find* things, not how much of the interval you *cover*. Two runs per day still see two instants. If a control has to catch transient conditions, no interval solves it - you need an event source or an authoritative record of the activity itself.