Preventive, Detective, and Corrective Controls: A CISM Domain 3 Primer

The Core Control-Type Taxonomy

Every security control exists to do one of a small number of jobs: stop something bad from happening, notice that something bad is happening or happened, or fix the damage once it has. ISACA's CISM Review Manual organizes this around three primary categories, preventive, detective, and corrective, and CISM candidates are expected to classify real-world controls into these buckets without hesitation.

This taxonomy matters beyond the exam. When you design or review a security program (the focus of CISM Domain 3), you are constantly asking "what type of control am I adding here, and does the program already have enough of that type relative to the risk." A program that is all preventive and no detective is blind to anything that gets past the front door. A program that is all detective and no corrective knows about every incident but has no playbook to recover from one.

Preventive Controls

Preventive controls act before an unwanted event can occur. They reduce the likelihood of an incident by removing or restricting the opportunity for it to happen in the first place. On the exam and in practice, these are the controls people think of first when they hear "security control."

Common examples:

• Access controls: role-based access control, least privilege, multi-factor authentication
• Network controls: firewalls, network segmentation, allow-listing
• Configuration controls: hardened baselines, disabling unused services, patch management before exploitation
• Procedural controls: separation of duties, mandatory security awareness training, pre-employment background checks
• Physical controls: badge readers, mantraps, locked server rooms

Preventive controls are generally the cheapest to operate once implemented and the most cost-effective on a per-incident-avoided basis, but they are never complete. No set of preventive controls reduces likelihood to zero, which is exactly why detective and corrective controls exist as a second and third layer. This layered reasoning is the foundation of defense in depth, and it is also the logic behind a well-built security awareness program, which is itself a preventive control aimed at human-layer risk.

Detective Controls

Detective controls do not stop anything. Their job is to notice: to generate a signal when something anomalous, policy-violating, or actively malicious is occurring or has already occurred. A detective control's value is measured by how quickly and reliably it surfaces the event and how low its false-positive rate is.

Common examples:

• Intrusion detection systems (IDS) and security information and event management (SIEM) alerting
• Log review and audit trails
• File integrity monitoring
• Internal and external security audits
• Reconciliation procedures (for example, comparing expected vs. actual financial transactions)
• CCTV monitoring and security guard patrols

A frequent exam trap is confusing a detective control with its downstream reporting. The IDS alert firing is detective. What the security team does with that alert, isolating a host, revoking credentials, is corrective. Candidates who skip this distinction tend to misclassify "incident response" as a single control type when it is actually a process built from detective and corrective controls working together. The metrics you use to judge how well detection and response are working are covered in our guide to incident response metrics.

Corrective Controls

Corrective controls act after a detective control (or an external party, or sheer luck) has identified a problem. Their purpose is to limit the damage already in progress and return the environment to a known-good state. Corrective controls are sometimes split further into "recovery" controls in other frameworks, but CISM materials generally treat recovery as part of the corrective category.

Common examples:

• Restoring data from backup after ransomware or corruption
• Patching a vulnerability that was actively being exploited
• Isolating or rebuilding a compromised endpoint
• Revoking and reissuing compromised credentials or certificates
• Disaster recovery failover to a secondary site
• Post-incident process changes that address a root cause

A useful way to separate corrective from preventive: a preventive control exists regardless of whether an incident ever occurs. A corrective control is only invoked because an incident already happened. Rebuilding a hardened server image before deployment is preventive. Rebuilding that same server because it was compromised is corrective, even though the technical steps look similar. This same before/after logic underlies the distinction between disaster recovery and business continuity planning, where DR is heavily corrective/recovery-oriented and BCP includes a broader mix of control types.

Compensating, Deterrent, and Directive Controls

The CISM Review Manual and broader governance frameworks (COBIT, NIST, ISO 27001) also reference several secondary control types that candidates should recognize, even though preventive, detective, and corrective remain the primary axis tested.

These secondary types are not mutually exclusive with the primary three. A policy (directive) that requires badge access (preventive) to a data center is both directive and preventive at once. Exam questions sometimes test whether you understand that a single control can satisfy more than one classification simultaneously, and that the classification is driven by the control's function, not its format.

