PM-28: Risk Framing

PM-28 requires organizations to identify, document, and distribute the assumptions, constraints, priorities, trade-offs, and risk tolerance

Quick-reference card

FieldValue
Control IDPM-28
Control NameRisk Framing
FrameworkNIST SP 800-53 Revision 5
Control FamilyProgram Management
BaselinesPRIVACY
RelevanceOrganization (First Party)
Risk SeverityLow

What this control requires

PM-28 requires organizations to identify, document, and distribute the assumptions, constraints, priorities, trade-offs, and risk tolerance that shape every risk management decision. Without this foundation, risk assessments produce inconsistent results because different teams operate under different, unstated beliefs about what threats matter and how much risk the organization can absorb.

In practice, this control asks you to build and maintain a risk framing document that captures four categories of information. You need to record the assumptions your teams make when evaluating threats and vulnerabilities. You need to name the constraints that limit your risk response options, whether those constraints are budgetary, regulatory, or technical. You need to document the priorities and trade-offs leadership has accepted, such as choosing faster time-to-market over exhaustive testing. And you need to define organizational risk tolerance in terms specific enough to guide actual decisions. Organizations with complex supply chains should align this work with NIST SP 800-161 guidance on supply chain risk management, since vendor dependencies directly affect risk assumptions.

The results of this framing work don’t sit in a drawer. PM-28 requires you to distribute risk framing outputs to stakeholders across the organization, including mission owners, system owners, authorizing officials, and privacy officers. You must also review and update these considerations on a defined schedule, because the assumptions that held true last year may not survive a reorganization, a new product launch, or a shift in the threat landscape.

Why it matters

Most organizations treat risk decisions as though everyone shares the same mental model of what’s acceptable. They don’t. When risk tolerance is implicit rather than documented, every assessor applies their own interpretation, and the organization ends up with a patchwork of inconsistent risk decisions that no audit can reconcile.

Failure to implement PM-28 introduces audit risk and may result in certification withdrawal or regulatory findings. Assessors reviewing your program will look for documented evidence that risk framing occurred at the organization level. If that evidence doesn’t exist, they can’t verify that your risk assessments, risk responses, and continuous monitoring activities rest on a coherent foundation. The NIST SP 800-53 framework treats risk framing as a prerequisite for the entire risk management lifecycle, not an optional governance exercise.

Where this gap becomes visible is during cross-team audits. One business unit may accept risks that another unit would flag as unacceptable, and without a shared risk framing document, neither team is wrong. The organization has no authoritative reference to resolve the disagreement, which creates material inconsistencies in audit evidence.

The absence of documented risk tolerance also undermines your ability to defend risk acceptance decisions to regulators. If you’ve accepted a risk but can’t point to a documented tolerance threshold, the acceptance looks arbitrary rather than deliberate.

What attackers exploit

  • Inconsistent risk assessments across business units that leave entire threat categories unaddressed
  • Undocumented assumptions about which assets are in scope, allowing critical systems to fall outside monitoring coverage
  • Implicit risk tolerance that allows high-risk exceptions to persist without executive review
  • Stale risk framing documents that don’t reflect current threat conditions or organizational changes
  • Gaps between stated priorities and actual resource allocation, creating blind spots in risk response

How to implement

For your organization

The most common failure with PM-28 isn’t refusing to do risk framing. It’s producing a document that sits at such a high level of abstraction that it doesn’t change any downstream risk decision. Your risk framing output needs to be specific enough that an assessor reading a risk assessment can trace the reasoning back to documented assumptions and tolerances.

Step 1: Establish the risk framing working group. Bring together stakeholders from security, privacy, legal, operations, and business leadership. Risk framing conducted in isolation by the security team alone produces assumptions that don’t reflect operational reality. Communicating risk assessment results to stakeholders effectively starts with involving them in the framing process itself.

Step 2: Document assumptions. Catalog the assumptions each group makes when evaluating risk. These include assumptions about the threat environment, about the reliability of existing controls, about the accuracy of asset inventories, and about the competence of personnel. Be explicit about what you’re taking for granted.

Step 3: Identify constraints. Record the budgetary, legal, technical, contractual, and operational constraints that limit your risk response options. A constraint is anything that narrows the set of feasible risk treatments. Don’t overlook workforce constraints such as staffing shortages in specialized security roles.

Step 4: Define priorities and trade-offs. Document the trade-offs leadership has explicitly accepted. If the organization prioritizes availability over confidentiality for certain systems, say so. If speed of deployment takes precedence over full security review for certain product categories, record that decision and the rationale behind it.

Step 5: Articulate risk tolerance. Define risk tolerance in measurable terms wherever possible. Instead of “low risk tolerance for data breaches,” specify thresholds such as acceptable recovery time objectives, maximum acceptable data exposure windows, or financial impact thresholds that trigger escalation.

