6.1 The Core Authorization Package & Supporting Artifacts

6.1 The Core Authorization Package & Supporting Artifacts

Within the NIST Risk Management Framework (RMF) and the ISC2 CGRC Common Body of Knowledge (CBK), Step 5: Authorize represents the formal culmination of governance, security engineering, and independent evaluation. The purpose of this step is to achieve executive accountability: an authorized senior leader evaluates the risks to organizational operations, organizational assets, individuals, other organizations, and the nation, and explicitly determines whether those residual risks are acceptable to support the organization's mission.

To make an informed, credible, and defensible risk determination, the Authorizing Official (AO) cannot rely on verbal assurances or superficial summaries. Instead, the AO relies on a formal, standardized dossier known as the Security and Privacy Authorization Package (often abbreviated as the Authorization Package), governed by NIST SP 800-37 Revision 2 (Risk Management Framework for Information Systems and Organizations).

---

The Three Core Mandatory Artifacts

Under NIST SP 800-37 Rev. 2 (Task A-1), the Authorization Package is composed of three primary mandatory documents. Together, these three artifacts tell the complete story of a system's security posture: how it was planned and built, how it actually performed under rigorous assessment, and how outstanding weaknesses will be remediated.

┌─────────────────────────────────────────────────────────────────────────────┐
│               THE THREE MANDATORY CORE AUTHORIZATION ARTIFACTS               │
│                                                                             │
│  ┌─────────────────────────┐ ┌─────────────────────────┐ ┌───────────────┐  │
│  │  System Security &      │ │   Security & Privacy    │ │    Plan of    │  │
│  │  Privacy Plan (SSP)     │ │ Assessment Report (SAR) │ │  Action and   │  │
│  │                         │ │                         │ │  Milestones   │  │
│  │ • System Boundary       │ │ • Assessor Findings     │ │    (POA&M)    │  │
│  │ • Security Categorization│ │ • Satisfied vs. Other   │ │               │  │
│  │ • Baseline Controls     │ │   Than Satisfied        │ │ • Corrective  │  │
│  │ • Implementation Detail │ │ • Vulnerability Evidence│ │   Milestones  │  │
│  │ • Control Allocations   │ │ • Residual Risk Summary │ │ • Resources   │  │
│  └─────────────────────────┘ └─────────────────────────┘ └───────────────┘  │
│               │                           │                      │          │
│               └─────────────────────┬─────┴──────────────────────┘          │
│                                     ▼                                       │
│               ┌───────────────────────────────────────────┐                 │
│               │       AUTHORIZING OFFICIAL (AO) REVIEW     │                 │
│               │   Risk-Based Authorization Determination  │                 │
│               └───────────────────────────────────────────┘                 │
└─────────────────────────────────────────────────────────────────────────────┘

1. System Security and Privacy Plan (SSP / SSPP)

• Primary Purpose: Serves as the authoritative, comprehensive blueprint of the information system. It describes the security and privacy requirements established for the system and the controls in place (or planned) to satisfy those requirements.
• Governing Guidance: NIST SP 800-18 Rev. 1 (Guide for Developing Security Plans for Federal Information Systems) and NIST SP 800-53 Rev. 5.
• Core Components Required:
  • System Name, Identifier, and Operational Status: Unique identification number, operational state (e.g., Operational, Under Development, Major Modification).
  • System Ownership and Key Roles: Names and contact details for the Information System Owner (ISO), Information System Security Officer (ISSO), Authorizing Official (AO), and System Custodians.
  • System Categorization and Impact Levels: FIPS 199 / NIST SP 800-60 security categorization ratings across the triad (Confidentiality, Integrity, and Availability) and overall system impact rating.
  • Authorization Boundary Definition: Precise technical description and architectural schematics defining what hardware, software, firmware, internal/external subnets, cloud VPCs, and data flows reside inside versus outside the boundary.
  • Operational Environment and Architecture: Description of hosting facilities, network topology, interconnected systems, operating systems, hypervisors, and data repositories.
  • Control Allocation and Implementation Statements: Granular narrative statements for every applicable control and enhancement in the baseline (e.g., AC-2, IA-5, SC-7), clearly stating whether the control is System-Specific, Inherited (Common Control), or Hybrid, and documenting exactly how the control is implemented (specifying tools, configurations, roles, and automated workflows).

2. Security and Privacy Assessment Report (SAR)

