Quick-reference card
| Field | Value |
|---|---|
| Control ID | PM-10 |
| Control name | Authorization Process |
| Framework | NIST SP 800-53 Revision 5 |
| Control family | Program Management |
| Baselines | PRIVACY |
| Implementation level | Organization |
| Relevance | First Party |
| Risk severity | Low |
What this control requires
PM-10 requires organizations to establish and maintain formal authorization processes that govern the security and privacy posture of every system and its operating environment. Most organizations already have some form of system authorization, but PM-10 demands more than a one-time checkbox. It requires a living process where designated individuals evaluate risk, grant operating authority, and remain accountable for those decisions over time.
In practice, this means assigning specific roles within the organizational risk management process, including a risk executive function and authorizing officials for each system and common control provider. These designations ensure that someone with the right authority and context owns the decision to accept residual risk before a system goes live.
The control also requires you to weave authorization activities into your broader risk management program. Authorization can’t exist as an isolated compliance exercise. It must connect to continuous monitoring so that authorizing officials maintain ongoing visibility into changing risk conditions and can revoke or modify operating authority when conditions shift.
Why it matters
Organizations that lack a formalized authorization process face a specific category of governance risk. Without clear authorization boundaries, systems operate in production with no documented acceptance of the risk they carry, and no one is accountable when those risks materialize during an audit or assessment.
The consequence is that auditors and assessors view missing or inconsistent authorization documentation as a systemic failure, not an isolated gap. A single system without a current authorization decision can trigger findings that call into question the maturity of your entire risk management program. For organizations pursuing FedRAMP authorization or similar compliance frameworks, weak authorization processes can delay or block certification.
Where this pattern becomes especially damaging is in environments with rapid system deployment. Cloud migration, DevOps pipelines, and hybrid architectures create new systems and environments faster than informal authorization processes can track. The result is authorization sprawl, where systems accumulate in production without documented risk acceptance.
Specifically, when no one is formally designated as the authorizing official for a given system, accountability gaps emerge. Decisions about acceptable risk become implicit rather than explicit, and there’s no audit trail to demonstrate that risk was evaluated before the system began processing sensitive data. This gap undermines the organization’s ability to respond to assessment findings or regulatory inquiries with documented evidence of informed risk acceptance.
What weak authorization processes expose
- Audit findings for systems operating without a current authorization to operate (ATO), leading to compliance delays or failed assessments
- Accountability gaps where no designated authorizing official owns the residual risk for a system or common control provider
- Disconnected risk management, where authorization decisions happen in isolation from continuous monitoring and enterprise risk posture
- Inability to demonstrate ongoing risk acceptance to external assessors, regulators, or oversight bodies
- Authorization drift, where the documented security and privacy state no longer reflects the system’s actual operating conditions
How to implement
For your organization
The most common failure mode with PM-10 isn’t the absence of an authorization process. It’s an authorization process that exists on paper but doesn’t connect to how the organization actually manages risk. Implementing PM-10 effectively means building a process that stays current rather than one that produces documentation and then goes dormant.
Start by defining your organization-wide authorization policy. This policy should establish the criteria for when systems require authorization, the roles involved (risk executive function, authorizing officials, common control providers), and the process for granting, maintaining, and revoking authorization decisions. Align this policy with your existing risk management strategy so authorization decisions use the same risk tolerance thresholds your organization has already defined.
Next, formally designate authorizing officials for each system and common control provider. These designations should be documented, communicated to relevant stakeholders, and reviewed when organizational changes occur. Avoid assigning authorizing official responsibilities to individuals who lack the authority or context to accept risk on behalf of the organization.
Build the connection between authorization and continuous monitoring. Authorization decisions should reference the ongoing monitoring data that feeds into them. When monitoring reveals a change in system risk posture, the authorizing official needs a defined trigger and workflow to reassess the authorization decision. Without this link, authorization becomes a point-in-time exercise that loses accuracy over time.
Implement tracking mechanisms for authorization status across all systems. A centralized authorization tracking register or governance, risk, and compliance (GRC) platform gives you visibility into which systems have current authorizations, which are pending, and which need reauthorization. Common tooling categories include GRC platforms, document management systems, and risk registers.
Avoid these common mistakes:
- Treating authorization as a one-time event rather than an ongoing process tied to continuous monitoring
- Failing to update authorization documentation when system boundaries, data types, or operating environments change
- Assigning authorizing official roles without ensuring the designees understand their accountability for residual risk
- Disconnecting the authorization process from the enterprise risk management strategy, creating parallel and inconsistent risk acceptance decisions
- Allowing inherited or common controls to operate without a designated common control provider who owns the authorization for those shared protections
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Authorization policy and procedures | Assessment, authorization, and monitoring policy defining authorization criteria, roles, decision workflows, and reauthorization triggers |
| Role designation documentation | Authorizing official designation letters or memoranda identifying individuals, their assigned systems, and scope of authority |
| System authorization packages | Authorization decision documents for each system including risk assessment summaries, residual risk acceptance statements, and authorization dates |
| Risk management strategy | Organizational risk management strategy documenting risk tolerance thresholds, risk executive function responsibilities, and integration with authorization processes |
| Continuous monitoring integration records | Procedures linking continuous monitoring outputs to authorization decision triggers, including escalation criteria and reauthorization workflows |
| Authorization tracking register | Centralized register or GRC platform export listing all systems, their current authorization status, authorizing official, and next review date |
Cross-framework mapping
| Framework | Control(s) | Coverage |
|---|---|---|
| ISO 27001:2022 | 5.2 Information security roles and responsibilities | Partial |
Related controls
- CA-06 — Authorization: Defines the specific authorization decision for individual systems, directly executing the process that PM-10 establishes at the organizational level.
- CA-07 — Continuous Monitoring: Provides the ongoing risk data that authorizing officials need to maintain and reassess authorization decisions over time.
- PL-02 — System Security and Privacy Plans: Documents the security and privacy requirements for each system, forming the baseline against which authorization decisions are evaluated.
Frequently asked questions
What is NIST SP 800-53 PM-10?
PM-10 requires organizations to manage the security and privacy state of their systems through formal authorization processes, designate individuals to fill risk management roles, and integrate those processes into an organization-wide risk management program. The control ensures that every system operating in production has a documented authorization decision backed by an accountable authorizing official. It sits within the program management family, meaning it governs how the organization structures and oversees authorization rather than how individual systems implement technical safeguards.
What happens if PM-10 is not implemented?
Without PM-10, systems can enter production with no formal risk acceptance decision and no designated authorizing official accountable for residual risk. Auditors and assessors will flag the absence of documented authorization processes as a systemic governance weakness, which can delay or block certification efforts under frameworks like FedRAMP. The lack of integration between authorization and continuous monitoring also means that changes in system risk posture go unreviewed, creating a growing gap between documented and actual security conditions.
How do you audit PM-10?
Auditing PM-10 starts with verifying that the organization has a documented authorization policy that defines criteria, roles, and workflows for granting and maintaining system authorizations. Assessors review authorization decision records for a sample of systems to confirm that each has a current authorization, a designated authorizing official, and a connection to the organization’s risk management strategy. They also examine whether the authorization process integrates with continuous monitoring by checking for defined reauthorization triggers and evidence that monitoring outputs feed back into authorization decisions.
Who is the authorizing official in NIST SP 800-53?
The authorizing official is a senior organizational leader designated to accept the residual security and privacy risk for a specific system or set of common controls. PM-10 requires organizations to formally assign this role as part of the risk management process, similar to how ISO 27001 defines information security roles, and the designation must carry sufficient authority to make risk acceptance decisions on behalf of the organization. In federal agencies, authorizing officials are typically senior executives or their delegates who review system authorization packages, including risk assessment results, before granting an authorization to operate.