Classifying Security Controls by Function and Implementation Type

Good to see you again. In the previous lesson, you separated a security scenario into its asset, threat, vulnerability, exploit, risk, and control. A control is the safeguard in that chain—but saying only “this is a control” is rarely enough. Security teams also need to state how the control is implemented and what role it plays in reducing risk.

By the end of this lesson, you should be able to assign both labels to a control, such as:

A firewall rule is a technical, preventive control.
A quarterly access review is an operational, detective control.

This vocabulary is useful in Security+ questions, architecture reviews, risk registers, audit discussions, and the kind of control decisions that come up when building and operating backend services.

---

A control has two independent labels

The key idea is that security controls can be classified along two axes:

1. Implementation type — What primarily carries out the safeguard?
2. Function — What security purpose does it serve?

A door lock and a firewall rule are implemented differently, but both can be preventive. A firewall log and a security guard’s patrol are implemented differently, but both can be detective.

A useful sentence structure is:

[Control] is a [implementation type] control whose primary function is [functional type].

For example:

• “Multi-factor authentication is a technical preventive control.”
• “A policy requiring privileged-access approval is a managerial directive control.”
• “An analyst reviewing anomalous login alerts is an operational detective control.”
• “A fire-suppression system is a physical corrective control.”

The labels are not competitors. They answer different questions.

---

Implementation type: how the control is put into effect

For Security+ purposes, use these four implementation categories.

Implementation type	Primary mechanism	Typical examples
Technical	Hardware, software, firmware, or automated system configuration	Firewalls, MFA enforcement, encryption, endpoint protection, logging, IDS
Managerial	Governance and management decisions that establish direction and accountability	Policies, standards, risk assessments, separation-of-duties rules, vendor requirements
Operational	People carrying out repeatable security processes	Security awareness training, access reviews, onboarding checks, incident handling, guard patrols
Physical	Protection of facilities, equipment, people, and environmental conditions	Locks, fences, badge-controlled doors, cameras, guards, fire suppression, generators

Technical controls

A technical control is primarily implemented through technology. It may run automatically, enforce a configuration, block an action, record evidence, or restore a system.

Backend-service examples include:

• a reverse proxy that rejects requests outside an allowed rate;
• a database configured to require encrypted connections;
• MFA enforced by an identity provider;
• a host firewall that permits inbound SSH only from an administration subnet;
• centralized logging that records failed authentication attempts;
• backups used to restore data after ransomware.

The important test is not whether someone configured the tool initially. Nearly every control requires human setup. The question is: does the system itself carry out the protection during normal operation? If yes, technical is usually the right implementation type.

Managerial controls

A managerial control establishes expectations, ownership, oversight, or required behavior. Its primary mechanism is governance rather than a software setting or a person’s individual day-to-day action.

Examples include:

• an access-control policy requiring least privilege;
• a standard requiring encryption for production database connections;
• a policy requiring code review before deployment;
• assigning an owner for each production service;
• a separation-of-duties requirement for sensitive financial changes;
• a documented incident-response plan.

A policy alone cannot block a malicious request. Its value comes from directing the organization and from being paired with operational, technical, and physical enforcement.

Operational controls

An operational control is performed by people as part of routine security work. Think of it as the process-in-action layer.

Examples include:

• HR verifying offboarding tasks when an employee leaves;
• administrators reviewing privileged accounts every quarter;
• an engineer following a change-management procedure;
• a security analyst investigating an alert;
• staff completing phishing-awareness training;
• a guard conducting a physical patrol.

A helpful distinction:

• The policy that requires access reviews is managerial.
• The people actually conducting the access reviews are implementing an operational control.
• A tool that automatically revokes expired access may be a technical control.

The same security objective can therefore involve several implementation types.

Physical controls

A physical control protects the physical environment: facilities, equipment, people, and environmental conditions. It is not limited to “things you can touch” in a simplistic sense; it includes physical safeguards such as controlled entry, surveillance, and fire suppression.

Examples include:

• locked data-center doors;
• fences and gates;
• badge readers protecting a server room;
• CCTV cameras around a facility;
• fire extinguishers and suppression systems;
• backup generators;
• temperature and humidity controls for hardware.

Physical controls matter to backend services because a well-designed API cannot stay available if its hosting equipment, network equipment, or staff workspace is physically compromised or damaged.

A terminology caution: “administrative”

You will often see administrative controls in resources and job discussions. The word is used inconsistently:

• It often means approximately the same thing as managerial controls: policies, governance, management oversight, and formal rules.
• In some frameworks, administrative is a broader category that includes both governance and people-driven processes.

For this course and Security+ preparation, keep managerial and operational distinct:

• Managerial: establishes the rule, ownership, or oversight.
• Operational: performs the recurring work required by that rule.

When working in an organization, use its stated taxonomy consistently rather than trying to force terminology from a different framework onto it.

---

Function: what the control is meant to do

Now classify the control by its intended security role. This is usually easiest if you imagine where it acts in the path from attempted attack to recovery.

