6.4 Authorization Decision Process & Decision Types

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

---

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.