Security Control Types: Preventive, Detective, Corrective

Security control types classify safeguards by what they do: preventive controls stop an incident, detective controls find one, corrective controls fix the damage, and deterrent, recovery, compensating and directive controls discourage, restore, substitute and instruct. A second axis classifies controls by how they are implemented: administrative (policies and processes), technical (technology) and physical (locks, guards, facilities). Knowing both lets you check that every important risk has more than one kind of protection, that you will notice when prevention fails, and that you can recover. This guide explains each type in plain language, maps the types to NIST CSF 2.0 functions and NIST SP 800-53 Rev. 5 controls, gives identity and non-human identity examples for each, and explains how auditors treat compensating controls under PCI DSS. It is written for security engineers, control owners, GRC analysts and anyone preparing for an audit.

Key takeaways

Function and form are two axes. A control has a function (preventive, detective, corrective and so on) and a form (administrative, technical, physical); describe both.
Prevention will fail eventually. Every critical risk needs a detective control that would notice the failure and a corrective or recovery control that limits the damage.
Many controls do more than one job. MFA prevents account takeover and its denial logs help detection; classify by primary purpose and note the secondary one.
Compensating controls are a substitute, not a waiver. NIST and PCI DSS both expect them to give equivalent or comparable protection, for a documented constraint, with evidence.
Test effectiveness, not existence. A detective rule nobody reviews or a backup nobody restores is a paper control.

What a security control is

The NIST CSRC glossary, drawing on SP 800-53 Rev. 5 and OMB Circular A-130, defines security controls as the safeguards or countermeasures prescribed for an information system or an organisation to protect the confidentiality, integrity and availability of the system and its information. Some NIST documents describe them as management, operational and technical controls, an older grouping that maps closely to administrative, operational process and technical. ISO/IEC 27002:2022 organises its controls into four themes (organisational, people, physical and technological) and tags each control with attributes, one of which is control type: preventive, detective or corrective. The wider seven-type taxonomy used in this guide is the one most security training and audit teams use; it is a classification aid rather than a requirement of any single standard. See the ISO 27002 Controls Guide.

The seven functional control types

Type	Purpose	Acts	General examples	Identity and NHI examples
Preventive	Stop an unwanted event from happening.	Before	Firewall deny rules, input validation, patching, encryption, segregation of duties.	Phishing-resistant MFA, least-privilege roles, GitHub push protection blocking a commit that contains a secret, AWS service control policies denying key creation.
Detective	Identify that an event is happening or has happened.	During or after	SIEM correlation rules, intrusion detection, file integrity monitoring, log review, reconciliations.	Alerts on a service account signing in from a new network, secret scanning alerts on existing repositories, access reviews that find orphaned accounts, AWS Config rules flagging access keys older than policy.
Corrective	Limit damage and return the affected component to a secure state.	After	Patching an exploited flaw, quarantining malware, restoring a changed configuration.	Revoking and rotating a leaked token, disabling a compromised account, removing an over-scoped OAuth grant, forcing re-authentication by revoking sessions.
Recovery	Restore services and data after a significant incident.	After	Backups, disaster recovery sites, rebuild runbooks.	Rebuilding the identity provider or directory from a clean, tested backup; break-glass accounts for when federation is down; rebuilding a secrets vault and re-issuing machine credentials.
Deterrent	Discourage someone from attempting the act.	Before	Login banners, visible cameras, disciplinary policy, legal warnings.	Acceptable use banners on privileged sessions, published consequences for credential sharing, session recording notices on PAM jump hosts.
Compensating	Provide equivalent or comparable protection when the expected control cannot be used.	Any	Network isolation and extra monitoring for a system that cannot be patched.	A legacy application that cannot use MFA placed behind a PAM proxy with MFA, session recording and IP allow-listing.
Directive	Tell people what they must or must not do.	Before	Policies, standards, procedures, training, rules of behaviour.	A machine identity standard that requires an owner, an expiry and a vault for every credential; secure coding rules banning hardcoded secrets.

The boundary between corrective and recovery is one of scale: corrective controls fix a component, recovery controls restore a service or the business. Deterrent and directive controls are both aimed at people; deterrents rely on consequences, directives on instruction. A deterrent has no effect on a fully automated attack, which is why it should never be the only control on a risk.

Product vocabularies differ: cloud platforms often use their own labels. AWS Control Tower, for example, classifies controls by behaviour as preventive (implemented with service control policies, resource control policies and declarative policies, which disallow actions), detective (AWS Config rules, which report noncompliant resources) and proactive (AWS CloudFormation hooks, which check resources before they are provisioned and stop noncompliant ones). In the taxonomy above, a proactive control is a preventive control applied earlier in the delivery pipeline. When you map product controls into your catalogue, record the product's label and your own type so evidence can be traced in both directions.