Functional type	Core question	Main purpose	Example
Preventive	“Does it stop or reduce the chance of the unwanted action?”	Block or limit an event before it succeeds	Server-side authorization check
Deterrent	“Does it make an attacker reconsider or expect consequences?”	Discourage an attempt	Authorized-use warning banner
Detective	“Does it reveal that something suspicious or harmful happened?”	Observe, record, or alert	Alert on unusual API-key usage
Corrective	“Does it fix the condition or restore service after discovery?”	Remediate, contain, repair, or recover	Patch a vulnerable service; restore backups
Compensating	“Is it an alternative when the preferred control is not feasible?”	Reduce risk by another means	Segment an unpatchable legacy server
Directive	“Does it instruct people to act securely?”	Specify required secure behavior	Secure-data-handling procedure

The image below shows the two-axis idea in a simplified matrix. It uses physical, technical, and administrative implementation categories and focuses on the three especially common functional labels: preventive, detective, and corrective.

Preventive controls

A preventive control reduces the likelihood that an unwanted action succeeds. It acts before or during the attempted event.

Examples:

• Technical: MFA, firewall rules, endpoint malware blocking, server-side authorization, encryption access controls
• Managerial: a policy requiring approval before production access is granted
• Operational: a mandatory peer-review process before deployments
• Physical: locks, gates, badge-controlled doors

For a backend service, authorization is one of the clearest examples. If an authenticated user requests /orders/8492, the server must determine whether that user is entitled to read order 8492. The server-side ownership check is a technical preventive control because it blocks unauthorized access before data is returned.

A log entry about the unauthorized request would be valuable, but it is not a substitute for authorization. Logging is typically detective; it sees the event rather than preventing it.

Deterrent controls

A deterrent control discourages malicious or unauthorized behavior by increasing the perceived chance of being caught, the expected consequence, or the effort required. It may not technically stop an attack.

Examples include:

• a login banner warning that access is monitored;
• a sign stating “Authorized Personnel Only”;
• clearly communicated disciplinary consequences for misuse of privileged access;
• visible cameras or security personnel.

A warning banner is often a technical deterrent. A sign on a door is usually a physical deterrent. A policy that states consequences for policy violations is a managerial deterrent.

A deterrent should not be overvalued. A banner does not stop a credential-stuffing script, and a sign does not stop someone who has already decided to enter. Deterrence is most useful as one layer among stronger controls.

Detective controls

A detective control identifies, records, or alerts on suspicious activity, policy violations, failures, or confirmed incidents. It often does not prevent the initial event.

Examples include:

• API audit logs;
• intrusion-detection alerts;
• suspicious-login alerts;
• file-integrity monitoring;
• quarterly privileged-access reviews;
• CCTV footage;
• guard patrols;
• smoke detectors.

For an API, an alert when one account downloads an unusually large number of exports is a technical detective control. An analyst examining that alert is part of an operational detective control.

Detection is useful only if the organization can respond. Producing logs that nobody reviews is weaker than a monitored detection process with clear ownership and escalation.

Corrective controls

A corrective control acts after a problem has been discovered. It fixes a weakness, limits the event’s continuing effects, restores service, or helps return the environment to a known-good state.

Examples include:

• patching a vulnerable library;
• disabling or rotating a compromised API key;
• restoring a database from a tested backup;
• reissuing a lost access badge;
• repairing a damaged lock;
• activating fire suppression;
• following incident-response procedures to contain an affected system.

A patch may be called technical corrective because it removes the discovered technical weakness. A restore from backup is also generally technical corrective because it recovers data or service after damage.

Corrective does not mean “perfectly undoing the past.” Restoring a database may restore availability and integrity, but it cannot erase the fact that an attacker may already have copied confidential data. That is why prevention and detection remain essential.

Directive controls

A directive control tells people what secure behavior is expected. It establishes required actions, constraints, or procedures.

Examples include:

• an acceptable-use policy;
• a secure coding standard;
• a data-classification and handling procedure;
• security awareness training;
• a sign directing visitors to check in at reception;
• a runbook that specifies how engineers request elevated access.

Directive controls depend on people following them, so they are not sufficient on their own for high-risk actions. For example, “developers must not log secrets” is useful guidance, but it should be reinforced with technical secret scanning, access controls, and review processes.

Compensating controls

A compensating control is an alternative safeguard used when the preferred or primary control cannot currently be implemented. It should pursue the same security objective or reduce the remaining risk to an acceptable level.

Suppose a legacy reporting service has a critical vulnerability, but the vendor cannot provide a patch for three months. The preferred control is to patch or replace the service. Until that is possible, the organization might:

• restrict access to a single internal network segment;
• allow requests only through a hardened proxy;
• block unneeded ports with a firewall;
• require additional authentication;
• closely monitor its activity.

Network segmentation in this case is a technical preventive compensating control. It is not merely “another good control.” It is specifically compensating for the missing patch.

Compensating controls should be documented with:

