A preventive control stops a bad event from happening, a detective control notices that it happened, and a corrective control limits the damage and restores the normal state. The type matters because it decides what evidence proves the control works: a block, an alert, or a completed fix.
Definitions in one table
| Type | Purpose | Engineering example | Evidence of operation |
|---|---|---|---|
| Preventive | Stop it before it occurs | Branch rule that blocks merges without review | Rule configuration, plus blocked attempts if any |
| Detective | Find it after it occurs | Alert when an admin role is granted | Alert logs, tickets showing someone responded |
| Corrective | Fix it and recover | Rollback procedure, credential rotation after exposure | Incident ticket, completed rollback, restored state |
Many real controls combine types. A required review is preventive. A weekly check of the bypass list is detective. A revert of an unreviewed commit is corrective.
Why auditors care
Each type fails differently, so each is tested differently.
- Preventive: test the configuration and try to get around it. Show the setting, show that exceptions are limited and recorded.
- Detective: test that the signal fires and that a person acts. An alert nobody reads is not a working control, so keep proof of response.
- Corrective: test that the fix happens in the time your policy states. Show real incidents or a drill.
Choosing the right mix
Preventive controls are usually cheapest to evidence, because a technical block runs every time with no human step. But they can be bypassed and they can break work, so not everything can be preventive. Detective controls cover what you cannot block. Corrective controls matter for the cases where both earlier layers miss.
A useful rule: for each high-risk event, name one control of each type, even a light one. If you have only detective controls for a serious risk, you are accepting that the event will happen first.
Steps to classify your controls
- List your controls in a sheet.
- For each, ask "does this act before, during or after the bad event?"
- Write the type next to the control.
- For each risk, look for a missing type.
- For detective controls, name who responds and by when.
- For corrective controls, schedule a drill or find a real instance to cite.
Examples across the delivery pipeline
- Source code: required reviews (preventive), audit of direct pushes (detective), revert and notify (corrective).
- Dependencies: policy gate on known vulnerable versions (preventive), scheduled rescans of released builds (detective), upgrade or patch pull request (corrective).
- Secrets: push protection (preventive), secret scanning of history (detective), rotation (corrective).
- Access: SSO and MFA (preventive), review of dormant accounts (detective), disable and investigate (corrective).
Try it yourself
Click through it at your own pace, or open it full screen. Look for what is a detective signal here, and ask what preventive and corrective step would sit alongside it.
Quick check
Is a code review preventive or detective?
Preventive when it is required before merge. A review done after release would be detective.
Can one control be more than one type?
Yes, but describe each part separately so you can show evidence for each.
Safeguard policies, gates and guardrails act as preventive checks, while dependency scanning and compliance and evidence automation support detective ones. Try a free scan.
Last reviewed: 19 October 2026.
