Security controls are easy to memorize as vocabulary and much harder to classify correctly in a real scenario. A firewall can prevent an unwanted connection and generate logs that help detect abuse; its configured filter enforces a written access policy, while the policy is a managerial control serving a directive function. Backups can support recovery, but an immutable backup can also reduce the impact of ransomware. A security awareness banner may deter some behavior while communicating a directive. The function depends on how the control is used, not only on the product name.

A security control’s category depends on what it accomplishes in the described workflow. A preventive control can deny an unauthorized action, a detective control can create an alert after suspicious activity, a corrective control can restore a safe configuration, and a compensating control can reduce a risk when a preferred measure is unavailable. The same technology might serve different roles depending on deployment and evidence. To evaluate third-party SY0-701 practice scenarios on control selection, first name the failure to prevent or discover, then describe what observable result would show the chosen control worked. A control that looks appropriate on an architecture drawing but has never been tested under the actual authorization or failure condition is not yet a demonstrated safeguard.

Separate control function from control implementation

A security control is a safeguard or countermeasure used to reduce risk and protect confidentiality, integrity, and availability. The same implementation can perform more than one function. This is why classifications such as preventive, detective, corrective, compensating, deterrent, and directive should be treated as descriptions of purpose rather than permanent labels attached to technologies.

Consider a network firewall. A rule that blocks unsolicited inbound traffic is preventive. Logging from the same firewall can be detective when analysts use it to identify suspicious connection attempts. A temporary deny rule inserted after an incident can be corrective because it helps contain or remediate an active problem. The technology did not change; the function did.

Suppose an unauthorized laptop attempts an administrative connection. A firewall rule that rejects the connection supplies a preventive result; a retained log of repeated denied attempts supplies evidence for a detective response. Check both outcomes before calling the same device a single control type. A block without matching evidence does not prove analysts can detect the pattern, and a log without enforcement does not prove the connection was stopped.

A good classification habit is to identify the undesired event first. Then ask whether the control tries to stop it, discover it, repair its effects, replace an unavailable control, discourage it, or instruct people how to behave.

Preventive controls try to stop the event

Preventive controls act before or during an unwanted action to reduce the chance that the action succeeds. Authentication, access control lists, firewall deny rules, application allowlisting, secure configuration, encryption requirements, and physical locks can all be preventive when they block or constrain behavior.

The defining question is: does the control directly make the undesired action harder or impossible? An access control list (ACL) that denies a source network from reaching an administrative interface is preventive because the prohibited connection is rejected.

Preventive does not mean perfect. A control can reduce probability without eliminating risk. Multi-factor authentication can prevent many credential-only account takeovers but can still be defeated by session theft, social engineering, or weak recovery procedures. Network segmentation can limit movement without stopping the initial compromise.

This matters because Security+ scenarios are often about the “best next control,” not an imaginary control that guarantees safety. A preventive measure is appropriate when the requirement is to block an action before damage occurs.

Detective controls provide evidence that something happened

Detective controls identify conditions, policy violations, anomalies, or security events. Logs, intrusion detection, security monitoring, file-integrity monitoring, audit trails, camera review, alerting, and many scanning activities can serve a detective role. Their value is visibility rather than direct prevention.

A detective control can operate in real time or after the event. An alert from endpoint telemetry may identify malicious behavior as it happens. A log review may discover unauthorized access hours later. Both are detective because the primary function is to reveal activity that occurred or is occurring.

This distinction is especially useful when products contain both blocking and monitoring modes. An intrusion prevention system configured to block exploit traffic performs a preventive function. The same engine in detection-only mode is detective. Endpoint protection that automatically quarantines a malicious file has preventive or corrective behavior in addition to detection.

When reading a scenario, look for verbs such as identify, alert, monitor, audit, discover, detect, and report. Those clues usually point toward a detective function. But do not classify solely from one word; verify what the control actually does to the event.

Corrective controls limit damage or restore a secure state

Corrective controls act after a problem has occurred to contain its effects, remove the cause, or return the system to an acceptable state. Restoring data from backup, reimaging a compromised workstation, applying a remediation after vulnerability discovery, rotating exposed credentials, and removing malicious persistence can all be corrective.

The timing distinction is useful. A preventive control asks, “How do we stop this from happening?” A corrective control asks, “Now that it happened, how do we fix or limit it?” Some technologies span both. Patch management is preventive when it closes a vulnerability before exploitation. Emergency patching after exploitation can be part of corrective incident response.

Backups are another good example. The backup process is often categorized as corrective because it enables restoration after loss or corruption. But backup architecture can also contain preventive or deterrent elements, such as immutability, isolation, and access controls that make destructive attacks less effective.

In exam scenarios, do not assume “after the event” means the organization failed. Mature security programs deliberately combine preventive, detective, and corrective controls because prevention will never cover every path.