Step 6: Distribute and integrate. Share the completed risk framing document with all personnel involved in risk management activities. Integrate risk framing outputs into your risk management strategy so that they directly inform risk assessments, risk responses, and monitoring criteria.

Step 7: Schedule reviews. Set a defined review cadence, at minimum annually and after any significant organizational change such as mergers, new product lines, or major incidents.

Common tooling categories: governance, risk, and compliance platforms; enterprise risk management software; document management systems with version control; stakeholder collaboration tools.

Common mistakes:

  • Writing risk tolerance statements too vaguely to guide decisions
  • Failing to update risk framing after organizational changes
  • Limiting distribution to the security team instead of all relevant stakeholders
  • Treating risk framing as a one-time exercise rather than a living process
  • Documenting assumptions without validating them against current conditions

Evidence examples

Evidence TypeExample Artifact
Risk framing policyOrganizational policy defining the process for identifying and documenting risk assumptions, constraints, priorities, trade-offs, and risk tolerance
Risk tolerance statementBoard-approved risk tolerance document specifying acceptable impact thresholds by risk category, including financial, operational, reputational, and privacy criteria
Assumptions and constraints registerRegister listing each documented assumption and constraint affecting risk assessments, risk responses, and risk monitoring, with owner and review date
Risk management strategyStrategy document showing how risk framing outputs feed into risk assessment methodology, risk response selection, and continuous monitoring criteria
Distribution recordsEvidence of risk framing document distribution to designated personnel, including mission owners, system owners, authorizing officials, and privacy officers
Review and update logVersion history or change log showing periodic review and update of risk framing considerations, with dates and approving authority

Cross-framework mapping

FrameworkControl(s)Coverage
ISO 27001:20226.2 Terms and conditions of employmentPartial
ISO 27001:20227.4 Physical security monitoringPartial

The following controls within the Program Management family and related families interact directly with PM-28’s risk framing requirements.

  • CA-07, Continuous Monitoring. Continuous monitoring activities depend on the risk framing outputs to determine what to monitor, at what frequency, and against which thresholds.
  • PM-09, Risk Management Strategy. The risk management strategy consumes risk framing results as foundational inputs, translating assumptions and tolerances into operational risk management processes.
  • RA-03, Risk Assessment. Risk assessments rely on the documented assumptions, constraints, and risk tolerance from PM-28 to produce consistent, defensible results across the organization.
  • RA-07, Risk Response. Risk response decisions reference documented priorities and trade-offs from risk framing to select appropriate risk treatments within organizational constraints.

Frequently asked questions

What is NIST SP 800-53 PM-28

PM-28 is the NIST SP 800-53 control that requires organizations to identify, document, and distribute the assumptions, constraints, priorities, trade-offs, and risk tolerance guiding their risk management program. It sits within the Program Management family and applies to the PRIVACY baseline. The control ensures that everyone involved in risk assessments, risk responses, and risk monitoring operates from a shared, documented understanding of organizational risk parameters. Organizations must also review and update these risk framing considerations on a defined schedule.

What happens if PM-28 is not implemented

Without PM-28, your organization lacks documented risk tolerance thresholds and risk assumptions, which means different teams make inconsistent risk decisions with no authoritative reference to resolve disagreements. Assessors will flag the absence of risk framing documentation as a gap during audits, since they can’t verify that risk assessments rest on a coherent foundation. Over time, undocumented constraints and unstated trade-offs lead to risk acceptance decisions that are indefensible when regulators or auditors ask for justification. The result is increased audit findings and potential difficulties maintaining certifications that require evidence of structured risk management.

How do you audit PM-28

Auditors assess PM-28 by examining whether the organization has documented its risk assumptions, constraints, priorities, trade-offs, and organizational risk tolerance in a formal risk framing output. They verify that distribution records show these results reached designated personnel, including mission owners, authorizing officials, and privacy officers. Auditors also check for evidence that risk framing considerations have been reviewed and updated according to the organization’s defined frequency. Finally, they trace downstream risk assessments and risk responses back to the documented risk framing outputs to confirm that framing decisions actually influenced operational risk management activities.

How does risk framing differ from risk assessment

Risk framing establishes the context and boundaries within which risk assessments operate, while risk assessment is the process of identifying and evaluating specific threats, vulnerabilities, and impacts within that context. PM-28 focuses on documenting assumptions, constraints, risk tolerance, and organizational priorities before any assessment begins. Risk assessment (addressed by RA-03) then applies those parameters to evaluate specific risks against the framing criteria. Without risk framing, risk assessments lack a consistent baseline, and two assessors evaluating the same system may reach different conclusions because they’re operating under different unstated assumptions about what constitutes acceptable risk.

Experience superior visibility and a simpler approach to cyber risk management