| Field | Value |
|---|---|
| Control ID | CA-06 |
| Control Name | Authorization |
| Framework | NIST SP 800-53 Revision 5 |
| Control Family | Assessment, Authorization, and Monitoring |
| Baselines | LOW MODERATE HIGH PRIVACY |
| Relevance | Organization (First Party) |
| Risk Severity | Low |
What This Control Requires
CA-06 requires organizations to designate an authorizing official who formally accepts risk and authorizes each information system to operate. This control is the governance backbone of your NIST SP 800-53 authorization process, ensuring that no system enters production without explicit, documented management approval.
Specifically, the responsibilities of the authorizing official (AO) extend beyond individual systems. Your organization must also assign an authorizing official for common controls, the shared security capabilities that multiple systems inherit. Before a system begins operations, the AO must confirm acceptance of inherited common controls and then issue a formal authorization to operate (ATO). This two-layer structure prevents gaps where one team assumes another has accepted the risk but neither actually has.
But authorization isn’t a one-time event. CA-06 requires your organization to update authorizations at a defined frequency, tying ongoing authorization decisions to evidence produced by your continuous monitoring program. When continuous monitoring is mature, it replaces the need for periodic full reauthorization by keeping the authorization package current with real-time security posture data.
Why It Matters
Without a formal authorization process, your organization operates systems whose risk has never been explicitly accepted by someone with the authority and accountability to do so. That creates a governance vacuum. Auditors flag it, and regulatory bodies treat it as a material weakness in your security program.
The result is concrete audit exposure. Failure to maintain CA-06 may result in certification withdrawal or regulatory findings. Federal agencies face particular exposure; authorization is a federal responsibility under the Federal Information Security Modernization Act (FISMA), and operating without a valid ATO can trigger funding holds or program shutdowns. For organizations pursuing NIST compliance, CA-06 is foundational because it ties every other control family’s outputs into a single risk acceptance decision.
In practice, the absence of a named AO creates an accountability gap. When no one is formally responsible for accepting system risk, security findings languish without remediation owners. Plans of action and milestones (POA&Ms) go stale, and security plans drift from reality.
What Attackers Exploit
- Orphaned systems with no current authorization. Systems running past their ATO expiration often lack current patching and monitoring, making them attractive targets.
- Unclear common control inheritance. When system owners assume inherited controls are someone else’s problem, gaps in implementation go undetected.
- Stale authorization packages. Security plans that haven’t been updated in years may not reflect current architecture, creating blind spots in vulnerability management.
- Shadow IT outside the authorization boundary. Systems that never entered the authorization process often bypass security controls entirely.
- Delayed remediation due to missing risk owners. Without an AO accountable for the system’s risk posture, critical vulnerabilities can persist for months.
How to Implement
For Your Organization
The core challenge with CA-06 isn’t technical; it’s organizational. Authorization requires clear role definitions, documented decision-making authority, and a process that connects risk assessment outputs to formal management acceptance. Many organizations struggle because they treat authorization as a checkbox rather than as an ongoing governance function.
Step 1: Designate authorizing officials. Identify and formally appoint a senior official for system authorization and a separate (or the same, depending on organizational structure) official for common controls. Document these appointments in writing with clear scope of authority. The AO must have sufficient seniority to accept risk on behalf of the organization and allocate resources for remediation.
Step 2: Define the authorization boundary for each system. Before an AO can authorize a system, the system’s boundary must be clearly defined. This includes all hardware, software, data flows, and interconnections. Map which common controls the system inherits and from which providers.
Step 3: Assemble the authorization package. The package must include the system security plan (SSP), the security assessment report (SAR), and the plan of action and milestones (POA&M). The AO reviews these documents to understand residual risk before making an authorization decision.
Step 4: Conduct the authorization decision. The AO reviews the authorization package, accepts inherited common controls, and issues a formal authorization statement. This statement should specify any conditions, time limits, or risk acceptance caveats. Use your organization’s compliance checklist to verify completeness.
Step 5: Establish ongoing authorization. Define the frequency and triggers for authorization updates. Tie authorization renewal to your continuous monitoring program so the AO receives ongoing evidence of security posture rather than relying solely on point-in-time assessments.
Step 6: Manage common control authorizations separately. The common control provider must maintain their own authorization documentation. System owners who inherit these controls need visibility into the provider’s authorization status and any changes that affect inherited protections.
Common Mistakes to Avoid
- Assigning the AO role to someone without actual decision-making authority or budget control
- Treating ATO as a one-time milestone rather than an ongoing responsibility
- Failing to document the acceptance of inherited common controls before system operation
- Allowing authorization packages to become outdated between formal reviews
- Not establishing clear communication channels between common control providers and system owners who inherit those controls
Organizations managing third-party risk requirements under NIST 800-53 should coordinate their vendor assessment timelines with authorization renewal cycles, since changes in third-party posture can affect the system’s risk profile.
Evidence Examples
| Evidence Type | Example Artifact |
|---|---|
| Authorization appointment | Signed memorandum designating the senior official as authorizing official for a specific system or set of common controls |
| Authorization statement | Formal ATO letter specifying system name, authorization boundary, risk acceptance conditions, and expiration date |
| System security plan | Current SSP documenting implemented controls, system architecture, and authorization boundary |
| Security assessment report | SAR from the most recent control assessment with findings, risk ratings, and recommended mitigations |
| Plan of action and milestones | Active POA&M tracking open findings with remediation owners, target dates, and status updates |
| Common control inheritance documentation | Mapping of inherited controls with provider authorization status and accepted residual risk |
| Authorization review records | Meeting minutes or decision logs from periodic authorization reviews tied to continuous monitoring outputs |
| Continuous monitoring evidence | Dashboard reports or automated feeds showing ongoing security posture data provided to the AO |
Cross-Framework Mapping
No cross-framework mappings are currently configured for this control.
Related Controls
- CA-02 — Control Assessments: provides the assessment results that feed directly into the AO’s authorization decision and the security assessment report.
- CA-03 — Information Exchange: governs the interconnection agreements that must be reviewed as part of defining the authorization boundary.
- CA-07 — Continuous Monitoring: supplies the ongoing evidence that supports continuous authorization and reduces the need for full reauthorization.
- PM-09 — Risk Management Strategy: establishes the organizational risk tolerance that the AO uses as a benchmark when accepting system risk.
- PM-10 — Authorization Process: defines the organization-wide authorization process, roles, and responsibilities that CA-06 implements at the system level.
- RA-03 — Risk Assessment: produces the risk findings the AO must evaluate before issuing or renewing an authorization.
- SA-10 — Developer Configuration Management: ensures that development-phase configuration controls are documented and available for authorization review.
- SI-12 — Information Management and Retention: governs retention requirements for authorization records, security plans, and assessment documentation.
Frequently Asked Questions
What Is NIST SP 800-53 CA-06?
CA-06 is the NIST SP 800-53 control that requires organizations to formally designate authorizing officials and obtain explicit authorization before operating information systems. It ensures that a senior official reviews the system’s security posture, accepts residual risk, and issues a documented authorization to operate. The control applies to all baselines (LOW, MODERATE, HIGH) and the PRIVACY baseline, making it a universal requirement across the CA control family.
What Happens If CA-06 Is Not Implemented?
Operating without a formal authorization process means no senior official has explicitly accepted the risk of running your systems. Auditors will flag the absence of documented ATO decisions as a material control deficiency. For federal agencies, this can result in FISMA audit findings, funding restrictions, or loss of authorization to process certain data types. Non-federal organizations face similar consequences during SOC 2 audits or client security reviews that reference NIST controls.
How Do You Audit CA-06?
Auditing CA-06 starts by verifying that a senior official is formally designated as the authorizing official for each system and for common controls. Examiners review the authorization statement for completeness, checking that it specifies the system name, boundary, conditions, and date. They confirm that the AO accepted inherited common controls before the system began operations. Finally, auditors check that authorizations are updated at the defined frequency and that continuous monitoring evidence supports ongoing authorization decisions.
Who Can Serve as an Authorizing Official?
The authorizing official must be a senior official with the authority to accept risk on behalf of the organization and the budget oversight to direct remediation resources. In federal agencies, the AO must be a federal employee; contractors cannot serve in this role. The AO should be positioned high enough in the organization to understand mission impact but should not be the same individual responsible for system development, to maintain independence. Common titles include CISO, CIO, mission or business owner, or a designated senior information security officer.