Multi-purpose controls: classify by the job the control was selected to do and note the rest. Phishing-resistant MFA is primarily preventive, but its failure events are detective signals; a PAM vault is preventive (it removes standing credentials), detective (session recording) and corrective (automatic rotation after checkout).

Administrative, technical and physical categories

Category	Also called	What it covers	Preventive example	Detective example	Corrective or recovery example
Administrative	Managerial, organisational, procedural	Policies, risk assessments, HR processes, training, change management, vendor management.	Joiner, mover and leaver process with access approval.	Quarterly access certification.	Incident response plan and post-incident review.
Technical	Logical	Controls enforced by hardware, software or firmware.	Conditional access policy requiring a compliant device.	EDR telemetry and SIEM alerting.	Automated key rotation; immutable backups.
Physical	Environmental	Protection of facilities, equipment and media.	Badge-controlled data centre doors.	CCTV and door-forced alarms.	Fire suppression; standby site.

Read the two axes together. "Technical detective" and "administrative preventive" are useful labels because they reveal gaps: a programme that is strong on administrative preventive controls (policies) but weak on technical detective ones (monitoring) will look good in a document review and fail in an incident.

Mapping control types to NIST CSF 2.0 and SP 800-53

NIST CSF 2.0 organises outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. The CIS Controls v8.1 update aligned its safeguard security functions with CSF 2.0 and added Govern. The functions are outcome groups rather than control types, but the alignment is close enough to use for gap analysis.

Control type	Closest CSF 2.0 function	Example CSF 2.0 outcomes	Example SP 800-53 Rev. 5 controls
Directive	Govern	GV.PO-01 policy for managing cybersecurity risk; GV.RR-02 roles and responsibilities	PL-4 Rules of Behavior; AT-2 Literacy Training and Awareness
Preventive	Protect	PR.AA-01 identities and credentials managed; PR.AA-05 least privilege; PR.PS-01 configuration management; PR.IR-01 networks protected from unauthorised access	AC-2 Account Management; AC-6 Least Privilege; IA-5 Authenticator Management; SC-7 Boundary Protection; PE-3 Physical Access Control
Detective	Detect	DE.CM-01 networks monitored; DE.CM-03 personnel activity and technology usage monitored; DE.CM-09 computing environments monitored; DE.AE-02 adverse events analysed	AU-2 Event Logging; AU-6 Audit Record Review; SI-4 System Monitoring; CA-7 Continuous Monitoring
Corrective	Respond	RS.MI-01 incidents contained; RS.AN-03 root cause analysis	IR-4 Incident Handling; SI-2 Flaw Remediation; SI-3 Malicious Code Protection
Recovery	Recover	RC.RP-01 recovery plan executed; RC.RP-03 backup integrity verified before restoration; PR.DS-11 backups created, protected and tested	CP-9 System Backup; CP-10 System Recovery and Reconstitution
Deterrent	Protect and Govern	PR.AT-01 awareness and training	PL-4 Rules of Behavior (consequences); AC-8 System Use Notification
Compensating	Any	Depends on the control replaced	Selected during tailoring, documented in the system security plan (PL-2)

See the Control Mapping Guide and the CIS Controls Guide.

Worked example: layering control types on one NHI risk

Risk: a cloud access key for a deployment pipeline leaks into a public repository and is used to read production data. One control type is never enough. A layered set looks like this:

Directive: a secrets standard states that credentials must live in a vault, have an owner and expire within a defined period. See the Secrets Management Guide.
Preventive: the pipeline uses short-lived federated credentials instead of a static key; push protection blocks commits containing supported secrets; the role is scoped to one bucket.
Detective: secret scanning alerts on existing history; cloud audit logs alert on the key being used from outside the pipeline's network; a weekly report lists keys older than policy. GitHub records push protection bypasses in the audit log and notifies designated owners, which is itself a detective signal worth routing to the SOC.
Corrective: a rotation runbook revokes the key, issues a replacement and confirms the old one fails. See the Secrets Rotation Runbook Template.
Recovery: data and infrastructure can be rebuilt from tested backups if the attacker modified or deleted anything.
Deterrent: limited value here against an automated scanner; useful against an insider tempted to copy a key.

The Cloudflare Thanksgiving breach shows why corrective controls must be complete. After the Okta support system breach, Cloudflare rotated credentials but missed one service token and three service accounts that were believed to be unused, and an attacker used them weeks later. Its eventual response rotated more than 5,000 production credentials.

Compensating controls and how auditors view them

The NIST CSRC glossary, citing SP 800-53 Rev. 5 and SP 800-53B, defines compensating controls as security and privacy controls employed in place of the controls in a baseline that provide equivalent or comparable protection for a system or organisation. SP 800-63-4 uses the same idea for digital identity, allowing alternative controls based on the organisation's mission, risk tolerance, risk assessments and the usability needs of the people served.

