PM-9 Risk management strategy: requirements and evidence

What the PM-9 risk management strategy asks for and why it is hard to show

PM-9 asks the organization for a comprehensive strategy for managing two kinds of risk: security risk from operating and using its systems, and privacy risk to individuals from authorized processing of PII. The strategy must be implemented consistently across the organization and reviewed and updated at a defined frequency or when organizational changes require it. When an auditor, a customer contract or a board asks for this, the team often has risk registers, system-level assessments and a few policies, but no single document that states how risk is decided, owned, accepted and revisited across the whole organization. The writing is the easy part. The hard part is showing that the same strategy is applied in every business unit and system, and that someone reviewed it on schedule or after a reorganization, a new cloud provider or a major change in data use.

PM-9 sits in the Program Management family, so it is deployed organization-wide rather than per system. That is why it is hard to evidence. A system authorization produces a package with a clear boundary and dated artifacts. A program-level strategy has no boundary, and its evidence is scattered across risk committee minutes, risk register exports, policy approvals and interview answers. An assessor working from SP 800-53A will examine the strategy, interview the people who develop and update it, and test the processes that produce and revise it. Before any assessment, confirm who owns the strategy, where the approved version lives, what the review trigger list contains and whether the last review and its outcome are recorded with dates and approvers.

Start with a gap check against the four determination statements in SP 800-53A for PM-9, then map each statement to a named document, owner and recent record. Decide the review frequency the organization will defend and write down the organizational changes that force an earlier review, such as mergers, new regulated services or significant changes to PII processing. Ask the people who will be interviewed to explain the strategy in their own words, because consistency is tested in those answers. Where risk registers from different units use different scales or acceptance thresholds, resolve that before the assessment rather than during it. The NIST CPRT entry for PM-09 gives the control text and related controls to check against.

Who PM-9 risk management strategy covers across the organization

PM-9 is written for the whole organization, so the strategy has to reach beyond any single system boundary. The cards below name the scoping decisions that change which teams, systems and third parties end up in the evidence set.

The organization as the unit

PM-9 sits in the Program Management family, so the strategy is one document set for the whole organization, not a strategy per system. Decide who signs it, which business lines it binds and how it is versioned. The evidence then shows one approved strategy, the review record and proof that system owners were told to follow it. Ask whether subsidiaries and shared service units are bound by it or only referenced.

Business units that run or fund systems

Risk from operating systems is often owned by a business unit that buys and funds the system, not by IT. Map which units own budgets, data and system decisions, then confirm each one has a role in the risk strategy. Evidence includes the risk appetite each unit has accepted and the minutes where tolerances were agreed. Without this mapping, the strategy describes IT risk only and the assessor's interview questions will expose the gap.

Teams that process PII

The privacy half of PM-9 covers risk to individuals from authorized PII processing, so every team that collects, stores or analyzes personal data must be in scope. Typical examples include HR, customer service, marketing analytics and product teams running test data. For each team, the strategy should state how privacy risk is identified and who decides on it. Evidence includes data flow records and the privacy risk entries that trace back to them.

Third parties whose risk feeds the strategy

Suppliers, cloud providers and managed service firms carry security and privacy risk into the organization. The strategy should say how third-party risk is weighed against internal risk and where supplier findings enter the risk register. Ask which contracts, assessments and incident notices must reach the risk owner. Evidence for this card is the supplier risk inputs, not the supplier's own certifications alone.

Risk owners and escalation paths

A strategy that names no owner cannot be reviewed consistently. Decide which role approves the strategy, which role accepts residual risk and how disputes escalate to senior leadership. Record these decisions in the strategy and in role descriptions. Assessors typically test this through interviews with the people named, so confirm those people know their responsibilities and have the authority to act on them.

Triggers for review after organizational change

PM-9 requires review at a defined frequency and when organizational changes require it. Mergers, new business lines, outsourcing moves and new regulated data types are the events that change the scope. Define which events trigger a formal review and who records the decision. Evidence includes change logs linking each reorganization to a strategy review or a documented decision that no update was needed.

