What PM-10 authorization process asks for across the organization
If a privacy baseline, contract or assessor requires PM-10, treat it as an organization-wide program control, not a task for one system. PM-10 asks the organization to run authorization as a managed process, and the requirement has three parts: manage the security and privacy state of systems and their operating environments through authorization processes, designate individuals for specific risk management roles, and integrate those authorization processes into the organization-wide risk management program. Each part needs a named owner, a written procedure and records that show the process runs across every system in scope, not only the systems that happened to be authorized last year.
SP 800-53B places the Program Management controls outside the low, moderate and high impact baselines, so PM-10 is not allocated to any of them and a system's impact level does not decide whether it applies. PM-10 does appear in the privacy baseline, which applies to systems irrespective of impact level. Confirm with your assessor or contract owner whether PM-10 is being assessed as a privacy baseline item, and which systems fall in scope. Also confirm which related controls the organization relies on, since the catalog links PM-10 to CA-6, CA-7 and PL-2, which cover authorization, continuous monitoring and planning.
The hard part is usually not writing the policy. Authorization decisions often sit in separate teams, each with its own tracker, so the organization cannot show one picture of which systems are authorized, under what conditions and who accepted the residual risk. Risk roles are frequently named in a charter but not tied to actual decisions. Start by inventorying authorization records across the program, assigning one accountable owner for the process and setting a reporting path into the enterprise risk program so that the assessor can trace a single authorization decision from the system to the executive who accepted the risk.
Which systems, teams and authorization decisions PM-10 reaches
PM-10 sits at the organization level, so it governs how every system authorization is run rather than authorizing one system. The cards below separate that program scope from the system-level work in CA-6 and CA-7, then name the systems, roles and privacy baseline cases the process must reach.
Program scope versus system-level CA-6
CA-6 asks for a named authorizing official to decide whether a single system may operate, based on its own assessment results. PM-10 asks whether the organization has a process that produces those decisions consistently, tracks them and feeds them into the wider risk program. Check that each system authorization can be traced back to a documented organization-wide process with the same forms, criteria and records, not to local habit.
Continuous monitoring as the operating link
CA-7 is the system-level monitoring control that keeps an authorization current after the decision. PM-10 needs the organization to manage that ongoing state across all systems, so monitoring results, changes in risk and expired authorizations flow into one tracked view. Confirm who receives CA-7 results and how the organization decides when an authorization must be revisited.
Systems and operating environments in scope
The process must reach every system and the operating environment it runs in, including cloud accounts, hosted services, on-premises platforms and any shared infrastructure that multiple systems inherit. A common gap is a system that was never entered into the authorization process because it was procured outside IT. Ask for the system inventory and check that each entry has a recorded authorization state, including systems that are retired, inherited or pending.
Authorizing officials, risk executive and system owners
PM-10 requires individuals to be designated for specific risk management roles. In practice that means naming the authorizing officials who sign decisions, the risk executive who views risk across the organization, and the system owners who maintain the security state of their systems. Confirm that each role has an appointment record, defined decision rights and a documented handoff when the person changes.
Privacy baseline systems at any impact level
PM-10 is not allocated to the low, moderate or high security baselines, but it appears in the SP 800-53B privacy baseline, which applies to systems irrespective of impact level. A low-impact system that processes PII therefore brings PM-10 into scope even though its security baseline does not. Review your PII inventory against the system list so that privacy-baseline systems are authorized through the same process.
Authorization decisions and their records
Each authorization decision, whether to authorize, authorize with conditions or deny, needs a record that shows the evidence reviewed, the risk accepted and the expiry or review date. Assessors using SP 800-53A examine the procedures for managing that authorization process and test whether the organization's processes work in practice. Ask for a sample of recent decisions and confirm each one can be followed from request to recorded outcome.
How an assessor tests PM-10 under SP 800-53A
This table maps the four SP 800-53A determination statements for PM-10 to the assessment method, the people or documents an assessor works with, and the findings that often appear. Read each row as one step of the assessor's test, and use the evidence column to prepare what an assessor will ask to see.
| Assessment element | What the assessor does | Evidence that passes | Common finding |
|---|---|---|---|
| Determination statement 1: examine procedures | Reads the documented procedures for managing the authorization process and the assessment, authorization and monitoring policy | Approved procedures that name the authorization process steps, the records kept, and how authorization status is tracked and reported | Policy exists but does not describe how authorization decisions are recorded or reported |
| Determination statement 2: examine management records | Checks that the authorization process is documented, tracked and reported as the procedures require | Authorization tracking records, status reports and dated decision records for systems in scope | Tracking spreadsheet is out of date or does not cover all systems |
| Determination statement 3: interview responsible personnel | Asks the people who manage the authorization process how it runs day to day and who decides | Consistent answers from named personnel, plus role assignments that match the documented procedures | Staff describe different steps, or no one can name the owner of the process |
| Determination statement 4: test the organizational process | Observes or walks through a recent authorization to confirm the documented process was followed | A completed authorization file that shows the steps, approvals and monitoring follow-up as written | Authorizations are granted in practice without the documented steps |
| Designated risk management roles | Checks that individuals are designated for the risk management roles tied to authorization | Appointment records or role descriptions that name the responsible individuals and their authority | Roles exist in policy but no individual is assigned, or assignments are undocumented |
| Integration with the risk management program | Confirms authorization results feed into organization-wide risk reporting and decisions | Risk reports or governance minutes that show authorization status and open risks reaching accountable officials | Authorization is handled as an isolated IT task and does not appear in risk reporting |
How to implement PM-10 in a sequence that produces evidence
This sequence turns PM-10 from a policy statement into a working authorization process, with named roles, a traceable link to CA-6, CA-7 and PL-2 outputs, and a review cycle that an assessor can test. Each step ends with a document or record the organization can show.
Define the organization-wide authorization process and scope
Write a procedure that states which systems and operating environments fall under authorization, what triggers a new authorization or re-authorization, and which decision outcomes are allowed. Senior leadership approves it, and the security and privacy offices review it. Done means a versioned authorization procedure with an approval record and a system inventory that it references, such as the inventory covered by PM-5. Ask the assessor's view early, because the SP 800-53A procedure asks for documentation of how the process is managed, tracked and reported.
Designate risk management roles and decision authority
Name the individuals who authorize systems, who review the security and privacy assessment results, and who accept residual risk. Record each person's authority, backup and escalation path in the procedure and in appointment or role documents. The organization owns these decisions. An implementation partner can help draft role definitions, but the named officials must sign them. Done means a roles matrix that an interviewer can match against what the staff actually say they do.
Connect the process to CA-6, CA-7 and PL-2 outputs
Map each authorization step to its inputs and outputs. CA-6 covers the authorization decision, CA-7 covers continuous monitoring results that feed later decisions, and PL-2 covers the system security and privacy plans that the decision relies on. Set a rule that no authorization decision is recorded without a current plan, current assessment results and a monitoring summary. Done means a traceability table linking each system to its plan, its latest assessment and its latest decision record.
Integrate authorization results into the risk management program
Route authorization decisions, accepted risks and open remediation items into the organization-wide risk register and the reporting that goes to senior officials. Confirm that the risk strategy and risk tolerance used for decisions match the organization's documented risk management strategy. Done means a risk register extract that shows authorization decisions, owners and status, and a report to the accountable official that a reviewer can trace back to individual system decisions.
Track authorization activity and reporting
Operate the process by logging each authorization request, decision, condition, expiry or re-authorization trigger and the reports produced from them. Use a system of record that is retained and access-controlled, whether that is a ticketing platform, a GRC tool or a self-hosted application. Done means a complete log for a sample of systems, where every decision can be followed from request to report without gaps. Confirm the tool's logging and export features before selecting it.
Set and run the review cycle
Schedule periodic reviews of the authorization procedure, the role assignments and the traceability table, and review them again when systems, roles or the risk strategy change. The review frequency should be set by the organization and recorded in the procedure. Done means dated review records with the reviewer's name, the changes made and the approval of each revision. The assessor will look for evidence that the process was reviewed, not only that it exists.
Evidence that passes a PM-10 assessment and how to keep it current
PM-10 is assessed by examining documentation, interviewing the people who run authorization, and testing whether the process works as written. The cards below cover the artifacts an assessor will ask for and the routines that keep each one accurate between assessments.
Written authorization process
This is the procedure that defines how systems move through authorization, who signs off at each stage, what evidence is required before a decision, and how the process links to the wider risk management program. Assessors compare it against the determination statements in SP 800-53A, so it should name roles and steps rather than restate the control. Check that it covers the procedures for documenting, tracking and reporting authorizations, and that it has an owner and a review date. Confirm the current version matches what staff actually follow.
Role designation records
Assessors look for evidence that named individuals hold specific risk management roles, such as the authorizing official, the risk executive and the control assessor. Keep appointment letters, role descriptions and a current register showing who holds each role and when it was assigned. Records should be updated when staff change, and a role with no assigned person should be flagged as a gap. An interview with those people usually tests whether they understand what the role requires.
Authorization decision records
Each authorization decision should be recorded with the system, the date, the decision, the risk accepted, the conditions attached and the official who signed. Store the package the decision relied on, including the assessment report and the plan of action and milestones. Track conditions and expiry dates in a single register so that a decision that has lapsed or carries open conditions is visible. Test a sample of decisions against the written process to confirm the steps were followed.
Authorization status reports
Risk governance needs a recurring view of which systems are authorized, which are expiring, and which operate under conditions or without a valid decision. Produce this report from the system inventory and the decision register rather than from memory. Confirm that the report reaches the officials named in the risk management program and that the distribution and the meeting minutes are kept as proof. The report is also the easiest way to show that authorization is integrated into organization-wide risk management.
Tracking and remediation of authorization gaps
Systems that operate without a current authorization, or with unmet conditions, should appear in a tracked list with an owner, a due date and a closure record. Link each item to the plan of action and milestones process so that deferrals are approved by the right official. Review the list at the frequency set in the program documents and keep the review minutes. An assessor will often pick one aged item and trace it to closure.
Periodic review records
The authorization process itself must be reviewed, and the review should be documented. Keep records showing when the procedure was last examined, what changed, who approved the update, and how the change reached staff. Reviews should also check whether the process still matches current system inventory, role assignments and monitoring results. Between formal assessments, schedule these reviews on the calendar with named owners so the evidence exists when an assessor asks for it.
What meeting PM-10 costs in money and effort
This table breaks down the cost components of running PM-10 authorization processes, marks which are one-time and which recur, and lists what drives each one up or down. Use it to see who is paid for what and what to request in a written quote before comparing outside help.
| Cost component | Who carries it | One-time or recurring | What drives it |
|---|---|---|---|
| Drafting the authorization policy and process | Internal policy owner, with optional outside help for drafting | One-time, then reviewed periodically | Number of system types, existing policy maturity, and how many authorization paths the organization runs |
| Designating risk management roles | Senior leadership and the officials who authorize systems | Recurring as roles change | Number of authorizing officials, and how often personnel or accountability lines change |
| Integrating authorization into the organization-wide risk program | Risk, governance and program staff | Recurring governance time | How mature the existing enterprise risk program is and how often its reporting cycles run |
| Tracking tooling and records | Internal IT or platform team, plus any licensed or self-hosted tools | Setup one-time, licensing or hosting recurring | Number of systems tracked, integrations with existing inventories, and whether tracking is manual |
| Evidence upkeep and reporting | System owners and the security or compliance team | Recurring with each authorization decision and periodic review | Number of systems and authorization decisions per year, and the reporting frequency leadership requires |
| External assessor time | Independent assessor or auditor, paid per agreed scope | Recurring at each assessment cycle | Scope of the assessment, number of systems sampled, and the quality of the evidence already prepared |
| Consultant preparation | Implementation partner, under a written fixed scope | Typically one-time for preparation, with optional retainers | Gap between current records and what assessors test, and how many systems need to be prepared |
Who owns PM-10 and what a partner can prepare
Your organization owns PM-10. The authorization process, the decisions it produces and the people who hold risk management roles all sit inside your governance structure, and no outside party can accept risk on your behalf. Assessors will ask who decided, when, and on what basis, so these answers need to come from named people in your organization.
- Authorization decisions: Senior officials decide whether to authorize a system to operate, under what conditions, and for how long, based on the risk information they receive.
- Designated roles: Name the individuals responsible for managing the authorization process and for each risk management role, and record their appointments and responsibilities.
- Integration with the risk program: Decide how authorization outputs feed the organization-wide risk management strategy, plans of action and milestones, and reporting to leadership.
- Policy approval: Approve the assessment, authorization and monitoring policy that governs the process.
- Accepting residual risk: Only your accountable officials can accept risk that remains after controls are applied.
Before any partner starts work, confirm which roles are yours, who signs authorization decisions, and where those decisions are recorded.
A implementation partner prepares the machinery that makes the authorization process repeatable and auditable. The work is documentary and operational: the partner helps build the process, keeps the tracking current, and assembles the evidence your team and assessor will review. The partner does not make authorization decisions and does not decide whether a control is satisfied.
- Process documents: Draft the authorization procedures, templates and workflow so that each step of the process is written down and repeatable.
- Tracking: Set up and maintain the records that show which systems are in the process, their status, and open items.
- Evidence packages: Collect the artifacts for each system, such as process records, meeting minutes and decision logs, and index them against the determination statements.
- Open-source tooling: Configure self-hosted tools inside your environment to store and report on this information, if your organization chooses that route.
- Gap identification: Report where documentation is missing or inconsistent so your team can fix it before assessment.
Ask any partner to state in writing which documents it will draft, which records it will maintain, and that your staff, not the partner, will sign authorization decisions.
The independent assessor tests PM-10 and reports on it. The assessor examines documents, interviews the personnel who run the process, and tests whether the organizational process works as written. Its conclusions must come from its own work, which is why the assessor cannot be the party that wrote the evidence it is testing.
- Examine: Review the authorization policy and procedures, and the records showing how the process is managed, documented and reported.
- Interview: Speak with the people responsible for managing authorization to confirm they understand and perform their roles.
- Test: Observe or sample the authorization process in operation to confirm it runs as documented.
- Reporting: Issue the assessment findings and any formal report, which only an independent assessor or the relevant authority can issue.
- Independence: Where a partner prepared the evidence, the assessor still tests it independently and draws its own conclusions.
Confirm with your assessor, before work starts, which evidence it expects, how it will sample records, and who is permitted to receive its findings.
Where PM-10 programs usually fall short
PM-10 is easy to satisfy on paper and hard to satisfy in practice. The gaps below share a root cause: authorization is run as a single project per system instead of as a managed process tied to the organization's risk decisions. Each card names one gap and the check that exposes it.
Authorization treated as a per-system form
Teams complete an authorization package for each system, sign it, and file it. Nothing defines how authorization decisions are tracked, reported or revisited across the portfolio. PM-10 asks for the security and privacy state of systems to be managed through the authorization process, so the process itself needs an owner, a procedure and a record. Check whether you can list every authorized system, its decision date and its open conditions from one place, without opening individual folders.
Risk management roles named informally
Authorizing officials, system owners and security reviewers are often identified by job title in a meeting note rather than by a formal designation. PM-10 requires individuals to be designated for specific risk management roles. Check that each role has a named person, a written scope, a documented delegation path for absences, and a record of who signed each decision.
No link to the enterprise risk register
Authorization decisions accept residual risk, but that acceptance rarely appears in the enterprise risk register. As a result, leadership sees a risk score that does not reflect systems operating under accepted conditions. PM-10 expects authorization to be integrated into the organization-wide risk management program. Check whether an authorization condition or accepted risk can be traced to a register entry, and whether the register is reviewed with authorization status in view.
Privacy baseline systems missed
PM-10 is part of the SP 800-53B privacy control baseline, which applies regardless of system impact level. Programs built around low, moderate and high security baselines often leave privacy-only systems, such as a low-impact application that processes PII, outside the authorization process. Check your system inventory for systems that process PII and confirm each one is either inside the authorization process or formally excluded with a recorded reason.
Operating environments outside the process
Authorization often covers the application and skips the hosting platform, shared services, or cloud accounts it depends on. PM-10 covers the security and privacy state of systems and their operating environments. Check whether the authorization boundary includes the environment, and whether changes to shared infrastructure trigger a reassessment of the systems that rely on it.
Assessment evidence not reviewed by the process
Assessment reports are produced, but no one checks whether the process that generated them runs on schedule or responds to findings. SP 800-53A asks assessors to examine how authorization management is documented, tracked and reported, and to interview the people who run it. Check that authorization tracking records show when packages were last reviewed, which findings remain open, and who reported on them.
Questions buyers ask about PM-10
Does PM-10 apply to our system impact level?
PM-10 is not allocated to the low, moderate or high baselines, because SP 800-53B treats Program Management controls as organization-wide and independent of any system impact level. It does appear in the SP 800-53B privacy baseline, which applies to systems irrespective of impact level. So if your systems process personally identifiable information and you select the privacy baseline, PM-10 is in scope for those systems. Confirm your baseline selection with your authorizing official or compliance lead before scoping the work.
What does PM-10 ask the organization to do?
PM-10 asks you to manage the security and privacy state of your systems and their operating environments through authorization processes, to designate people for specific risk management roles, and to fold those authorization processes into your organization-wide risk management program. In practice, this means a documented authorization process, named roles with clear accountability, and records showing that authorization decisions feed the wider risk program. The control is organizational, so the evidence sits with governance records rather than with a single server or application.
How much effort does PM-10 take to put in place?
Effort depends mostly on how mature your authorization process already is. If you already run authorization decisions for systems under CA-6 and monitor them under CA-7, PM-10 is largely about writing down the process, naming the roles and linking the process to your risk management program. If authorization is informal or spread across teams, the work includes defining the process, agreeing roles and collecting records of past decisions. Ask any partner to break effort down by policy drafting, role definition, process integration and evidence collection.
How long does the PM-10 work take?
No duration is set by NIST for PM-10, so the timeline depends on your scope, the number of systems in the authorization process and how far existing governance already reaches. Work usually runs in the order of policy and role definition, process integration, then evidence gathering and review. Ask for a timeline in the written scope, with each deliverable and the dependencies on your own approvals and review cycles stated.
Can we implement PM-10 ourselves without an outside partner?
Yes, an organization can implement PM-10 with its own staff, since the control owns its processes and the organization is responsible for its controls. Outside help is most useful when the team lacks experience with authorization workflows, the SP 800-53A assessment expectations or the technical evidence for the related CA controls. DeployOpen plans, implements and documents systems and evidence for compliance readiness under a fixed-scope written agreement, but it does not issue assessment reports or certifications, which only an independent assessor can do.
What must we provide to an implementation partner?
Give the partner the material that shows how authorization works today, so scope and gaps can be agreed in writing before work starts. Typical inputs include your current authorization and risk management policies, a list of systems and their authorization status, records of recent authorization decisions, role descriptions for anyone involved in risk decisions, and the link between your risk strategy and the authorization process. Name a single accountable owner on your side, because approvals and role assignments must come from your organization.
What will the assessor ask for when testing PM-10?
SP 800-53A assesses PM-10 through determination statements using examine, interview and test methods. An assessor will typically examine procedures for managing the authorization process, including documentation, tracking and reporting, and the assessment, authorization and monitoring policy. They will interview the personnel responsible for running the authorization process and test whether the authorization processes operate as written. Prepare the procedure documents, tracking records, reports to senior officials, role assignments and examples of completed authorization decisions, and confirm the exact assessment objects with your assessor.
How DeployOpen prepares PM-10 evidence
DeployOpen's role in PM-10 work is to prepare, not to attest. Before any work starts, DeployOpen and the client agree in writing on the scope: which systems and operating environments fall under the authorization process, which authorization and monitoring policy documents exist, who holds the risk management roles, and which assessment objects the assessor will examine. Because PM-10 sits at the organization level and is not tied to a single system, that scope has to name the programs it covers, not only the infrastructure. DeployOpen then prepares the systems, process documents and evidence an independent assessor will need to walk through the four determination statements in SP 800-53A. The client owns the controls and the decisions; DeployOpen organizes the material so the assessor can trace each statement to an artifact.
Preparation usually centers on the records that show the authorization process is managed, tracked and reported. DeployOpen can help assemble the documentation of the authorization process and the assessment, authorization and monitoring policy, the register of designated risk management roles, and the records that link authorization decisions to the organization-wide risk management program. Where the client runs open-source platforms in its own infrastructure, DeployOpen can also prepare the configuration and logging output that shows those systems are being tracked through the process. The client should confirm with its assessor which artifact formats and sampling approach are acceptable, because those choices change how much preparation is needed.
When gaps appear, DeployOpen supports remediation within the agreed scope. Typical work includes drafting or revising procedures, setting up tracking for authorization status, and helping the client record plans of action and milestones for items it cannot close in time. Remediation is still the client's decision, and any change to risk acceptance or authorization outcomes belongs to the designated officials. DeployOpen does not issue assessment reports, attestations or authorization decisions. Only an independent assessor can provide those, and the client should confirm the assessor's independence and qualifications before engaging them. Ask any implementation partner to name exactly which deliverables are in the written scope and which belong to the assessor.