How CISM Frames Control Selection

CISM does not treat control-type classification as trivia. It frames control selection as a risk management decision: given a specific risk, what mix of preventive, detective, and corrective controls achieves an acceptable residual risk at a justifiable cost. This is directly tied to the risk concepts in CISM Domain 2 and to the quantitative framing used in key risk indicators.

A few principles ISACA expects candidates to apply:

1. No single control type is sufficient on its own. A mature program layers preventive, detective, and corrective controls for any significant risk. This is defense in depth applied to control selection rather than just network architecture.
2. Detective controls are only as valuable as the response behind them. An alert nobody actions provides false assurance. CISM scenario questions frequently describe a detective control firing correctly and then ask what should happen next, testing whether the candidate understands that detection must connect to a corrective process.
3. Cost and risk appetite drive the mix, not a checklist. Low-impact, low-likelihood risks may be adequately covered by a single preventive control. High-impact risks typically justify preventive, detective, and corrective coverage together, informed by the organization's documented risk appetite.
4. Compensating controls require documented justification. Auditors and ISACA both expect a compensating control to be explicitly tied to the risk it offsets, not used as a permanent workaround for a control gap.

How the Exam Tests This

CISM rarely asks "which of the following is a preventive control" as a bare definitional question. Instead, it embeds the classification inside a scenario and asks you to pick the "best" or "most appropriate" answer, which usually means identifying the correct control type for the stage of the incident described.

Typical scenario patterns include:

• "An incident has already occurred, what should management do first?" The correct answer is almost always a corrective or containment action, not a preventive measure, because preventive controls can no longer change the outcome of an event already in progress.
• "Which control would have best identified this issue sooner?" This is asking you to recognize a gap in detective controls, even if the scenario's narrative focuses on a technical failure.
• "Management wants to reduce the likelihood of recurrence." This points toward preventive controls or a root-cause-driven corrective action that becomes preventive going forward (for example, patching a vulnerability class, not just the single instance).
• "A control cannot be implemented due to a legacy constraint." This points toward a compensating control, and the best answer will usually include some form of enhanced monitoring or review as the compensation.

The practical study tactic: for every control example you encounter while reviewing the CISM Review Manual or practice questions, force yourself to say out loud which primary type it is and why. Candidates who can do this instantly for unfamiliar controls, not just memorized textbook examples, consistently perform better on Domain 3's scenario-heavy questions.

Frequently Asked Questions

Is encryption a preventive or detective control?

Encryption is preventive. It does not detect unauthorized access, it prevents unauthorized parties from being able to use data even if they obtain it. The confusion sometimes arises because encryption also supports confidentiality objectives broadly, but its control function is squarely preventive.

Is a security audit preventive or detective?

Detective. An audit identifies control weaknesses, policy violations, or incidents that have already occurred or are currently present. It does not stop anything from happening on its own, though the findings often drive preventive or corrective improvements afterward.

Can one control be more than one type at the same time?

Yes. A single control can serve multiple functions depending on how it operates. A well-configured firewall with logging enabled is primarily preventive (blocking traffic) but also contributes a detective function (the logs can reveal attempted intrusions). CISM exam questions generally ask for the primary or most dominant function in context rather than every possible classification.

Where does incident response fit in this taxonomy?

Incident response is a process, not a single control type. It typically begins with detective controls (alerting, monitoring) that trigger the response, followed by corrective controls (containment, eradication, recovery). Some incident response activities, like tabletop exercises and updated playbooks, also feed back into preventive controls for the next occurrence.

Are backups preventive or corrective?

Corrective. Backups exist to enable recovery after data loss or corruption, they play no role in preventing the loss from occurring. This is one of the more commonly missed classifications on practice exams.

How many control types does CISM expect candidates to know?

The three primary types, preventive, detective, and corrective, are tested most heavily. Candidates should also recognize deterrent, compensating, and directive controls as secondary classifications that can appear in scenario answer choices, but the exam's core reasoning almost always resolves to the primary three.

Related Guides