PCI DSS v4.0.1 is the framework where compensating controls are most formally audited. The PCI SSC glossary points to Appendix B (requirements) and Appendix C (the Compensating Controls Worksheet). PCI SSC guidance explains that:

Legitimate constraint: compensating controls are an option within the defined approach for an entity with a legitimate and documented technical or business constraint that prevents it meeting a requirement as stated, often a legacy system.
Not retroactive: Appendix B states that compensating controls cannot be used to retroactively address a requirement that was missed in the past.
Not the customized approach: the customized approach is a choice to meet a requirement's Customized Approach Objective differently, backed by a targeted risk analysis (Requirement 12.3.2 and Appendices D and E); compensating controls cannot be used to meet that objective.
Mixing is allowed: an entity can use compensating controls for some system components and the defined or customized approach for others under the same requirement.

In practice, assessors expect a compensating control to meet the intent and rigour of the original requirement, to go beyond controls already required elsewhere in the standard, to be proportionate to the extra risk created by not meeting the requirement, and to be documented in the worksheet with evidence and re-validated at each assessment. Check the exact Appendix B wording in the current standard before relying on it. A common rejection reason is offering a control the standard already requires (for example "we also log access") as the compensation. See the PCI DSS 4.0 Guide.

How to implement a control type review

Pick the top risks: start with the ten to twenty highest risks in the register rather than the whole control library. See the Threat vs Vulnerability vs Risk Guide.
Tag existing controls: for each risk, list controls with function (primary and secondary) and category. Use the control catalogue fields your GRC tool already has.
Find gaps: flag any risk with no detective control, no corrective or recovery control, or only administrative controls.
Design additions in audit mode first: introduce new technical preventive controls in report-only mode (for example conditional access report-only, AWS Config detective rules before SCP enforcement, push protection with bypass allowed), measure impact, then enforce.
Pilot and roll back safely: enforce for a pilot ring, keep a documented rollback (disable the policy, restore the previous rule version) and a break-glass path for identity controls.
Test effectiveness: simulate the event each detective control should catch, restore from backup, run the rotation runbook end to end.
Record compensating controls formally: constraint, original requirement, replacement controls, evidence, owner and review date.
Re-review on change: new systems, retired controls and incidents should trigger a re-tag.

Choosing between types: prefer preventive controls where the event is high impact and the control is reliable and cheap to run. Lean on detective and corrective controls where prevention would block legitimate work (for example broad developer access in a sandbox) or where the threat cannot be prevented (insiders with legitimate access). Small organisations should concentrate on a few strong technical preventive controls (MFA, least privilege, patching) plus managed detection and tested backups. Larger organisations also need formal control ownership, continuous control monitoring and compensating control governance. See the Defence in Depth Guide and the Audit Evidence and Continuous Controls Monitoring Guide.

Detection and measurement

Type coverage: percentage of high and very high risks with at least one preventive, one detective and one corrective or recovery control.
Detective efficacy: percentage of simulated events (purple team or test cases) detected within the target time.
Corrective speed: median time from detection of a leaked machine credential to confirmed revocation.
Recovery proof: percentage of tier 1 systems with a successful restore test in the last 12 months.
Compensating control hygiene: number of compensating controls past their review date or without evidence attached.
Control test failure rate: percentage of controls failing their periodic test, by type.

Common failure patterns

All prevention, no detection: heavy investment in perimeter and policy, but no alert would fire if a valid service account were misused.
Policy counted as protection: a directive control ("do not hardcode secrets") is recorded as mitigating the risk with no technical control enforcing or detecting it.
Incomplete corrective action: rotation that skips credentials believed to be unused, as in the Cloudflare case above.
Untested recovery: backups exist but restores of identity systems and vaults have never been rehearsed. See the Backup Identity Isolation Guide.
Compensating controls used as permanent waivers: no constraint documented, no review date, and protection that is not comparable to the original requirement.
Alert without owner: a detective control generates findings that nobody triages, so it detects nothing in practice.

Practitioner checklist

Tag every control in the catalogue with its primary function, any secondary function and its category.
Confirm each high risk has preventive, detective and corrective or recovery coverage.
Pair every directive control with a technical control that enforces or detects it.
Route preventive control bypass events (push protection bypasses, break-glass use) to detection.
Roll out new preventive controls in audit or report-only mode, then enforce with a rollback plan.
Test detective rules and recovery procedures on a schedule and record the evidence.
Document every compensating control with the constraint, the requirement replaced, evidence, owner and review date.
Include machine identities and secrets in corrective runbooks so rotation is complete.
Report type coverage and test results to the risk committee.

Standards and references

Related NHI Mgmt Group resources: Defence in Depth Guide · CIA Triad Guide · Control Mapping Guide · PCI DSS 4.0 Guide · Secrets Management Guide

Security Control Types Guide: Preventive, Detective, Corrective and More