Once a threat model has found the risks, the next question is what to do about them. The answer is a set of security controls, and the most common mistake is choosing them all from the same category: five ways to prevent an attack and no way of noticing if they all fail. Knowing the categories helps you build a balanced set.
Classification by function: what the control does
| Function | Purpose | Examples |
|---|---|---|
| Preventive | Stop the incident from happening | Access control, MFA, input validation, encryption, network segmentation, code review |
| Detective | Notice that it is happening or has happened | Audit logs with alerts, intrusion detection, anomaly detection, file integrity monitoring, reconciliations |
| Corrective | Limit the damage and fix the cause | Revoking sessions, isolating a host, patching, rotating a leaked key, incident response playbooks |
| Recovery | Restore normal operation | Backups and tested restores, failover, disaster recovery plans |
| Deterrent | Discourage the attempt | Warning banners, visible monitoring, legal agreements, disciplinary policy |
| Compensating | Stand in for a control that can't be implemented yet | Extra monitoring and network isolation around a legacy system that can't be patched |
Preventive, detective and corrective are the core three. Recovery is sometimes folded into corrective, and deterrent into preventive. Compensating controls are a special case: they're defined by their relationship to another control, not by what they do.
Classification by type: how the control works
- Technical (or logical): implemented in hardware or software. Firewalls, encryption, MFA, endpoint protection, rate limiting.
- Administrative (or managerial): policies, procedures, training, background checks, access reviews, change management.
- Physical: locks, badge readers, CCTV, guards, fire suppression, shredders.
The two classifications combine. An access review is an administrative detective control; a badge reader is a physical preventive control; automatic session revocation on suspicious login is a technical corrective control.
ISO/IEC 27001:2022 uses a similar grouping for its 93 Annex A controls, in four themes: organisational, people, physical and technological. NIST SP 800-53 organises its controls into 20 families such as Access Control, Audit and Accountability, and Incident Response.
Why you need more than prevention
Preventive controls are the most intuitive and the most popular, but every one of them eventually fails: a password is phished, a misconfiguration slips through review, a zero-day is exploited. A risk protected only by prevention fails silently. Nobody knows until a customer or a journalist tells you.
A simple rule for every high or critical risk in your register: the planned mitigations should cover at least two functions, usually one preventive and one detective, with a corrective step written down so the response doesn't get improvised at 3 a.m.
Worked example: Invoicely
For T5 in the Invoicely model (a support agent can read or change any customer's data through the admin console), a balanced set of controls looks like this:
- Preventive, technical: a separate, read-mostly database role for the console (least privilege).
- Detective, technical: an audit log of every console lookup and edit, with an alert on unusual volume. This also closes T6, the repudiation threat.
- Detective, administrative: a monthly review of a sample of console actions.
- Corrective, administrative: a documented procedure for suspending an agent's access and notifying affected customers.
Choosing controls for a risk
- Start from the attack path. An attack tree shows where a single control breaks the most paths. An AND node is often the cheapest place to intervene.
- Prefer technical over administrative where possible. A rule enforced by code runs every time; a policy depends on people remembering it.
- Make administrative controls produce evidence. An access review nobody records didn't happen, as far as an auditor is concerned.
- Re-score after choosing. The risk left once controls are in place is the residual risk, and that's what gets accepted or not.
Common mistakes
- Logs without alerts counted as detection. A log that nobody reads detects nothing until after the fact.
- Policies counted as controls. "Staff must not share passwords" is a rule; the control is whatever enforces or checks it.
- Untested recovery. A backup you've never restored is a hope, not a recovery control.
Key takeaways
- Classify controls by function (preventive, detective, corrective, plus deterrent, recovery and compensating) and by type (technical, administrative, physical).
- A risk protected only by preventive controls fails silently. Pair prevention with detection and a way to recover.
- Administrative controls are only as good as the evidence that they run; auditors will ask for it.
- For each high risk in a threat model, check that the planned mitigations cover at least two functions.
Frequently asked questions
What are the three main types of security controls?
By function, preventive (stop an incident), detective (notice it) and corrective (limit and fix the damage). By type, technical (implemented in technology), administrative (policies and procedures) and physical (locks, badges, guards). Both classifications are used together.
Is a firewall preventive or detective?
Mostly preventive: it blocks traffic that breaks its rules. Its logs can also support detection, which is a good example of one control serving more than one function.
What is a compensating control?
A control used in place of the one a standard or best practice expects, when that control can't be implemented yet. It is only legitimate if it actually reduces the same risk, for example blocking the attack path rather than only logging it.
How many controls does ISO 27001 have?
ISO/IEC 27001:2022 Annex A lists 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). Organisations choose which apply based on their risk assessment.