• the primary control that is unavailable;
• the risk that remains;
• why the alternative is adequate for now;
• an owner and review date;
• a plan to implement the primary control when feasible.

This prevents temporary workarounds from becoming invisible permanent weaknesses.

---

Classify the control, not the entire situation

Controls can appear ambiguous when the object being classified is too broad. Break the situation into its separate parts.

Consider ParcelTrack’s production environment:

The company requires manager approval for production access. Engineers submit access requests through a ticketing workflow. The identity platform enforces role-based permissions and MFA. Audit logs record privileged actions, and the security team reviews unusual activity. A legacy reporting service cannot be patched immediately, so it is isolated behind a restrictive firewall rule. Database backups are tested monthly.

Here is a precise classification.

Specific control	Implementation type	Primary function	Why
Requirement for manager approval	Managerial	Directive	Establishes a formal requirement for secure access decisions
Engineers submitting access requests	Operational	Directive	People follow a defined access-request process
Role-based permissions and MFA enforcement	Technical	Preventive	System blocks access that lacks required identity or privilege
Privileged-action audit logs	Technical	Detective	System creates evidence of actions
Reviewing unusual audit activity	Operational	Detective	People identify suspicious behavior from evidence
Restrictive firewall around unpatchable service	Technical	Preventive, compensating	Reduces exploitability while the preferred patch is unavailable
Tested database backup restoration	Technical plus operational process	Corrective	Enables recovery after corruption, deletion, or ransomware

Two principles prevent many classification errors:

1. Classify the specific artifact or action.
   “Access management” is too broad. A policy, ticket workflow, IAM rule, and quarterly review are separate controls with different classifications.

2. Choose the primary function, then add a second label only when it genuinely matters.
   A firewall that blocks traffic is primarily preventive. If it also creates logs, it has a detective capability—but do not label every firewall “all functions” without explaining the configuration and use case.

---

Defense in depth: controls should work as layers

A secure design does not assume that a single control will work forever. Prevention can fail due to a bug, misconfiguration, stolen credential, insider misuse, or an entirely different attack path. Defense in depth means selecting controls that address the risk at multiple points.

For a backend API handling merchant data, a layered design might include:

• Preventive: MFA for administrators, least-privilege database roles, authorization checks, network segmentation, rate limits.
• Detective: authentication logs, audit trails for exports, anomaly alerts, access reviews.
• Corrective: a process to revoke compromised credentials, patching procedures, tested backups, and a service-recovery runbook.
• Directive and deterrent: secure coding standards, acceptable-use rules, training, and monitored-access notices.
• Compensating: a restrictive proxy or network isolation around a legacy component until it can be modernized.

This is not a request to put one control in every possible box. Controls should be chosen to address a defined risk. For example:

• Rate limiting may slow bulk data extraction, but it does not fix missing object-level authorization.
• Encryption may protect stored data, but it does not prevent an authorized yet malicious administrator from reading it.
• Backups may restore a damaged database, but they do not detect the attacker or prevent initial compromise.

Each layer should make a distinct contribution.

---

A practical classification workflow

When you encounter a proposed safeguard in a ticket, security review, or exam question, classify it in this order:

1. State the control precisely.
   Avoid vague labels such as “access security” or “monitoring.”

2. Ask what primarily implements it.
   Is it technology, governance, a people-run process, or a physical safeguard?

3. Ask what it is intended to accomplish.
   Does it prevent, deter, detect, correct, direct behavior, or compensate for an unavailable primary control?

4. Identify its primary role in the risk chain.
   A control can have secondary benefits, but lead with its main purpose.

5. Check whether it is only a partial solution.
   If it substitutes for an unavailable preferred control, label it compensating and record the limitation.

For your own notes or portfolio work, use a compact control-register format:

Control	Risk addressed	Implementation type	Function	Owner	Evidence it operates
MFA for production console	Credential theft leading to privileged access	Technical	Preventive	Identity team	Identity-provider policy and authentication logs
Quarterly privileged-access review	Excessive or stale privileges	Operational	Detective	Service owner	Completed review record
Legacy-service network isolation	Exploitation of unpatchable vulnerability	Technical	Preventive, compensating	Platform team	Firewall rules and validation results

The final column matters. A documented control is not automatically an operating control. A policy should have evidence of adoption; an alert should have evidence that it is reviewed; a backup should have evidence that restoration actually works.

---

Key takeaways

• Every security control can be described by both implementation type and function.
• The four Security+ implementation types are technical, managerial, operational, and physical.
• The six common functional types are preventive, deterrent, detective, corrective, compensating, and directive.
• Managerial controls establish governance and requirements; operational controls are the people-run processes that carry them out.
• Compensating is a special label: it describes an alternative used when the preferred control cannot be implemented.
• Defense in depth combines controls that prevent, detect, and correct rather than relying on a single safeguard.
• Classify the specific control artifact or action, not a vague whole program.

Next, you will begin describing a system before defending it: marking assets, data flows, entry points, and trust boundaries on a simple architecture diagram.