Study guide
6.4 Authorization Decision Process & Decision Types
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
6.4 Authorization Decision Process & Decision Types
Key Takeaways Explain This Topic AI
The RMF Step 5 Authorization Decision Process consists of five discrete tasks (A-1 through A-5) culminating in an executive risk acceptance determination.
The Authorizing Official (AO) bears ultimate statutory and financial accountability for the risk of operating an information system; this executive accountability cannot be delegated to subordinate roles.
There are five primary authorization decision types: Authorization to Operate (ATO), Authorization to Operate with Conditions (Conditional ATO), Interim Authority to Test (IATT), Denial of Authorization to Operate (DATO), and Authority to Use (ATU).
An Authority to Use (ATU) is specifically leveraged in cloud environments (e.g., FedRAMP) when an agency relies on a Cloud Service Provider's underlying authorization while evaluating agency-specific customer controls.
Last updated: August 2026
6.4 Authorization Decision Process & Decision Types
In the cybersecurity governance lifecycle, risk management is not merely an engineering exercise; it is an executive business function. Technical assessors uncover vulnerabilities and security engineers implement safeguards, but neither group has the legal, fiduciary, or statutory authority to decide whether the organization should accept the residual risk of operating an IT system. That critical responsibility rests exclusively with the Authorizing Official (AO) .
Step 5: Authorize of the NIST Risk Management Framework (RMF) translates empirical assessment findings into a formal, binding executive decision governed by NIST SP 800-37 Revision 2 .
The Authorization Decision Lifecycle (RMF Step 5 Tasks)
NIST SP 800-37 Rev. 2 organizes Step 5 into five structured tasks executed sequentially by system stakeholders, assessors, and authorizing officials: ┌─────────────────────────────────────────────────────────────────────────────┐
- │ RMF STEP 5: AUTHORIZE TASK WORKFLOW │
- │ │
- │ ┌───────────────────────┐ │
- │ │ Task A-1: Prepare │ Assemble SSP, SAR, POA&M, and supporting │
- │ │ Authorization Package │ artifacts into a cohesive dossier. │
- │ └───────────┬───────────┘ │
- │ ▼ │
- │ ┌───────────────────────┐ │
- │ │ Task A-2: Compile & │ Transmit the authorization package to the AO │
- │ │ Submit Package │ via digital GRC portal (eMASS/CSAM). │
- │ └───────────┬───────────┘ │
- │ ▼ │
- │ ┌───────────────────────┐ │
- │ │ Task A-3: Determine │ AO/AODR evaluates residual risk against │
- │ │ System Risk │ organizational risk tolerance and mission needs. │
- │ └───────────┬───────────┘ │
- │ ▼ │
- │ ┌───────────────────────┐ │
- │ │ Task A-4: Authorize │ AO signs formal Authorization Decision Document │
- │ │ System Operation │ (ATO, Conditional ATO, IATT, DATO, ATU). │
- │ └───────────┬───────────┘ │
- │ ▼ │
- │ ┌───────────────────────┐ │
- │ │ Task A-5: Communicate │ Distribute decision to stakeholders, CIO, CISO, │
- │ │ Authorization Decision│ and external oversight (OMB/FISMA CyberScope). │
- │ └───────────────────────┘ │
- └─────────────────────────────────────────────────────────────────────────────┘
- Task Breakdown and Responsibilities
Task A-1 (Prepare Package): The Information System Owner (ISO), Information System Security Officer (ISSO), and Security Control Assessor (SCA) assemble the System Security and Privacy Plan (SSP), Security Assessment Report (SAR), Plan of Action and Milestones (POA&M), Risk Assessment Report (RAR), Contingency Plan, and Interconnection Agreements.
Task A-2 (Compile and Submit): The package is formally submitted to the AO or Authorizing Official Designated Representative (AODR) through official digital governance channels.
Task A-3 (Risk Determination): The AO assesses the residual risk to organizational operations, organizational assets, individuals, other organizations, and the nation. The AO reviews open POA&M items, the effectiveness of compensating controls, and the criticality of the mission supported.
Task A-4 (Risk Decision): The AO makes the formal authorization decision and issues a signed Authorization Decision Document defining the terms, conditions, and operational constraints.
Task A-5 (Communication): The authorization decision and residual risk posture are communicated across the enterprise, updating system inventories and federal reporting repositories.
The Sole Authority of the Authorizing Official (AO)
The role of the Authorizing Official is central to federal and enterprise cybersecurity governance:
Important
Non-Delegable Accountability: The Authorizing Official (AO) is a senior leader or executive with the statutory, operational, and budgetary authority to allocate resources and accept risk. While an AO may appoint an Authorizing Official Designated Representative (AODR) to perform preliminary reviews, coordinate staff analysis, and draft recommendations, the legal authority to sign an authorization decision cannot be delegated.
Joint Authorization Models
When an information system spans multiple organizational boundaries, involves joint defense/intelligence initiatives, or interconnects disparate federal agencies, a Joint Authorization may be executed:
Multiple AOs from participating entities jointly review the common Authorization Package.
The AOs sign a shared Authorization Decision Document, establishing mutual risk acceptance and shared oversight responsibilities.
Comprehensive Analysis of Authorization Decision Types
An Authorizing Official renders one of five formal authorization decisions based on the evaluated risk posture: ┌─────────────────────────────────────────────────────────────────────────────┐
- │ THE FIVE AUTHORIZATION DECISION TYPES │
- │ │
- │ ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────┐ │
- │ │ Full Authorization │ │ Conditional ATO │ │ Interim Authority │ │
- │ │ to Operate (ATO) │ │ (ATO w/ Conditions) │ │ to Test (IATT) │ │
- │ │ • Residual risk OK │ │ • Deficiencies exist │ │ • Operational │ │
- │ │ • Up to 3 years or │ │ • Strict 30-90 day fix│ │ network testing │ │
- │ │ ongoing continuous │ │ • Time-limited waiver │ │ • No live data │ │
- │ └───────────────────────┘ └───────────────────────┘ └───────────────────┘ │
- │ ┌─────────────────────────────────────────────────┐ ┌───────────────────┐ │
- │ │ Denial of Authorization to Operate (DATO) │ │ Authority to Use │ │
- │ │ • Unacceptable risk / major control failures │ │ (ATU) │ │
- │ │ • System halted, disconnected, or blocked │ │ • Cloud / FedRAMP │ │
- │ │ • Must remediate and re-assess before live ops │ │ • Leverages CSP │ │
- │ └─────────────────────────────────────────────────┘ └───────────────────┘ │
- └─────────────────────────────────────────────────────────────────────────────┘
- 1. Authorization to Operate (ATO)
Definition: A formal authorization granting full permission to operate an information system for a specified period and process, store, or transmit organizational data.
Risk Criteria: The AO determines that residual risk to mission operations, assets, and individuals is acceptable and that security controls are operating with sufficient effectiveness.
Validity Period: Traditionally granted for a static window (up to 3 years under legacy triennial cycles) or granted under an Ongoing Authorization / Continuous ATO model based on continuous monitoring telemetry.
2. Authorization to Operate with Conditions (Conditional ATO)
Definition: An interim authorization granted when the system demonstrates significant operational necessity, but possesses specific, known deficiencies that must be corrected before full authorization can be granted.
Operational Constraints: The AO issues strict, binding conditions (e.g., "System permitted to operate for 60 days on the condition that MFA is fully deployed across all database tiers by Day 30" ).
Timeframe: Strictly limited, typically lasting 30 to 90 calendar days . If the conditions and milestones are not met within the deadline, the Conditional ATO automatically expires or converts to a DATO.
3. Interim Authority to Test (IATT)
Definition: A specialized, temporary authorization granted solely to operate a system (or modified subsystem) in an operational network environment specifically to conduct developmental, operational, or security testing.
Operational Constraints: System is strictly prohibited from processing live production data (unless specific compensatory safeguards are formally approved). Network access is heavily firewalled and segmented.
Timeframe: Limited to the precise duration of the test window (typically 30 to 180 days ).
4. Denial of Authorization to Operate (DATO)
Definition: A formal executive determination that the residual risk of operating the system is unacceptable.
Operational Impact: The system is prohibited from entering service . If the system is already active, it must be immediately disconnected from the network, halted, or decommissioned.
Triggers: Grossly inadequate documentation, systemic failure of critical controls (e.g., unencrypted sensitive data in transit, unauthenticated administrative access), or unmanageable threat exposure.
5. Authority to Use (ATU)
Definition: A specialized authorization decision utilized primarily in Cloud Computing and FedRAMP contexts.
Mechanics: When an agency adopts a third-party Cloud Service Provider (CSP) that already possesses a FedRAMP Joint Authorization Board (JAB) ATO or Agency ATO, the customer agency does not re-assess the CSP's underlying infrastructure. Instead, the agency assesses its own internal Customer-Configured Controls (e.g., IAM policies, data encryption settings, key management) and issues an Authority to Use (ATU) permitting agency users to utilize the cloud service.
Comparison Matrix: Authorization Decision Types
Decision Type Primary Purpose Live Production Data Permitted? Standard Duration Primary Risk Posture
ATO Full operational deployment and mission execution. Yes Up to 3 years (or Continuous). Residual risk fully acceptable.
Conditional ATO Short-term operation while urgent deficiencies are fixed. Yes (with constraints). 30 to 90 days (firm cutoff). Residual risk elevated but temporarily tolerable.
IATT Operational network connectivity for testing only. No (Simulated / synthetic test data only). Duration of test window (30-180 days). High testing risk contained by strict network isolation.
DATO Prohibition of system operation. No (Immediate disconnection/halt). Immediate / Indefinite. Residual risk completely unacceptable.
ATU Agency consumption of authorized FedRAMP cloud service. Yes Aligned with FedRAMP CSP continuous monitoring. Leveraged CSP risk accepted; customer controls verified.
Real-World RMF Scenario: The Conditional ATO Deadline
Scenario: A defense logistics platform undergoes RMF Step 4 assessment prior to a critical military deployment. The SAR identifies that while perimeter firewalls and encryption are fully compliant, automated session termination ( SC-10 ) is failing on legacy warehouse barcode scanners. The operational commander requires the system immediately to support troop deployments.
GRC Action: The Authorizing Official refuses to grant a standard 3-year ATO due to the open session vulnerability, but recognizes the critical mission imperative. The AO issues an Authorization to Operate with Conditions (Conditional ATO) for 60 days . The binding terms state that the engineering team must deploy updated scanner firmware remediating SC-10 within 45 days. On Day 46, an independent assessor validates the fix, and the AO formally transitions the system to a full Authorization to Operate (ATO) .
Common Exam Traps
⚠️ Trap: Confusing an IATT with a Conditional ATO . An IATT is granted strictly for testing in a live environment (no operational data), whereas a Conditional ATO allows live operational data processing under strict time-bound remediation conditions.
⚠️ Trap: Believing the Authorizing Official Designated Representative (AODR) can sign the final ATO letter. The AODR can review, analyze, and recommend, but only the AO can sign the authorization decision.
⚠️ Trap: Assuming an Authority to Use (ATU) means the agency ignores security entirely. Under an ATU, the agency relies on the CSP's underlying FedRAMP authorization but remains fully responsible for assessing and authorizing its own customer-implemented controls .