• Primary Purpose: Documents the independent, empirical findings and conclusions reached by the Security Control Assessor (SCA) during RMF Step 4 (Assess). It provides the unvarnished reality of whether controls are implemented correctly, operating as intended, and producing the desired security outcome.
• Governing Guidance: NIST SP 800-53A Rev. 5 (Assessing Security and Privacy Controls in Information Systems and Organizations).
• Core Components Required:
  • Executive Summary: High-level overview of assessment scope, methodology, assessor independence statement, and overarching risk posture.
  • Control Effectiveness Determinations: Formal binary rating for each evaluated control enhancement—either Satisfied (implemented correctly and operating effectively) or Other Than Satisfied (deficient, partially implemented, misconfigured, or ineffective).
  • Assessment Findings and Vulnerability Evidence: Detailed descriptions of every identified vulnerability, technical scan results (e.g., DISA STIG compliance checklists, Nessus/Qualys vulnerability scan outputs, penetration test logs), and configuration discrepancies.
  • Root Cause Analysis: Investigation into why each control failed (e.g., lack of automated patch orchestration, inadequate staffing, unmanaged vendor dependencies).
  • Assessor Risk Recommendations: Technical and operational remediation guidance formulated by the assessor to mitigate identified vulnerabilities before or after authorization.

3. Plan of Action and Milestones (POA&M)

• Primary Purpose: The formal corrective action plan that documents the organization's planned remediation actions for all control weaknesses, vulnerabilities, and "Other Than Satisfied" findings identified in the SAR and continuous monitoring.
• Governing Guidance: OMB Memorandum M-02-01, FISMA (44 U.S.C. § 3554), and NIST SP 800-37 Rev. 2.
• Core Components Required: Specific weakness descriptions, assigned points of contact (POCs), resource and funding requirements, milestone schedules with interim completion targets, and scheduled completion dates.

---

Critical Supporting Artifacts

While the SSP, SAR, and POA&M form the core triad, an Authorizing Official cannot assess system risk in a vacuum. Comprehensive authorization packages incorporate several critical supporting artifacts that provide operational, architectural, and legal context:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     KEY SUPPORTING AUTHORIZATION ARTIFACTS                  │
│                                                                             │
│  ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────┐  │
│  │ Risk Assessment (RAR) │ │ Contingency Plan(ISCP)│ │ Incident Response │  │
│  │ • Threat Likelihood   │ │ • BIA & RTO/RPO       │ │ • Triage & Contain│  │
│  │ • Threat Impact       │ │ • Annual CP-4 Drill   │ │ • US-CERT Escalate│  │
│  └───────────────────────┘ └───────────────────────┘ └───────────────────┘  │
│  ┌───────────────────────┐ ┌───────────────────────┐ ┌───────────────────┐  │
│  │ Interconnection (ISA) │ │ Privacy Impact (PIA)  │ │ Continuous Mon.   │  │
│  │ • MOU / MOA           │ │ • SORN (Privacy Act)  │ │ • ISCM Strategy   │  │
│  │ • Data Flow & Crypto  │ │ • PII Safeguards      │ │ • Scan Frequencies│  │
│  └───────────────────────┘ └───────────────────────┘ └───────────────────┘  │
└─────────────────────────────────────────────────────────────────────────────┘

1. Risk Assessment Report (RAR)

• Developed in accordance with NIST SP 800-30 Rev. 1 (Guide for Conducting Risk Assessments).
• Identifies threat sources (adversarial, accidental, environmental, structural), threat events, systemic vulnerabilities, pre-mitigation likelihood, impact severity, and post-mitigation residual risk scores.
• Synthesizes technical SAR findings into organizational mission/business impact terms.

2. Information System Contingency Plan (ISCP) & CP-4 Evidence

• Governed by NIST SP 800-34 Rev. 1 (Contingency Planning Guide for Federal Information Systems).
• Incorporates the Business Impact Analysis (BIA), identifying Mission Essential Functions (MEFs), Recovery Time Objectives (RTO), and Recovery Point Objectives (RPO).
• Must include concrete evidence of annual contingency plan testing, tabletop exercises, or live disaster recovery failover drills (CP-4).

3. Incident Response Plan (IRP) & IR-3 Testing

• Governed by NIST SP 800-61 Rev. 2 (Computer Security Incident Handling Guide).
• Outlines formal procedures for incident detection, triage, containment, eradication, recovery, and mandatory external reporting (e.g., CISA / US-CERT within 1 hour for major federal incidents).
• Includes evidence of annual incident response testing and simulated tabletop exercises (IR-3).

4. Interconnection Security Agreements (ISAs) and MOUs/MOAs