Deterrent controls change the attacker’s decision

Deterrent controls try to discourage unwanted behavior by increasing perceived risk, effort, or consequences. Warning signs, visible guards, surveillance notices, login banners, lighting, fencing, and clearly communicated sanctions can be deterrent when they influence a person’s decision before the action.

Deterrence is psychological or behavioral. A camera can be detective because it records evidence. A prominently visible camera may also be deterrent because a person knows activity is being observed. A fence can be preventive because it physically obstructs access, while signage on the fence can be deterrent or directive.

This overlapping function is not a flaw in the classification system. It reflects reality. Security controls are layered precisely because one implementation can contribute to more than one risk treatment goal.

A useful exam technique is to choose the function that best matches the requirement stated in the question. If the goal is “discourage employees from attempting unauthorized access,” a warning banner or visible monitoring notice fits deterrence. If the goal is “record who entered the room,” access logs or video evidence are detective. Similar tools can answer different requirements.

Directive controls tell people what is required

Directive controls communicate required or expected behavior. Policies, standards, procedures, acceptable-use rules, security training instructions, posted requirements, and configuration baselines can be directive because they tell people or administrators what must be done.

A directive does not enforce itself. A password policy can require a minimum standard, while an identity platform setting enforces the requirement. The written policy is directive; the technical setting is preventive. Similarly, a data-handling procedure can direct employees to encrypt sensitive exports, while a data-loss prevention rule may technically block unauthorized transfer.

The distinction is valuable because governance depends on both. Technical controls without clear policy can be inconsistent, while policy without enforcement or monitoring can be ignored. Real environments usually combine directive controls with preventive and detective mechanisms.

In scenarios, look for requirements that define behavior, obligations, or process. “Employees must report suspected phishing within one hour” is directive. A mail security system that blocks malicious links is preventive. A monitoring system that flags suspicious mail is detective. The topic may be the same, but the control function is different.

Compensating controls provide comparable protection another way

A compensating control is used when a preferred or required control cannot be implemented as designed, but the organization can provide equivalent or comparable protection through another measure. Compensating does not mean “we did something weaker.” The replacement should address the same risk well enough to satisfy the security requirement or accepted risk decision.

Suppose a legacy application cannot support modern multi-factor authentication. A compensating design might place the application behind a strongly authenticated access gateway, limit it to a hardened administrative network, restrict users, monitor sessions closely, and add additional approval. The goal is not to pretend the missing control exists; it is to reduce the resulting risk through alternative safeguards.

Compensating controls therefore require context and risk analysis. A convenient alternative is not automatically equivalent. The organization should document why the primary control is infeasible, what risk remains, how the compensating measure provides comparable protection, and how long the exception will exist.

On Security+ questions, compensating is usually signaled by phrases such as “cannot implement,” “legacy system,” “temporary exception,” or “alternative control.” The best answer addresses the same risk rather than introducing an unrelated safeguard.

Administrative, technical, physical, and operational labels answer a different question

Control function is only one classification dimension. Security material also groups controls by how they are implemented: managerial or administrative, operational, technical, and physical. These labels should not be confused with preventive, detective, or corrective functions.

A technical control is implemented through technology, such as an access-control mechanism or security configuration. A physical control protects the built environment through barriers, locks or guards. Managerial controls include policies, governance and management decisions. Operational controls are performed through defined people-and-process activities, such as media handling or incident procedures. The official SY0-701 classification uses the word managerial; it should not be silently replaced by the broader informal label administrative.

One control can therefore have both a category and a function. A door lock is physical and preventive. Security awareness training is administrative or operational and directive. Endpoint monitoring is technical and detective. A documented recovery procedure is operational and directive, while executing that procedure after an incident is corrective activity.

When a question asks for “control type,” first determine which classification scheme the answers are using. Mixing dimensions is a common source of confusion. The scenario may describe a technical control but ask which function it serves.

Classify by the scenario’s stated objective

The safest way to choose a control type is to ignore the product label at first and identify the desired outcome. If the requirement says stop, block, restrict, or prevent, think preventive. If it says identify, alert, monitor, or record, think detective. If it says restore, remediate, contain, or repair, think corrective. If it says discourage, think deterrent. If it says require, instruct, or define, think directive. If it says an intended control cannot be used and an equivalent safeguard is needed, think compensating.

Then check whether the proposed control truly performs that function in the scenario. A firewall is not automatically preventive if the question is about reviewing its logs. A camera is not automatically detective if its visible presence is being used to discourage trespassing. A backup is not automatically corrective if the question is about an isolated immutable copy reducing attacker leverage.

The practical skill is classification by intent. Security architecture is built from layered controls that overlap, reinforce one another, and fail in different ways. Understanding the function each control is serving makes it easier to identify gaps and choose the next safeguard deliberately.