Category: Authorization & Accreditation

Authorization Package

Also known as: Security Authorization Package

Simply put

An authorization package is the collection of documents that a system owner submits to a senior official so that official can decide whether to approve a system for operation. It describes how the system is protected and what security and privacy risks remain. The official reviewing it uses the package to accept or reject the risk of running the system.

Formal definition

An authorization package is the completed set of documentation compiled by a system owner and provided to an authorizing official (AO) to support a risk-based authorization decision. Per the NIST CSRC glossary, it generally includes, at a minimum, an executive summary, the system security plan (SSP), the privacy plan, the security control assessment, and the privacy control assessment, among other supporting artifacts. In DoD contexts the AO is typically a senior civilian or military officer authorized to accept risk on behalf of the government, while in the FedRAMP context the package documents the security and risk posture of a cloud service offering, with the SSP serving as the central security blueprint. Contents and specific artifact requirements vary by framework, agency tailoring, and applicable revision, so practitioners should verify requirements against the current authoritative guidance for their environment. Note that submission of an authorization package is part of the assessment and authorization process and is distinct from the authorization decision itself; producing the package does not constitute an Authority to Operate.

Why it matters

The authorization package is the evidentiary foundation for a risk-based authorization decision. Without a complete and accurate package, an authorizing official (AO) lacks the documented basis to weigh the residual security and privacy risks of operating a system against mission needs. Because the AO accepts risk on behalf of the government, the quality of the package directly shapes whether that acceptance is well-informed. A package that misrepresents or omits the true security posture can lead to an authorization that does not reflect actual risk, which is a governance failure as much as a technical one.

A critical distinction that experts insist upon is that producing an authorization package is not the same as receiving an Authority to Operate (ATO). The package supports the assessment and authorization (A&A) process, but the authorization decision is a separate act rendered by the AO. Practitioners sometimes conflate submission with approval, or treat compliance documentation as equivalent to security itself; a well-assembled package demonstrates documented posture, not guaranteed protection. Similarly, the specific contents required vary by framework, agency tailoring, and applicable revision, so an assumption that one agency's package satisfies another's requirements can be mistaken.

Because frameworks differ, the same core concept plays out differently across environments. In DoD contexts the package is reviewed by a senior civilian or military officer authorized to accept risk, while in the FedRAMP context it documents the security and risk posture of a cloud service offering, with the system security plan serving as the central security blueprint. Readers should verify the exact artifact requirements against the current authoritative guidance for their environment rather than assuming a uniform standard.

Who it's relevant to

System Owners

System owners are responsible for compiling the authorization package and submitting it to the authorizing official. They must ensure the package accurately outlines the system's security posture and assembles the required artifacts, which generally include the executive summary, SSP, privacy plan, and the security and privacy control assessments, subject to the applicable framework and revision.

Authorizing Officials

AOs use the authorization package as the documented basis for a risk-based authorization decision. In DoD contexts this is typically a senior civilian or military officer authorized to accept risk on behalf of the government. AOs should treat the package as decision support, not as an automatic authorization, and confirm that it reflects the actual security and privacy risk before accepting it.

Cloud Service Providers Pursuing FedRAMP

CSPs seeking FedRAMP authorization prepare a package that documents the security and risk posture of their cloud service offering, with the SSP serving as the central security blueprint. Providers should verify current FedRAMP artifact requirements, and should not assume that a FedRAMP package automatically satisfies DoD or other agency-specific authorization requirements.

Assessors and Compliance Officers

Those conducting or supporting the A&A process rely on the package to evaluate an information system's policies, technical and non-technical security components, and documentation. They should distinguish the assessment activity from the authorization decision, and confirm the specific artifact and tailoring requirements against current authoritative guidance for the relevant environment.

Inside Authorization Package

System Security Plan (SSP)

The foundational document describing the information system, its boundary, operational environment, and the security controls selected and implemented. Under the NIST RMF, the SSP generally serves as the central artifact around which the rest of the authorization package is organized. Practitioners should confirm the required SSP format against current agency or DoD guidance, as templates and expectations vary by organization and revision.

Security Assessment Report (SAR)

The document produced by an assessor that records the results of evaluating the implemented controls, including findings, deficiencies, and residual weaknesses. The SAR reflects assessment activity and should not be confused with the authorization decision itself, which is a separate determination made by the authorizing official.

Plan of Action and Milestones (POA&M)

A remediation-tracking document identifying known weaknesses, planned corrective actions, responsible parties, and target completion milestones. The POA&M generally allows an authorizing official to accept residual risk while remediation proceeds. Its specific structure and reporting cadence may differ across federal civilian (FISMA), DoD RMF, and FedRAMP contexts.

Supporting artifacts and appendices

