Study guide
4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes
ISC2 Certified in Governance, Risk and Compliance CGRC
Track your progress as you read
Finished sections get a check mark.
1 Introduction & Exam Overview
0.1 ISC2 CGRC Exam Structure, Logistics & Passing Strategy 0.2 NIST RMF 7-Step Lifecycle & GRC Architecture
2 Chapter 1: Security and Privacy Governance, Risk Management, and Compliance Program
1.1 Enterprise Governance & GRC Frameworks 1.2 Security and Privacy Objectives: CIA, Non-Repudiation and Privacy Concepts 1.3 Multi-Tier Risk Management & Assessment Methodologies 1.4 System Development Life Cycle and Information Life Cycle Management 1.5 Establishing and Operating the Compliance Program 1.6 Legal, Regulatory & Federal Compliance Drivers 1.7 Privacy Governance, Organizational Roles & ISC2 Code of Ethics
3 Chapter 2: Scope of the System
2.1 System Boundary Definition, Architectural Context & Types 2.2 Identifying Information Types with NIST SP 800-60 2.3 System Categorization Process & Impact Analysis (FIPS 199 / SP 800-60) 2.4 Impact and Risk Determination Under Non-Federal Frameworks 2.5 System Registration, Environment & Interconnection Agreements
4 Chapter 3: Selection and Approval of Framework, Security, and Privacy Controls
3.1 Control Catalogs & NIST SP 800-53 Rev. 5 Structure 3.2 Control Allocation & Inheritance Models 3.3 Control Tailoring, Scoping & Overlay Guidance 3.4 Data Handling and Marking Requirements 3.5 Documenting Control Selection and Securing Stakeholder Agreement 3.6 Continuous Monitoring Strategy & Control Selection Approval
5 Chapter 4: Implementation of Security and Privacy Controls
4.1 Developing the Implementation Strategy: Resourcing, Funding and Timeline 4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes 4.3 System Security and Privacy Plan (SSP/SSPP) Development 4.4 Security Engineering Principles & Technical Control Implementation 4.5 Secure Baseline Configuration & System Hardening 4.6 Implementing Compensating and Alternate Controls 4.7 DevSecOps, SDLC Integration & Supply Chain Risk Management 4.8 Documenting Control Implementation: Policies, Procedures, Plans and Risk Registers
6 Chapter 5: Assessment/Audit of Security and Privacy Controls
5.1 Security Assessment Plan (SAP) & Assessor Independence 5.2 Assessment Methods, Objects & Depth/Coverage 5.3 Assessment Execution, Vulnerability Scanning & Testing 5.4 Preparing the Initial Assessment/Audit Report 5.5 Selecting Risk Responses: Avoid, Accept, Share, Mitigate, Transfer 5.6 Stakeholder Collaboration, Corrective Action and Reassessment 5.7 Security Assessment Report (SAR) & Risk Findings Analysis 5.8 Developing the Risk Response Plan: Prioritization and Resources
7 Chapter 6: System Compliance and Authorization
6.1 The Core Authorization Package & Supporting Artifacts 6.2 Plan of Action and Milestones (POA&M) Architecture & Management 6.3 System Risk Acceptance Criteria and Stakeholder Concurrence 6.4 Authorization Decision Process & Decision Types 6.5 Residual Risk Acceptance, Terms of Authorization & Continuous ATO 6.6 Documenting and Communicating the Compliance Decision
8 Chapter 7: Compliance Maintenance and Continuous Monitoring
7.1 Continuous Monitoring Strategy & Operations (NIST SP 800-137) 7.2 Configuration Management & Security Impact Analysis (NIST SP 800-128) 7.3 Incident Response and Contingency Activities in Sustained Compliance 7.4 Awareness, Training, Evidence Collection and Monitoring-Strategy Revision 7.5 Ongoing Remediation, POA&M Sustainment & Annual Reviews 7.6 Event-Driven Reauthorization & System Decommissioning
4.2 Identifying Control Types: Management, Operational, Technical and Functional Classes
Key Takeaways Explain This Topic AI
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.
Last updated: August 2026
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.