RMFInsider

An Authorizing Official accepts risk when four things are true on paper: the weakness is described precisely, the residual risk is stated in mission terms, compensating controls are named with evidence behind them, and the acceptance has an expiration date. A memo that delivers those four things gets signed. A memo that asks the AO to absorb an unbounded unknown gets returned, and usually without a reason attached.

This walks through where risk acceptance fits in RMF, how AOs weigh a decision, the exact sections of a memo that survives review, the failure patterns that get one rejected, and a worked example with real control identifiers. If you need the upstream document first, the risk assessment report guide covers how residual risk gets calculated before it ever reaches a memo.

Risk acceptance is a decision, not a filing step

NIST SP 800-39 and the risk response task in SP 800-37 Revision 2 give you four options for any identified risk: accept it, avoid it, mitigate it, or transfer and share it. Acceptance is the one that requires a signature from someone with the authority to bind the organization. Under DoDI 8510.01, effective July 19, 2022, AOs must be government personnel and cannot re-delegate the role. Your contractor lead cannot accept risk. Your ISSM cannot accept risk. They can recommend it.

Above the system level, DoDI 8510.01 assigns enterprise risk acceptance determinations to the DoD Information Security Risk Management Committee for authorized enterprise systems. That matters when your finding lives in a service you inherit rather than in anything you own.

An AO has never been called into an office for asking one more question about a memo. They have absolutely been called in for signing something they could not explain eighteen months later. Write for that room.

Where risk acceptance shows up in a package

• A POA&M item you have decided not to remediate, tracked under CA-5 rather than quietly closed.
• A STIG finding with a documented deviation and an approved justification recorded in the checklist.
• Residual risk carried forward in the Risk Assessment Report after mitigation has done everything it can.
• A control assessed as other than compliant in the Security Assessment Report where the assessor and the system owner disagree on feasibility.
• A condition attached to an authorization, which is a time boxed cousin of acceptance and behaves differently. The mechanics are in how an ATO with conditions works.

How AOs actually decide

An AO is not grading your writing. They are asking whether they can defend this decision to an inspector, a commander, and whoever reads the incident report if the weakness gets used. These are the factors that change the answer.

• Exploitability in context, not the raw severity label. A CAT I finding on a standalone system in a controlled space and the same CAT I on a system with an internet facing interface are two different conversations.
• The confidentiality, integrity, and availability impact levels set under FIPS 199 and CNSSI 1253, and for cloud hosted systems the DoD cloud impact level.
• Where the weakness sits relative to the authorization boundary and the SC-7 perimeter. Interior weaknesses behind strong boundary protection read differently than weaknesses on the boundary itself.
• Whether compensating controls reduce exploitability in a way you can actually evidence, as opposed to a paragraph asserting that the team is careful.
• Whether other systems inherit anything from this one. A weakness in a common control multiplies across every consuming package.
• The mission consequence of not operating. AOs weigh operational risk against cybersecurity risk, and one of those is easier for a commander to feel.
• Precedent. An AO who signs a broadly worded acceptance for one program will be handed the same wording by the next four, and they know it.
• Duration. A twelve month bounded acceptance with a named trigger is a much easier signature than an open ended one.

The anatomy of a memo they will sign

1. Subject line that names the system, the finding identifier, and the action requested. Something an AO can route from their phone without opening the attachment.
2. Reference block listing the SAR, the RAR, the POA&M item identifier, the applicable STIG and rule identifier, and the NIST SP 800-53 control identifier the finding maps to.
3. Finding statement in one paragraph of plain language that a non engineer can follow.
4. Why remediation is not feasible now, with a specific obstacle: a vendor release date, a contract modification, a hardware refresh cycle, or a dependency you can name.
5. Compensating controls, each with a control identifier, what is implemented, and where the evidence lives.
6. Residual risk statement expressed as likelihood and impact under NIST SP 800-30, then translated into a sentence about mission consequence.
7. Operational justification: what breaks or does not happen if the system stops operating.
8. Duration and review trigger: a calendar expiration plus the event that would force an earlier look.
9. Signature block for the AO, with coordination lines for the ISSM, the system owner, and the SCA as your organization requires.

The finding statement

Weak version: the system has a legacy encryption finding that cannot be corrected at this time. That tells the AO nothing and asks them to trust a stranger’s judgment. Strong version: control SC-8 is other than compliant because the vendor supplied reporting module listens on TCP 8080 and negotiates TLS 1.0, which the vendor will not remediate before the release scheduled for the third quarter of fiscal year 2027. The module is reachable only from eighteen workstations inside the enclave.