Why PM-9 sits outside the impact baselines but inside the privacy baseline

PM-9 is not allocated to the low, moderate or high impact baselines, and the reason is structural rather than a gap in the control. SP 800-53B treats the Program Management controls as deployed organization-wide, supporting the information security program as a whole and independent of any system's impact level. A risk management strategy is one document and one set of processes for the whole organization, so it is not selected system by system the way access or audit controls are. An assessor will look for the strategy at the organization level, not in each system security plan. Expect the system-level question to be answered by PM-9 once and then referenced, not repeated.

PM-9 does appear in the SP 800-53B privacy control baseline, and that baseline applies to systems irrespective of impact level. For an organization that processes PII in low-impact systems, this matters: the security baseline for those systems may be light, but the privacy baseline still brings PM-9 into scope, along with the other privacy controls it selects. The strategy must therefore address privacy risk to individuals from authorized PII processing, not only security risk from operating systems. Confirm in the SP 800-53B privacy baseline profile which privacy controls apply to your systems before you scope, and do not assume that a low categorization removes the privacy requirement.

Before scoping, check the baseline table in the SP 800-53B OSCAL profiles for the low, moderate, high and privacy baselines against the current release, and record which of your systems process PII. Then decide who owns the organization-wide strategy, how it is reviewed when the organization or its PII processing changes, and where the evidence sits for an assessor. Confirm these points with your assessor or the authorizing official, since the applicable baseline depends on your authorization and contract requirements.

How an assessor tests the PM-9 risk management strategy

This table maps the four SP 800-53A determination statements for PM-9 to the assessment method, the assessment object, the evidence an assessor will request and the findings that usually come up. Read it as a checklist of what must be consistent across the organization, not just present in a policy document.

Assessment element	Method and object named in SP 800-53A	Evidence the assessor will request	Common findings
Strategy content (examine)	Examine the supply chain risk management strategy, which SP 800-53A names as a potential assessment object for PM-9	The current risk management strategy, its approval record, and how it covers operating system security risk and privacy risk from authorized PII processing	Strategy covers security risk only, or privacy risk is described in general terms with no link to PII processing activities
Responsible personnel (interview)	Interview personnel responsible for developing, implementing, reviewing and updating the strategy	Role descriptions, named owners, meeting minutes or sign-offs showing who reviewed and changed the strategy	Interviewees describe the strategy differently, or the owner cannot explain how privacy risk feeds into system decisions
Development and review process (test)	Test the organizational processes for developing, implementing, reviewing and updating the strategy	Documented review cycle, change log, triggers for out-of-cycle review after organizational change, and records of completed reviews	Review frequency is defined but not followed, or reviews do not occur after reorganizations, mergers or new system categories
Consistent implementation (test)	Test whether the strategy is applied across business units and systems, not only at headquarters	Samples of risk decisions from several units showing the same risk tolerance, scoring and escalation path	Different units apply different risk criteria, so the same risk receives different ratings across the organization

Building a PM-9 risk management strategy an assessor can trace

This sequence turns PM-9 into a dated, approved strategy with named owners, so an assessor can follow each decision from leadership scope through to the review record. Each step produces a document or record the assessor can examine, interview against and test.

