PM-28: Risk Framing

PM-28: Risk Framing requires you to identify and document the assumptions, constraints, risk tolerance, and risk priorities that will govern how your organization makes security and privacy risk decisions. To operationalize it fast, publish a risk framing statement, assign an owner, map it to decision points (A&A, architecture, third-party onboarding), and retain dated evidence that teams actually used it. ¹

Key takeaways:

• Risk framing is governance: it sets the “rules of the road” for risk decisions across the system lifecycle. ²
• Auditors look for documentation plus proof it drove real decisions (exceptions, authorizations, third-party requirements). ¹
• The fastest path is a single, approved risk framing memo that is cross-referenced in core workflows and reviewed on a defined cadence you can evidence. ²

Most programs fail PM-28 because they treat it like a philosophy slide, then can’t show how it changes day-to-day approvals. PM-28 is a management control in NIST SP 800-53 Rev. 5 that forces you to write down the organization’s risk posture in a way that engineers, system owners, procurement, and authorizing officials can apply consistently. ²

For a CCO, CISO, or GRC lead, the practical goal is simple: make risk decisions repeatable. If your team is debating whether to accept a vulnerability, onboard a cloud/SaaS third party, approve a new data flow, or grant an exception to baseline controls, PM-28 is the upstream artifact that tells them what “acceptable” means and who gets to decide. ²

This page gives you requirement-level implementation guidance: what the control is asking for, where it applies, how to implement it step-by-step, and what evidence you should retain for assessments. It also highlights common audit hangups and the implementation mistakes that create “paper compliance” without operational impact. ¹

Regulatory text

Control excerpt: “Identify and document:” ¹

Operator interpretation: NIST is requiring a documented risk framing output. The excerpt is short in the provided catalog view, but the operational expectation is clear: you must produce written, reviewable documentation that frames how your organization evaluates, accepts, and prioritizes risk so downstream controls and decisions follow a consistent approach. ³

What the operator must do: create a risk framing document (or set of linked documents) that is approved, maintained, and referenced in governance workflows. Then show evidence that it was used when making risk decisions (authorizations, risk acceptances, third-party requirements, exception approvals). ²

Plain-English requirement: what PM-28 is asking you to have

PM-28 expects a documented “risk lens” for the enterprise or program. Your risk framing should answer, in plain language:

• What types of impact matter most (mission, safety, legal/regulatory exposure, financial, operational resilience, privacy).
• What risk tolerance looks like (what you generally accept, what you rarely accept, and what requires senior approval).
• What constraints shape decisions (budget, staffing, architecture standards, cloud mandates, contractual obligations, inherited controls).
• What assumptions you are making (threat environment, expected user behavior, dependency reliability, data sensitivity).
• How to resolve tradeoffs (availability vs. confidentiality, delivery speed vs. control rigor, remediation SLAs vs. compensating controls).

The test: a system owner should be able to read it and know how to proceed without re-litigating the organization’s risk appetite in every meeting. ²

Who it applies to (entity + operational context)

PM-28 is most relevant where you must demonstrate a defensible, repeatable risk management approach, especially for:

• Federal information systems and programs assessed against NIST SP 800-53. ²
• Contractor systems handling federal data, where NIST-aligned governance is required by contract or assessment scope. ¹

Operationally, it applies whenever you:

• Authorize systems or services (ATO/A&A-style decisions or internal equivalents).
• Approve exceptions to baseline controls.
• Onboard and govern third parties that process, store, or transmit your data.
• Set security architecture patterns and “guardrails” for product teams.

What you actually need to do (step-by-step)

1) Name an accountable owner and approver path

• Assign a control owner (often Enterprise Risk, GRC, or Security Governance).
• Define approvers (e.g., AO, CISO, CIO, Privacy Officer), and who can accept which classes of risk.
• Put the ownership and approval workflow in writing.

Practical tip: if the owner cannot force adoption across procurement, architecture review, and change management, PM-28 turns into a document nobody reads. ²

2) Draft a one-page risk framing statement first

Start with a short memo that includes:

• Purpose and scope (enterprise-wide vs. specific program).
• Risk priorities (what the organization protects first).
• Risk tolerance bands (low/medium/high is fine if you define what each means in your environment).
• Escalation rules (what requires senior sign-off).
• How you treat inherited risk (cloud shared responsibility, managed services, government-furnished systems).

Keep the first version short to get approval quickly, then expand with appendices. ²

3) Translate framing into decision criteria teams can apply

Create a “decision mapping” table that ties framing to common decisions:

Decision point	What PM-28 must dictate	Example output
Risk acceptance / POA&M deferrals	Who can accept; what evidence required	Risk acceptance template + approval thresholds
Third-party onboarding	Minimum security/privacy requirements by data type	Contract/security addendum triggers; due diligence depth
Architecture review	Non-negotiable guardrails	Approved patterns; prohibited tech
Incident response prioritization	What gets priority	Severity rubric aligned to business impact

This is where PM-28 becomes operational. Without this mapping, auditors often conclude the program cannot prove consistent risk decisions. ²

4) Integrate into workflows (make it hard to ignore)

Embed references and checkpoints in:

• System authorization packages (include the risk framing doc as a referenced governance artifact).
• Exception management (the request form should require justification aligned to the risk framing).
• Third-party risk management (TPRM) (questionnaires, contract templates, and onboarding gates should point back to your framing assumptions and tolerance).
• SDLC gates (architecture review, threat modeling criteria, release approvals).