Additional materials that may accompany the core documents, such as continuous monitoring strategies, contingency and incident response plans, privacy documentation, and other evidence tailored by the agency or program. The exact set of supporting artifacts depends on the applicable baseline, impact level, and organizational tailoring; readers should verify requirements against current authoritative sources.

Common questions

Answers to the questions practitioners most commonly ask about Authorization Package.

Does an approved authorization package mean my system is permanently authorized to operate?

No. An Authority to Operate (ATO) granted on the basis of an authorization package is time-bound and conditioned on continuous monitoring, not permanent. The package supports the authorizing official's risk decision at a point in time, but that decision generally remains subject to ongoing assessment, and the ATO can be reconsidered, suspended, or revoked if the system's risk posture changes. Reauthorization timelines and continuous monitoring expectations vary by agency and applicable RMF guidance, so confirm the specific requirements against current authoritative sources.

If my authorization package shows we are compliant with the control baseline, does that mean the system is secure?

Not necessarily. Compliance and security are distinct. An authorization package documents that controls have been implemented and assessed against an applicable baseline, but a fully documented, compliant package reflects a risk decision at a moment in time rather than a guarantee of security against evolving threats. Experts caution against equating a favorable assessment or authorization with an assurance that the system is secure; residual risk, undiscovered weaknesses, and new threats may still exist.

What are the core components typically included in an authorization package?

An authorization package generally consists of the security plan (often a System Security Plan documenting the system and its implemented controls), the assessment results (commonly a Security Assessment Report), and a plan of action and milestones addressing identified weaknesses. Some frameworks and agencies expect additional artifacts. The exact required contents depend on the governing RMF or agency-specific guidance and applicable revision, so verify the current expected components against the authoritative source for your environment.

Who reviews the authorization package and makes the authorization decision?

The authorizing official (AO) reviews the authorization package and renders the risk-based authorization decision. The package is generally prepared and assembled by system stakeholders and supported by an assessor who produces the assessment results, but the AO holds the accountability for accepting risk and issuing, denying, or conditioning the authorization. Roles and delegation practices can vary by agency, so confirm your organization's specific assignments.

How should I handle open weaknesses that remain when the package is submitted?

Open or unresolved weaknesses are typically captured in the plan of action and milestones component of the authorization package, which documents identified deficiencies and planned remediation. Presenting these transparently supports the authorizing official's risk-based decision rather than undermining it. How remaining weaknesses affect the authorization outcome depends on their severity and the AO's risk tolerance under the applicable guidance, which you should confirm against current requirements.

Does a completed authorization package for a FedRAMP-authorized cloud service automatically satisfy DoD authorization requirements?

No. A FedRAMP authorization and its associated package do not automatically satisfy DoD requirements. FedRAMP is maintained through the FedRAMP program for federal civilian cloud use, while DoD systems follow the RMF as directed by the DoD CIO and may impose additional or distinct requirements. A DoD authorizing official generally must make a separate risk determination, and additional package artifacts or tailoring may be needed. Confirm the specific requirements against current DoD and FedRAMP authoritative guidance.

Common misconceptions

An approved authorization package grants a permanent Authority to Operate (ATO).

An ATO is generally time-bound and remains contingent on ongoing continuous monitoring. Changes to the system, environment, or threat landscape can require reassessment, and the authorization package is expected to be maintained as living documentation rather than treated as a one-time deliverable.

Completing the Security Assessment Report means the system is authorized.

Assessment and authorization are distinct steps. The SAR documents assessment results, but authorization is a separate risk-based decision rendered by the authorizing official after reviewing the full package. Confusing assessment with authorization is a common error an expert would correct.

A complete authorization package demonstrates that the system is secure.

The package documents that controls have been selected, implemented, assessed, and that residual risk has been evaluated and accepted. Compliance and documentation are not equivalent to security; open items may still exist in the POA&M and residual risk may be formally accepted rather than eliminated.

Best practices

Treat the System Security Plan as a living document and keep it synchronized with the actual system boundary, control implementations, and operational environment as changes occur.

Maintain the POA&M actively with realistic milestones and responsible parties, and update it as weaknesses are remediated or newly identified rather than only at authorization time.

Keep assessment results (SAR) clearly separated from the authorization decision in your records so that the distinction between assessment and authorization is preserved and auditable.

Establish a continuous monitoring approach so the package supports the time-bound nature of the ATO and can inform reauthorization or ongoing authorization decisions.

Confirm required package contents, formats, and impact-level tailoring against the current applicable authority (for example FISMA, DoD RMF, or FedRAMP) rather than assuming one context's requirements satisfy another.

Verify document templates, artifact expectations, and cadence against the current official guidance for the applicable revision, since baselines and requirements change over time.