Confirm scope with senior leadership
Start by agreeing with the senior leader accountable for risk which operating systems, business units, data types and PII processing activities the strategy covers. Record the scope statement and the leader's sign-off in a dated memo. The organization owns this decision. An implementation partner can draft the scope options, but the accountable official must approve them. The output is a signed scope statement that names what the strategy governs and what it excludes, so every later step has a boundary to point to.
Document security and privacy risk sources and tolerances
Inventory the sources of security risk from operating and using organizational systems, such as threats, vulnerabilities, third parties and internal processes, and the sources of privacy risk to individuals from authorized PII processing. For each source, record the risk tolerance the organization accepts and the reasoning behind it. Link these entries to the existing risk register and the PM-28 risk framing outputs where they exist. The output is a source and tolerance register that an assessor can compare against the strategy text and the register in use.
Define decision roles and approval path
Assign who develops, reviews, approves and updates the strategy, and who decides when a risk falls outside tolerance. Write these roles into the strategy and into role descriptions or appointment records. Confirm the approval path with the officials named, including who signs off on privacy risk separately from security risk. The output is a roles table with named positions and an approval record showing the strategy was adopted at the appropriate level. Assessors interview these individuals, so the names and duties must match what they say.
Set the review frequency and change triggers
PM-9 requires review and updating at a defined frequency or when organizational changes require it. Choose the periodic interval the organization can keep, then list the events that force an earlier review, such as a major system acquisition, a new PII processing purpose, a material incident or a change in the organization's structure. Confirm that the interval and triggers match what leadership has agreed. The output is a review schedule and a trigger list written into the strategy, which an assessor will check against the review history.
Publish and communicate the strategy
Publish the approved strategy in the location where the staff who run risk processes can find it, and send it to the officials named in the roles table. Record the distribution list and the date of each communication. Where contractors or service providers depend on the strategy, confirm that the relevant parts reach them through their agreements. The output is a published, version-controlled document and a distribution record. Assessors test whether the people who own risk decisions have actually received and used the current version.
Run and record the first review cycle
Run the first scheduled review against the source register, the tolerances and the trigger list, and record what changed, what stayed the same and why. Feed any open risk decisions into the plan of action and milestones process and the risk registers. Obtain approval for the revised version and update the version history. The output is a review record with the date, participants, decisions and new version number. This closes the cycle and gives the assessor a dated trail from the original strategy to its current state.

Which evidence passes PM-9 and how to keep it current

PM-9 is satisfied by a set of records that show the risk management strategy exists, was approved, is reviewed on schedule and after organizational change, reaches the units that apply it, and covers privacy risk from PII processing. Each artifact below has an owner and a refresh trigger, and the assessor will look for both the document and the trail of decisions behind it.

Approved risk management strategy document

This is the core artifact: a written strategy that sets out how the organization manages security risk from operating and using its systems and privacy risk to individuals from authorized PII processing. Check that it names the scope, the risk tolerance and the roles involved, and that it cross-references the supporting policies that carry it out. Keep the document under version control with a dated revision history, so an assessor can see exactly which edition was in force at any point in the assessment period. The owner is usually the risk executive or the senior official responsible for the security program, with the privacy office co-authoring the privacy portions.

Evidence of accountable official approval

An assessor will want to see that someone with authority over organization-wide risk formally approved the strategy. Keep the signed approval memo, the governance meeting minutes or the board or committee resolution that records the decision, and the date of approval. Confirm that the approver is the same official named in your risk management leadership roles, so the approval chain matches your role definitions. Approval should be repeated whenever the strategy is materially revised, and each approval should be tied to a specific document version.

Periodic and change-driven review records

PM-9 requires review at a defined frequency and when organizational changes require it. Keep a review log that records each review date, the reviewer, what was checked, and what changed as a result, including reviews that concluded no change was needed. Define the triggers in advance, such as a merger, a new regulated line of business, a major cloud migration or a significant privacy law change, and record each trigger when it occurs. Assessors often test whether the review happened when a trigger fired, so the log should show that link explicitly. The owner is the strategy author, with the accountable official signing off.

Communication and adoption across units

A strategy that sits in a document library does not satisfy the requirement that it be implemented consistently. Keep distribution records, acknowledgment logs from unit leaders, training attendance tied to the strategy, and examples of unit-level risk registers that reference the organization-wide strategy. Sample a few units and confirm that their risk decisions use the same tolerance and categories. Gaps found in this sampling should be logged as findings with an owner and a due date. Unit leaders typically own their adoption records, and the central risk function reviews them.

Privacy risk records for PII processing

The privacy side of PM-9 needs its own trail. Keep the privacy risk assessments or privacy impact assessments that feed the strategy, the register of PII processing activities, and records showing how identified privacy risks were accepted, mitigated or escalated. Confirm that the privacy risk tolerance matches the one stated in the strategy. The privacy office usually owns these records, and they should be refreshed whenever a new processing purpose is approved or an existing one changes materially.

