Assessment & Authorization

Assessment and authorization (A&A) is a structured, formal process through which an organization evaluates the extent to which a system's design and implementation satisfy a defined set of security requirements, and grants or denies authorization for that system to operate based on the assessed risk. For space mission systems, A&A may apply to spacecraft, ground systems, mission networks, supporting infrastructure, common controls, and the interfaces and dependencies among them. The authorization scope and boundary must be defined by the governing risk management framework, mission architecture, information types, applicable requirements, and organizational risk decisions. The assessment phase produces evidence concerning whether selected controls are implemented correctly, operating as intended, and producing the required security outcomes. The resulting authorization package should contain the system security plan, assessment reports, plan of action and milestones, executive risk summary, and other evidence required by the authorizing authority. The authorization decision, made by a designated authority with accountability for accepting the residual risk of operating the system, formally records the organization's acceptance of that risk and establishes the conditions under which the system may operate. Authorization must be supported throughout the system lifecycle by continuous monitoring, security impact analysis, updated risk information, and maintenance of the authorization evidence. Proposed system changes must be assessed before implementation when they could affect the authorization boundary, control implementation, or accepted risk. Significant changes or material deviations from the authorization basis must be reported to the authorizing authority, who determines whether additional assessment, modified authorization conditions, or reauthorization is required.

ID: CM0089
Tier: III
Ground CM 
Created: 2023/11/29
Last Modified: 2026/08/06

Pre-Operations Government

Acquisition requirements should establish authorization as a required operational milestone for systems, services, and common controls subject to the applicable assessment and authorization framework. Operational use must remain within the scope, conditions, and limitations approved by the designated authorizing authority, except where a separately approved limited, interim, test, or emergency authorization applies. The authorization package must demonstrate that applicable security requirements have been implemented and assessed for the mission’s classification, operational context, risk tolerance, and authorized use. Requirements should define the authorization boundary, system categorization, applicable security control baseline and tailoring, inherited or shared controls, external dependencies and interconnections, assessment methodology, required evidence, and authorization-package deliverables. Spacecraft, ground systems, mission networks, and supporting services may be covered by separate authorization decisions, but their interfaces, shared dependencies, inherited controls, and mission-level integration risks must be assessed collectively, with responsibility for each control and risk clearly assigned. Contract language should require contractors to develop and maintain authorization evidence throughout the system lifecycle and submit interim assessment artifacts at defined program milestones. This approach should enable government technical and security authorities to identify control deficiencies, evidence gaps, and unresolved risks while corrective action remains practical and cost-effective rather than deferring authorization activities until system delivery. Evaluation criteria should assess each offeror’s experience supporting the applicable authorization process, proposed security assessment methodology, approach to producing and maintaining authorization evidence, and demonstrated ability to support the authorization of systems with comparable security, mission, and operational requirements. Verification should include government review of authorization artifacts at defined milestones and a security control assessment completed before the authorization decision. Assessors must possess sufficient independence and objectivity from the system’s development and operation, with the required level of independence determined by the system’s risk, criticality, and applicable authorization framework.

Pre-Operations Developer/Supplier

Organizations subject to a formal A&A requirement should establish the applicable authorization framework during program planning. This includes identifying the authorizing authority, authorization boundary, security control baseline and tailoring, inherited controls, assessment methodology, required evidence, and authorization-package structure early enough to inform security engineering and evidence collection. The authorization package structure should be defined early, as the evidence required to demonstrate control compliance, including design documentation, test results, configuration records, and risk assessment artifacts, must be planned for and collected throughout development; attempting to reconstruct this evidence after the fact is significantly more costly and often incomplete. For commercial missions subject to government authorization requirements, early and ongoing engagement with the authorizing authority is essential to ensure that the security control baseline, assessment methodology, and package format meet the government's expectations before the program has invested significant effort in a direction that may require rework. Ongoing authorization should be evaluated where permitted by the applicable A&A framework and supported by a mature continuous monitoring program. Continuous monitoring and ongoing assessment provide current risk information to the authorizing authority but do not independently authorize system changes or eliminate the need for an accountable authorization decision. The organization must define the controls and risks to be monitored, assessment frequencies, change thresholds, reporting requirements, and conditions requiring formal reassessment or a new authorization decision. The authorization boundary must be clearly defined and documented, specifying which systems, interfaces, and external services are within the authorization scope and which are covered by separate authorization actions, as an unclear boundary can leave significant security risks unassessed.