4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes
Key Takeaways
- The CGRC blueprint names four control types — management, technical, common, and operational — which combine two independent classification axes that must not be conflated.
- Management, operational, and technical describe the nature of a control; common, hybrid, and system-specific describe who implements it.
- NIST SP 800-53 Rev. 5 dropped the management/operational/technical class labels in favour of the twenty control families, but the CGRC outline still uses that vocabulary.
- Functional classes — preventive, detective, corrective, deterrent, recovery, directive, and compensating — describe what a control does when a threat materializes.
- One control can hold a label on every axis simultaneously, so exam items must be read for which axis is being asked about.
Identifying Control Types: Management, Operational, Technical and Functional Classes
The blueprint bullet reads: "Identification of control types (e.g., management, technical, common, operational control)." That list quietly mixes two different classification systems, and the resulting confusion is a reliable source of lost marks. A single control can carry a label on three separate axes at once, and exam items are written to test whether you know which axis is being asked about.
1. Axis One — Nature of the Control
This is the FIPS 200 / legacy SP 800-53 classification, describing what kind of thing the control is.
| Class | Description | Implemented By | Examples |
|---|---|---|---|
| Management | Controls addressing risk management and the governance of security. Policies, planning, assessment, authorization. | Managers and governance functions | Risk assessment (RA), planning (PL), security assessment and authorization (CA), acquisition policy (SA) |
| Operational | Controls executed primarily by people in day-to-day operations. | Operators, administrators, staff | Awareness and training (AT), configuration management (CM), contingency planning (CP), incident response (IR), physical protection (PE), personnel security (PS) |
| Technical | Controls executed primarily by the system through hardware, software, or firmware. | Automated mechanisms | Access enforcement (AC), identification and authentication (IA), audit generation (AU), cryptographic protection (SC) |
The discriminator is who or what executes the control. A guard checking badges is operational; a badge reader denying entry is technical; the policy stating that all entrants must be badged is management. All three may protect the same door.
[!IMPORTANT] A Revision 5 subtlety worth knowing. SP 800-53 Rev. 5 removed the management/operational/technical class labels, organizing controls solely into the twenty families and deliberately dropping the classification because many controls span classes — CM has policy, procedural, and automated elements simultaneously. The CGRC exam outline nevertheless still uses this vocabulary, so you must know both: the terms remain examinable, and you should also know that the current catalog no longer assigns them.
2. Axis Two — Implementation Responsibility
This axis is allocation, and it is orthogonal to the first. It answers who is responsible, not what kind of control it is.
| Type | Provided By | Documentation |
|---|---|---|
| Common (inherited) | A Common Control Provider serving many systems | Cite the provider's system, authorization status, and date |
| System-specific | The system owner alone | Full implementation statement in the SSP |
| Hybrid | Split between a provider and the system owner | Must state explicitly which portion each party owns |
Every control in a baseline resolves to exactly one of these three (or to a justified "not applicable"). Because the two axes are independent, a control can be both technical and common — enterprise multifactor authentication is a technical control provided commonly. A control can be operational and system-specific — an application-specific incident playbook. There is no correlation between the axes, and exam distractors are frequently built by implying one.
Why Common Controls Matter Economically
Common controls are the principal efficiency mechanism in the entire framework. When an organization provides physical security, enterprise identity, boundary protection, and awareness training centrally, every system afterwards inherits rather than rebuilds. A Moderate baseline system might inherit 40–60% of its controls, reducing per-system implementation and assessment cost proportionally. This is why cataloguing common controls is a founding activity of the compliance programme rather than a per-system decision.
3. Axis Three — Functional Class
This axis describes what a control does relative to the timeline of a threat event. It is standard security-professional vocabulary and appears throughout the exam.
| Class | Acts | Purpose | Example |
|---|---|---|---|
| Directive | Before | Mandates required behaviour | Acceptable use policy, rules of behaviour |
| Deterrent | Before | Discourages an actor from attempting | Warning banners, visible cameras, published sanctions |
| Preventive | Before / during | Stops the event occurring | Access enforcement, MFA, firewall rules, encryption |
| Detective | During / after | Identifies that it occurred | Audit logging, IDS, file integrity monitoring, log review |
| Corrective | After | Fixes the condition and limits damage | Patching, quarantine, account disablement, rollback |
| Recovery | After | Restores operations | Backups, failover, contingency plan execution |
| Compensating | Instead of | Provides equivalent protection when the specified control is infeasible | Isolated enclave in place of unsupported MFA |
Two exam-relevant observations. The same mechanism can occupy different classes depending on how it is used: a camera is deterrent when visible, detective when monitored, and forensic evidence when reviewed after an event. And defence in depth requires coverage across classes — a control set that is entirely preventive has no way to discover that prevention failed, which is precisely the architecture that produces multi-month undetected breaches.
4. Reading Type Questions Correctly
When a scenario asks for the "type" of a control, identify which axis the answer options belong to:
- If options are management / operational / technical → the question is about the nature of the control. Ask: does a manager, a person, or the system execute it?
- If options are common / hybrid / system-specific → the question is about allocation. Ask: who provides it — the enterprise, the system owner, or both?
- If options are preventive / detective / corrective / compensating → the question is about function. Ask: when in the threat timeline does it act, and what does it accomplish?
Worked example. Enterprise disk encryption, centrally managed, applied to every laptop:
- Nature: technical — enforced by software, not by a person.
- Allocation: common — provided centrally, inherited by systems.
- Function: preventive — it stops unauthorized disclosure from a lost device.
All three labels are simultaneously correct. Nothing in the scenario is contradictory; the labels simply answer different questions. Getting this right is largely a matter of reading the answer options before reasoning about the control.
An organization deploys centrally managed full-disk encryption to every enterprise laptop, and consuming systems inherit it. How is this control classified across the axes the CGRC outline uses?
A security architecture consists almost entirely of preventive controls — strong authentication, network segmentation, encryption, and strict access enforcement — with minimal logging and no log review process. What is the principal weakness of this design?
How did NIST SP 800-53 Revision 5 change the treatment of the management, operational, and technical control classes?