Daydream (as a practical tool choice) fits here when you need a single place to map PM-28 to an owner, implementation procedure, and recurring evidence artifacts so you can produce audit-ready outputs without rebuilding spreadsheets each cycle. ¹

5) Define recurring review triggers and document outcomes

Pick review triggers you can defend and evidence, such as:

• Major mission changes, new data types, new cloud service model, or material incidents.
• Annual governance refresh aligned to enterprise risk review.

Record review dates, what changed, and who approved. ²

Required evidence and artifacts to retain

Auditors typically want both “paper” and “proof of use.” Build an evidence pack:

1. Risk Framing Statement (dated, versioned, approved).
2. RACI / governance charter showing ownership and risk acceptance authority.
3. Decision mapping table tying framing to workflows (A&A, exceptions, TPRM, architecture).
4. Completed risk acceptances that cite the framing (samples across different risk levels).
5. Third-party onboarding records showing the framing influenced due diligence depth or contract requirements.
6. Meeting minutes or approval tickets showing updates and sign-offs.
7. Change log (what changed, why, impact).

The fastest “pass” pattern is consistent cross-referencing: the same framing ID/version appears in risk acceptances, exception tickets, and authorization artifacts. ¹

Common exam/audit questions and hangups

Expect these:

• “Show me your documented risk framing. Who approved it, and when was it last reviewed?” ²
• “How does this document change what teams do during exceptions or ATO decisions?” ²
• “Give examples where a request was denied or escalated because it exceeded risk tolerance.”
• “How do third-party requirements reflect your assumptions and constraints?”
• “Where is this referenced in system authorization or governance documentation?” ¹

Hangup to watch: teams produce a risk appetite statement from ERM that is too high-level to apply to systems. You need a security-and-privacy-operational version that drives control decisions. ²

Frequent implementation mistakes (and how to avoid them)

1. Writing framing that cannot be tested.
   Fix: add decision criteria and escalation rules that create observable outcomes (approved/denied/escalated). ²

2. No linkage to third-party governance.
   Fix: define how risk tolerance changes due diligence depth and contractual controls for third parties by data sensitivity and criticality. Use “third party” broadly, not just vendors. ²

3. No evidence of use.
   Fix: require the framing version ID in risk acceptance templates, exception forms, and A&A packages. ¹

4. Ownership without authority.
   Fix: set an approver chain where the risk framing owner can block exceptions that exceed tolerance without the right approval. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat PM-28 as an assessment-readiness and governance-defensibility control rather than an enforcement-citation-driven item. ¹

Risk implication is still real: weak risk framing leads to inconsistent exception decisions, uneven third-party requirements, and “who approved this?” failures after incidents. That pattern increases the chance of audit findings, delayed authorizations, and control inheritance disputes with partners and agencies. ²

A practical 30/60/90-day execution plan

First 30 days: establish the minimum viable framing

• Assign control owner, approvers, and risk acceptance authority levels.
• Draft and approve a one-page risk framing statement.
• Create an evidence plan: where the document lives, how versions are tracked, and what artifacts will reference it. ²

By 60 days: operationalize through workflows

• Build the decision mapping table for exceptions, A&A, third-party onboarding, and architecture review.
• Update templates: risk acceptance form, exception ticket fields, third-party intake checklist, and A&A documentation references.
• Train the reviewers (architecture board, TPRM, system owners) on how to apply the framing. ²

By 90 days: prove it works and close evidence gaps

• Pull samples of completed decisions (accepted risks, escalations, denied exceptions) that cite the framing version.
• Run an internal mini-audit: can you trace a decision from request → framing criteria → approval authority → evidence?
• Formalize review triggers and log at least one review cycle outcome (even if “no change”). ¹

Frequently Asked Questions

What’s the difference between “risk framing” and “risk assessment” for PM-28?

Risk framing sets the assumptions, constraints, and tolerance used to make risk decisions. Risk assessments apply that framing to specific systems, threats, and control gaps. ²

Can we reuse our enterprise risk appetite statement?

You can reuse it as an input, but PM-28 needs a security-and-privacy-operational artifact that teams can apply to exceptions, authorizations, and third-party requirements. If the statement doesn’t change decisions, it won’t satisfy the intent. ²

Who should approve the risk framing document?

Approval should match who is accountable for accepting mission and security risk in your organization (often an authorizing official, CIO/CISO, and privacy leadership). The key is a documented approval path you can evidence. ²

How do we show auditors that the framing is “used”?

Require the framing version to be cited in risk acceptances, exception tickets, and A&A artifacts, then provide a sample set of completed records. Meeting minutes and decision logs help show it guided outcomes. ¹

How does PM-28 connect to third-party risk management?

Your framing should state what risks you will not outsource, what minimum requirements apply by data type, and what level of assurance you require from third parties. Then your onboarding and contracting process must enforce those choices. ²

What’s the simplest “good enough” deliverable for a small program?

A short, approved risk framing memo plus updated templates that force teams to reference it during exceptions and third-party onboarding. Add a small set of decision records that demonstrate consistent application. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5

3. NIST SP 800-53 Rev. 5; Source: NIST SP 800-53 Rev. 5 OSCAL JSON