Cross-references to the risk register

The strategy is only useful if it feeds day-to-day risk decisions. Keep the enterprise risk register and its risk acceptance records, and show how entries trace back to the tolerance levels in the strategy. Check that the risk categories used in the register match those in the strategy document. Between audits, the risk function should reconcile the register against the strategy at each review cycle, and any mismatch should trigger either a register update or a strategy update, recorded in the review log.

What meeting PM-9 costs in money and effort

This table lists the cost components of running a PM-9 risk management strategy, who is paid for each, whether it is one-time or recurring, and what moves it up or down. NIST does not estimate compliance costs, so the table names drivers and questions to ask rather than amounts. Use it to scope internal effort and to compare quotes on a like-for-like basis.

Cost component	Who bears it	One-time or recurring	What drives it up or down
Strategy drafting and policy writing	Internal risk, security and privacy staff; any outside facilitator	One-time, then recurring on each revision	Number of risk domains covered (security and privacy), existing risk documents to reuse, and how many business units must agree
Executive and risk committee time	Senior accountable officials and committee members	Recurring at each review cycle	Frequency of committee meetings, number of decisions needed on risk tolerance, and whether PM-28 risk framing already exists
Risk register and evidence tooling	Licence fees for commercial GRC platforms, or hosting and administration for self-hosted tools	Recurring licences or hosting; one-time setup and data migration	Commercial per-user licensing versus self-hosted open source, integration effort with existing ticketing and asset systems, and volume of risk entries
Periodic review and update	Internal owners, with optional external review	Recurring at the organization's defined review frequency	Review interval set in the strategy, rate of organizational change (mergers, new services, new data processing), and how much evidence is already automated
External facilitation or independent review	Consultant or implementation partner paid per written scope	Usually one-time for the initial strategy, optional recurring for review	Internal experience with risk methodology, number of workshops, and whether the scope is fixed in writing before work starts
Assessor sampling and testing	Independent assessor or auditor, fees set by their engagement terms	Recurring with each assessment cycle	Assessment scope and sample sizes the assessor chooses, quality of documented decisions and minutes, and how easily evidence can be produced
Remediation of gaps found in review	Internal teams and any vendors used for fixes	Variable, one-time per finding	Number and age of open findings, whether risk decisions were documented when made, and whether plans of action and milestones are tracked

Who owns the PM-9 strategy, what a partner prepares and what the auditor tests

Your organization owns PM-9. The risk management strategy must address security risk from operating and using organizational systems and privacy risk from authorized PII processing, and it must be implemented consistently across the organization. Leadership decides the risk tolerance, the priorities and the review cadence, so these decisions cannot be delegated to an outside party.

Accountable official: A senior leader approves the strategy and accepts the residual risk it describes.
Risk owners: Business and system owners confirm that the strategy matches how their systems and data are actually used.
Strategy author: A named internal role maintains the document, records changes and tracks reviews.
Privacy and security input: The privacy official and the security lead agree on how both risk types are weighed.
Review triggers: Your team defines the review frequency and the organizational changes that force an earlier review.

Confirm internally who signs the strategy, where the approved version is stored and how reviews are recorded before any outside party starts work.

Where organizations usually fall short on PM-9 and how to close each gap

PM-9 looks simple on paper, but assessors tend to find the same few weaknesses: a strategy that covers only security, no clear review trigger, approval that cannot be demonstrated, and a strategy that stops at the policy document. Each card below names one gap and the practical fix that closes it.

Security risk only, no privacy risk

Many strategies describe how the organization manages threats to systems but never address privacy risk to individuals from authorized PII processing. PM-9 asks for both, so the strategy should name the PII processing activities it covers and state how privacy risk is assessed and accepted. Check whether the privacy program owner was consulted when the strategy was written, and whether the privacy baseline applies to the systems you operate.

No defined review frequency