Specificity is not a style preference. It is the thing that lets the AO size the exposure without a follow up meeting.

The residual risk statement

Use the language of NIST SP 800-30 and then say what it means. Likelihood is moderate because exploitation requires an authenticated position inside the enclave. Impact is moderate because the module handles operational reporting data categorized at moderate for confidentiality and low for integrity. Residual risk after compensating controls is moderate. If successful exploitation occurred, the consequence is exposure of internal reporting data for a single mission area, with no path to the authentication infrastructure.

Do not write low unless you can show the arithmetic. An AO who reads low with no reasoning behind it will assume you are managing them rather than informing them.

Compensating controls

List controls that are implemented, not controls you intend to implement. Each line gets a control identifier, a one sentence description of the implementation, and a pointer to the artifact. If the artifact does not exist in eMASS yet, upload it before you route the memo, because an AO checking a citation and finding nothing is the fastest route to a rejection.

What gets a memo rejected

• No expiration date. An acceptance with no end date is a permanent liability with a signature on it.
• Compensating controls asserted with no artifact behind them.
• A residual risk rating with no likelihood or impact reasoning.
• A cost argument with no number in it. If remediation is too expensive, say what it costs and against what budget.
• A finding that a competent team could actually close in a sprint. AOs notice when a memo is cheaper than the fix.
• One memo covering nine unrelated findings. Bundle by root cause or write separate memos.
• A signature block naming someone who is not the AO, which is the fastest way to signal that nobody read the policy.

The other pattern worth calling out is the memo written to avoid a hard remediation conversation with an engineering team. Those get spotted. The guide to closing CAT I findings is worth reading before you decide a finding is unfixable, because a meaningful share of unfixable findings turn out to be unassigned.

A worked example

A moderate categorized mission support system inherits its hosting enclave from a service provider. The assessor writes up SC-8 and SC-13 as other than compliant because a vendor reporting module still negotiates TLS 1.0. The vendor has published a release date eleven months out. The system owner wants an acceptance.

The memo names SC-8 and SC-13, cites the SAR finding identifier and the corresponding POA&M item, and states the vendor release date as the remediation dependency. Compensating controls are SC-7, because the module is reachable only from a segmented VLAN with an access control list denying all other sources, AC-4 for the information flow enforcement rules that implement that restriction, AU-6 because the security operations center has a specific alert on connections to TCP 8080 from outside the approved source list, and CM-6 because the module’s configuration is baselined and monitored for drift. Every one of those has a configuration export or a screenshot attached in eMASS.

Residual risk is stated as moderate likelihood, moderate impact, moderate residual, with a sentence about what exposure of that reporting data would actually mean. The acceptance runs twelve months, expiring one month after the vendor release date, with an earlier review triggered if the module is exposed to any additional network segment. That is a memo an AO can sign in a morning.

Where it lives after the signature

1. Upload the signed memo to eMASS as an artifact and attach it to both the affected control and the POA&M item so anyone opening either one finds it.
2. Keep the POA&M item open with the accepted status and a comment pointing to the memo. Deleting the item is how findings reappear as surprises at the next assessment. The POA&M management walkthrough covers the tracking discipline.
3. Put the expiration date on the continuous monitoring calendar with a sixty day warning, not a same week reminder.
4. Run a CM-4 security impact analysis if anything about the environment changes, because a change to the boundary can invalidate the compensating controls the acceptance was built on.
5. Re-validate at the annual review. An acceptance that nobody revisits becomes an audit finding of its own.

Before you write one

• Confirm the finding is real and current. Re-scan or re-check the configuration rather than writing a memo against a stale checklist.
• Get the remediation estimate in writing from whoever would do the work, including the number.
• Draft the compensating control list first and see whether it is convincing. If it is thin, the answer is more mitigation, not better prose.
• Ask your ISSM which template your AO’s office actually uses, because local formats differ and a reformat round costs a week.

Risk acceptance done well is one of the more respectable artifacts an ISSO produces. It says the organization looked directly at a weakness, priced it, bounded it, and made a deliberate choice with a name on the bottom of the page. Done badly it is a piece of paper that converts a technical problem into a governance one. If you want a system for keeping accepted risks, expiration dates, and milestones visible instead of buried, the POA&M Tracker is built for exactly that.