RMFInsider

RMF Step 5 is the Authorize step, and it ends with one person deciding whether to sign. The authorizing official (AO) reads the authorization package, weighs residual risk against the mission the system supports, and issues a decision. NIST SP 800-37 Revision 2 defines four outcomes: an authorization to operate, a common control authorization, an authorization to use, and a denial of authorization. DoDI 8510.01, effective 19 July 2022, is the version you actually work under in eMASS, and it points to interim authorization to test (IATT), ATO, ATO with conditions, and denial of ATO. That same instruction defines the security authorization package in exactly three items: the security plan, the security assessment report, and all POA&Ms. Everything your component asks for beyond those three is local flavor.

What Actually Lands on the AO Desk

An AO with a portfolio of systems is not reading your 400-page system security plan cover to cover. What reaches the desk is a briefing package built from the three required artifacts, and the parts that get read closely are predictable.

The single most consequential document is the security assessment report, because it is written by someone who does not report to the system owner. The SAR is where the assessor states what was tested, what failed, and how bad the failures are. If you have never read one from the AO side of the table, the structure of a SAR and how to read your own findings is worth an hour of your life before you submit anything.

Here is the stack, in the order it tends to get attention:

• The SAR executive summary and the finding counts by severity, usually broken out as CAT I, CAT II, and CAT III.
• The risk assessment report or risk determination narrative, which translates raw findings into mission impact.
• The POA&M, specifically the count of open items, the scheduled completion dates, and whether any date has already slipped once.
• The system security plan, read selectively: the categorization, the authorization boundary description, and the implementation statements for whatever control family the SAR flagged.
• The authorization boundary diagram and the hardware and software list, checked against each other for anything the diagram shows but the inventory does not.
• Scan results with dates on them, because a scan older than the last patch cycle tells the AO the package is stale.

Nobody has ever been granted an ATO because of a beautiful boundary diagram. Packages do get sent back because the diagram and the hardware list disagree about whether a jump box exists.

The Five Tasks Inside Step 5

SP 800-37 Revision 2 breaks the Authorize step into five tasks. Knowing the sequence matters because it tells you which conversations happen before the decision and which happen after.

1. R-1, Authorization Package. The system owner or common control provider assembles the package and submits it to the AO. In eMASS this is a workflow action, not an email.
2. R-2, Risk Analysis and Determination. The AO or the AO designated representative analyzes the assessment findings and determines the risk to operations, assets, individuals, other organizations, and the nation.
3. R-3, Risk Response. The organization decides how to respond to the determined risk: accept it, mitigate it, transfer it, or avoid it. This is where conditions and POA&M commitments get negotiated.
4. R-4, Authorization Decision. The AO determines whether the risk is acceptable and issues the decision, after input from the senior accountable official for risk management or the risk executive function.
5. R-5, Authorization Reporting. The decision, the terms and conditions, and the authorization termination date are reported to the system owner, the CIO, and whoever else the organization designates.

R-3 is the task ISSOs underestimate. By the time the package reaches R-4 the negotiation is over. If you want a finding treated as an accepted risk rather than a blocking condition, the argument has to be in the package at R-2 and R-3, written down, with a compensating control named.

The Decision Types, Plainly

What NIST Defines

An authorization to operate means the AO found the risk acceptable and the system may run for a defined period, ending on an authorization termination date the AO sets. The AO can attach operating restrictions: limited user populations, limited connectivity, restricted data types, or enhanced monitoring.

A common control authorization is the same decision applied to controls a provider offers for inheritance rather than to a system. An authorization to use is the reciprocity mechanism: your organization reviews an authorization package another organization already produced and chooses to accept it, sometimes after asking for supplemental controls. A denial of authorization means the system is not authorized and does not go into operation. There is also authorization rescission, which pulls an existing authorization when terms are violated.

What DoD Uses

DoDI 8510.01 names interim authorization to test, ATO, ATO with conditions, and denial of ATO. An IATT is narrow on purpose: it authorizes testing with live data in an operational environment, not operations. ATO with conditions is the one that causes the most confusion, because it is a real authorization, the system runs, and the conditions carry deadlines that the AO can enforce by rescinding. If that is where your package is headed, read what the conditions actually obligate you to do and what happens when you miss one before you celebrate the signature.

How an AO Weighs Risk

AO decisions look arbitrary from the outside because the inputs are not evenly weighted. Three things move the needle harder than the rest.

First, severity concentration. Fifty open CAT III findings on a standalone training system reads very differently from two open CAT I findings on a system with an external connection. The AO is reading for exploitability against this boundary, not for a clean scorecard.

Second, credibility of the remediation plan. A POA&M with milestone dates that already slipped once is worse than a POA&M with a long but honest schedule, because it tells the AO the organization does not control its own delivery. A well-built risk assessment report is where you make that credibility case in prose rather than leaving the AO to infer it from dates.

Third, mission urgency. This is the input nobody documents. A system the commander needs next quarter gets an ATO with conditions where a system nobody is waiting on gets sent back for rework. That is not corruption, it is risk management doing what it is supposed to do, but it explains why two packages of similar quality get different answers.

What Delays the Decision

Step 5 delays are almost never the AO reading slowly. They are package defects that force a round trip.

• Controls marked compliant in eMASS with no artifact attached, or with an artifact attached to the wrong assessment procedure.
• A SAR that references findings the POA&M does not contain, or a POA&M with items the SAR never raised.
• Inherited controls that were never formally accepted, so the package claims coverage the provider has not granted.
• Scan results and STIG checklists dated before the last configuration change captured in the change log.
• A boundary description in the SSP that contradicts the boundary diagram, usually because a cloud service got added and only one document was updated.
• Missing signatures in the package approval chain, which stalls the workflow before the AO ever sees it.

If your package keeps bouncing at the submission gate rather than at the decision, work the pre-flight checklist for submitting an authorization package in eMASS until the workflow moves cleanly on the first try. The AO cannot decide on a package that never arrives.

After the Signature

The ATO letter names an authorization termination date, terms and conditions, and in a growing number of DoD components a continuous monitoring frequency instead of a hard expiration. The moment the letter is signed you are in Step 6, and the obligations in the letter are now auditable commitments. Conditions with 30-day and 90-day deadlines get tracked by the AO staff whether or not anyone reminds you.

One 2026 caveat worth stating plainly: DoD stood up the Cybersecurity Risk Management Construct in September 2025 as a phased successor to RMF, and components are absorbing it at different speeds. As of this writing, RMF Step 5 as described above is still how the overwhelming share of DoD authorization decisions get made, and the artifacts have not changed. What is changing is the expectation that authorization becomes continuous rather than a calendar event, which is exactly the direction ongoing authorization and cATO were already pushing.

The practical takeaway for an ISSO is that Step 5 rewards preparation done in Steps 3 and 4. An AO signs packages that answer questions before they are asked: what is the worst finding, why is it survivable, who owns the fix, and what date does it close. If you want a repeatable way to get a package into that shape, the RMF Checklist walks the artifacts and the order to build them in, so nothing shows up missing the week you submit.