PM-9 requires the strategy to be reviewed and updated at a frequency the organization defines. A strategy with no stated interval, or one that was last changed years ago, fails the test even if the content is sound. Set the interval in the document itself, record the date of each review, and keep the prior versions so an assessor can see the review actually happened.

Missing change triggers

The control also requires updates when organizational changes require them. Mergers, new cloud regions, a new business line that processes personal data, or a change in the risk executive are typical triggers. Write the triggers down as a short list in the strategy, and tie each one to a named owner who decides whether the strategy must be revised.

Approval that cannot be shown

A strategy that circulates as an unsigned draft leaves the assessor with no evidence of management endorsement. Record who approved the strategy, the approval date and the version number, and retain the approval record alongside the document. Confirm the approver holds the risk management leadership role the organization has assigned, since that person's sign-off is what makes the strategy binding.

Inconsistent use across business units

PM-9 expects the strategy to be implemented consistently across the organization, yet business units often apply their own risk scales, thresholds and acceptance rules. Ask each unit to show how it applies the strategy in a recent risk decision, and compare the results. Differences in scoring or risk acceptance are the findings an assessor is most likely to record.

No link to the POA&M process

A strategy that sets risk tolerance but does not connect to the plan of action and milestones process leaves remediation disconnected from risk decisions. Map how risks above tolerance enter the POA&M under PM-4, who prioritizes them, and how accepted risks are documented. Assessors reviewing PM-9 often trace one risk from the strategy into a POA&M entry to confirm the link is real.

Common questions about PM-9 cost, effort and whether to do it in-house

How much effort does PM-9 take to implement?

PM-9 takes as much effort as the organization's existing risk management practice needs to become a single written strategy that is applied consistently across the organization. The control asks for a comprehensive strategy covering security risk from operating and using organizational systems and privacy risk to individuals from authorized PII processing. The main effort is not the document itself. It is agreeing on risk tolerance, assigning owners, connecting the strategy to the risk assessment, the plan of action and milestones process and the continuous monitoring strategy, and then showing that the same approach is used in practice. Organizations with mature enterprise risk management usually need less effort than those where security and privacy risk are handled in separate silos. Ask any partner to size the work from a written scope that lists the business units, systems and existing documents in play.

How long does a first PM-9 risk management strategy take to produce?

The duration depends on how much of the strategy already exists and how many people must approve it. NIST does not set a timeline for implementing SP 800-53 controls, so any schedule is an internal planning decision. The main drivers are the number of business units and systems in scope, whether risk tolerance and risk framing decisions have already been made, how many executives must review and approve the strategy, and whether privacy and security risk are being integrated for the first time. A first draft can move quickly when leadership has settled its risk appetite. It slows down when decisions are deferred. Ask for a milestone plan with dated review points for leadership, privacy and security stakeholders, not just a delivery date for the document.

Can our own team write a PM-9 strategy without outside help?

Yes, in most organizations the internal team can write the strategy, because the control is a policy and governance artifact rather than a technical configuration. The organization owns its controls, and the people who understand the business, its risk appetite and its privacy obligations must make the decisions that the strategy records. Outside help is most useful when the team lacks experience with the NIST Risk Management Framework, has no current risk register to build from, or needs an independent check before leadership approval. An implementation partner can prepare drafts, supporting systems and evidence, but it cannot decide risk tolerance on the organization's behalf or issue an assessment result. An independent assessor is the party that tests whether the control is in place.

Is PM-9 in the low, moderate or high baseline?

PM-9 is not allocated to the low, moderate or high baseline. SP 800-53B describes Program Management controls as deployed organization-wide, supporting the information security program and independent of any system impact level. PM-9 is included in the SP 800-53B privacy baseline, which applies to systems irrespective of impact level. This matters for scoping: you do not add PM-9 to each system's baseline selection because of its impact categorization, but the organization still needs one strategy that covers all of its systems. If your program is subject to privacy requirements, confirm with the authorizing body which privacy baseline controls apply to your systems and how the organization-wide strategy is evidenced for them.

What does NIST say about compliance costs and timelines for PM-9?

