What is the difference between a preventive and a detective policy control?

## Two classes of control, separated by when they run A **preventive** control is evaluated *before* a change takes effect, and its answer is part of the decision about whether the change happens. The change is proposed — a merge request, a build promotion, an admission request, a call to a cloud provider's API — the control evaluates the proposal, and a `deny` means the state described by that proposal never comes into being. A **detective** control is evaluated *after* something exists. It reads the world as it currently is: a scheduled sweep over live cloud resources, a query over an inventory, a subscription to a change-event feed. Its output is a finding — a statement that a thing is non-conforming, addressed to a human or a ticket queue. Nothing about producing that finding stops anything. The distinction is about **position in time relative to the change**, not about how strict the rule is or what language it is written in. The identical rule — "a managed data store must have encryption at rest enabled" — is preventive when it is evaluated against a proposed store before creation and detective when it is evaluated against stores that already exist. ## The exposure window The reason this classification matters is the **exposure window**: the interval during which the non-conforming state is real. For a preventive control the window is zero by construction. For a detective control it is the sum of several delays: - creation → next evaluation (a sweep runs on a cycle; an event feed still has propagation delay) - evaluation → someone actually reads the finding - triage → an owner is found and a decision is made - decision → the fix lands A real window of hours is normal even for a well-run detective control. What matters is what can happen inside it. A store created without encryption at rest and left for six hours has almost certainly accepted writes; those writes are now durable, unencrypted, on media you do not own. ## What each one structurally cannot see Preventive controls only adjudicate changes that pass through the point where the control sits. Anything created by a hand-run console click, a third-party integration using its own credentials, or a platform component that provisions sub-resources on your behalf never produces a proposal for the gate to read. A preventive control also sees one proposed change at a time; it is a poor tool for estate-wide questions like "how many of these already exist". Detective controls have the opposite shape. They see everything that exists regardless of how it got there, and they can answer estate-wide questions directly — but only about the past. ## What a finding cannot undo A finding is information, and information is not a reversal. You can delete the offending resource, but you cannot un-write data that landed in it, un-serve the requests it answered, or un-disclose a secret that was readable while it was exposed. The cost of after-the-fact remediation is what decides how tolerable a window is: - **cheap to fix**: a mutable property that can be edited in place with no downtime — a long window is survivable - **expensive to fix**: a property fixed at creation. Encryption at rest on many managed data stores is the standard example: you cannot toggle it on afterwards. Remediation is create a new encrypted store, migrate the data, cut traffic over, destroy the original — an availability-affecting project, not an edit - **impossible to fix**: anything about what was already disclosed. A rotated credential is still a credential that was readable for six hours ## Why programs run both Because the two failure modes are opposite ones. Preventive alone gives you a green record that describes only the gated path and says nothing about the resources that never touched it. Detective alone gives you complete coverage of an estate you were never able to keep clean. The usual pattern is: block at the gate for the changes you can route through it, and sweep continuously for the state you cannot guarantee was ever proposed. ## Grading a control in an interview Three questions get you most of the way: 1. Does its verdict gate the change, or only describe it? 2. What fraction of the ways this state can come to exist actually pass through it? 3. What does remediation cost once the state already exists? A fourth class, **corrective**, is sometimes named separately: a control that not only reports but also acts on what it found. It is still evaluated after the fact, so it shortens the exposure window rather than eliminating it, and it inherits every limit above about what cannot be undone.