• Governed by NIST SP 800-47 (Security Guide for Interconnecting Information Systems) and control CA-3.
• Memorandum of Understanding / Agreement (MOU/MOA): High-level administrative agreement defining the operational purpose, business need, and authority for connecting two distinct systems.
• Interconnection Security Agreement (ISA): Technical agreement specifying interface mechanisms, communication protocols, encryption ciphers (FIPS 140-2/3 validated), IP addressing, data sensitivity levels, and mutual incident response obligations.

5. Privacy Documentation: PIA and SORN

• Mandated by the E-Government Act of 2002 (Section 208) and the Privacy Act of 1974 whenever a system collects, processes, stores, or transmits Personally Identifiable Information (PII).
• Privacy Impact Assessment (PIA): Analyzes how PII is handled, ensuring compliance with privacy laws and minimizing privacy risks.
• System of Records Notice (SORN): Formal legal notice published in the Federal Register describing the existence, character, purpose, and routine uses of any record system containing PII retrieved by personal identifiers (e.g., SSN, name).

6. Information Security Continuous Monitoring (ISCM) Strategy

• Governed by NIST SP 800-137 (Information Security Continuous Monitoring for Federal Information Systems and Organizations).
• Establishes automated metric collection schedules, vulnerability scanning frequencies, configuration compliance checks, and ongoing risk status reporting.

---

Summary Comparison: Core vs. Supporting Artifacts

---

Digital Authorization Platforms & OSCAL Standardization

Historically, authorization packages consisted of thousands of pages of static word processor documents and spreadsheets. In modern enterprise and cloud environments, organizations have transitioned to automated GRC management platforms and standardized data exchange formats.

Enterprise Digital Governance Platforms

• eMASS (Enterprise Mission Assurance Support Service): The automated web-based GRC application utilized across the Department of Defense (DoD) and Intelligence Community to manage RMF lifecycles, store artifacts, track POA&Ms, and route digital authorization packages for AO signature.
• CSAM (Cyber Security Assessment and Management): The web-based GRC platform widely deployed across federal civilian agencies (e.g., DOJ, DHS, Treasury) to inventory systems, manage NIST SP 800-53 control baselines, monitor FISMA compliance, and generate executive risk dashboards.

OSCAL (Open Security Controls Assessment Language)

Developed by NIST, OSCAL is a set of standardized, machine-readable XML, JSON, and YAML formats designed to automate the authoring, exchange, and processing of security control baselines, System Security Plans (SSPs), assessment plans (SAPs), assessment results (SARs), and POA&Ms.

[!TIP] Why OSCAL Matters for CGRC: OSCAL enables continuous compliance and automated authorization by transforming static compliance paperwork into machine-readable code. Cloud Service Providers (CSPs) and tool vendors can auto-generate SSP implementation statements and assessment results directly from CI/CD pipeline scans, drastically reducing authorization timelines.

---

Real-World RMF Scenario: The Incomplete Authorization Package

Scenario: A healthcare agency's IT modernization team submits an authorization package to the Authorizing Official (AO) for a new patient scheduling cloud application. The package contains a beautifully written System Security Plan (SSP) and a comprehensive Assessment Report (SAR) completed by an independent assessor. However, the team omitted the Plan of Action and Milestones (POA&M), claiming that because they resolved all "High" severity findings during testing, a POA&M was not required for the remaining 14 "Moderate" and "Low" findings.

GRC Action: The AO Designated Representative (AODR) immediately returns the package without presenting it to the AO for signature. Under NIST SP 800-37 Rev. 2 and OMB policy, an authorization package is incomplete and legally invalid without all three core mandatory artifacts (SSP, SAR, POA&M). Every unremediated finding in the SAR—regardless of severity—must be cataloged in a formal POA&M with assigned POCs, resource allocations, and milestone delivery dates.

---

Common Exam Traps

• ⚠️ Trap: Assuming that only the System Security Plan (SSP) is mandatory and other reports are optional. The SSP, SAR, and POA&M are all mandatory core artifacts required for every authorization decision.
• ⚠️ Trap: Confusing an MOU/MOA with an ISA. An MOU/MOA defines the high-level business relationship and organizational intent, whereas an Interconnection Security Agreement (ISA) establishes the precise technical parameters, encryption protocols, and security controls for the data link.
• ⚠️ Trap: Believing a System of Records Notice (SORN) is only required if a data breach occurs. A SORN must be drafted and published in the Federal Register before operational system launch whenever PII is retrieved by personal identifiers.