NIST does not estimate certification or compliance costs, does not offer or endorse any compliance program or tool, and does not set federal implementation timelines. Those timelines are left to OMB Circular A-130. Under FISMA, Inspectors General independently assess agency system security and report to OMB. This means no official NIST figure exists for what PM-9 costs or how long it takes, and any number you see from a vendor or consultant should be traced to its basis. When you request a quote, ask for the cost components, which parts are one-time, which recurse each year, and what assumptions about scope and staffing sit behind the figure. The cost table on this page explains those components.

What must our organization provide to an implementation partner for PM-9?

A partner can only scope and prepare the strategy if the organization supplies its existing governance and risk material. Typical inputs include the current risk management policy and any risk appetite statements, the organization's risk register and assessment reports, the list of business units and systems in scope, privacy notices and PII processing inventories, the plan of action and milestones process, and the names of accountable executives who will approve the document. Name a single internal owner who can make decisions and access systems or records quickly. Under a fixed-scope engagement, the written scope should state which inputs the organization is responsible for and how delays in providing them affect the timeline.

How PM-9 relates to CSF 2.0 subcategories in NIST's crosswalk

NIST's OLIR catalog lists PM-9 as an informative reference for 17 CSF 2.0 subcategories: GV.OC-02, GV.OV-01, GV.OV-02, GV.RM-01 through GV.RM-07, GV.SC-03, GV.SC-09, ID.RA-04, ID.RA-06, DE.AE-04, PR.IR-04 and RC.RP-04. Most of these sit in the Govern function, which fits PM-9's purpose: a single organization-wide strategy for security risk from operating systems and privacy risk from PII processing. The mapping is useful for showing an assessor where your risk management strategy answers CSF outcomes such as risk management objectives, risk tolerance, supply chain risk and risk response. It is less useful as evidence on its own, because it says which CSF outcome a control informs, not whether your organization meets it.

NIST marks this crosswalk as not comprehensive, so treat the 17 subcategories as a starting point. Before you cite the mapping in a CSF profile, a SP 800-53 system security plan or a customer questionnaire, open the NIST OLIR catalog entry for the CSF 2.0 to SP 800-53 Rev. 5.2.0 crosswalk and confirm each row against the current release. Check two things in particular: whether PM-9 is listed in the direction you intend to cite, and whether the subcategories you need, such as ID.RA-05 on risk response or GV.PO on policy, are mapped to other PM or RA controls instead.

Record the result as a decision, not a copied table. For each subcategory you rely on, name the strategy document, the review date and the owner who approved it, then state whether your gap analysis treats the mapping as confirmed, partial or unmapped. A mapping you have verified and dated is defensible in an assessment. An unverified list copied from a third-party tool is the first thing a reviewer will challenge.

How DeployOpen scopes and prepares the PM-9 strategy and its evidence

DeployOpen helps organizations prepare the PM-9 risk management strategy documents, the processes behind them and the evidence an assessor will examine, interview and test against. The organization owns the strategy and its approval. DeployOpen prepares the systems, records and documentation, and an independent assessor reaches any conclusion about the control.

How we scope

Written scope names the organization-wide risk management strategy documents, owners and review cycle that PM-9 will cover.
Scope states which security risk from operating systems and privacy risk from PII processing are included in the strategy.
Scope lists the frameworks in use, such as NIST CSF 2.0 or privacy baselines, so the strategy can be traced to them.

How we build

We set up self-hosted open-source tooling inside your environment to hold the strategy, its risk register and review records.
We document the review and update process, including triggers for organizational change and the defined review frequency.
We test the process with a dry run so the examine, interview and test evidence is consistent before an assessor arrives.

How we hand over

You receive the strategy documents, process descriptions, configuration records and an evidence index mapped to PM-9 determination statements.
Handover includes a short walkthrough so named owners can answer assessor interview questions about the strategy.
Open items, gaps and owners are recorded in a written list so the organization can close them under its own governance.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and periodic reviews of the strategy are available as a retainer.
Confirm with your assessor which evidence formats and review frequencies they expect before the written scope is signed.