RMFInsider

DoD Instruction 8510.01, Risk Management Framework for DoD Systems, is the policy document that makes RMF mandatory inside the Department of Defense. NIST SP 800-37 describes RMF as a process any federal agency can use; DoDI 8510.01 is what turns that description into an order for every DoD component, system, and program. It assigns the roles (AO, SCA, ISSM, ISSO, and the rest), sets the rules for authorization decisions, requires the use of eMASS or a component-approved equivalent, mandates reciprocity between components, and defines what happens when an authorization expires. If your job title contains ISSO, this instruction is the reason your job exists.

The version in force as of 2026 is the July 19, 2022 reissue, which replaced the 2014 version and its three changes. I read the 2014 version as a new ISSO and thought it was dense; the 2022 version is longer but answers questions the old one left to interpretation. This post covers what it requires, the roles it defines, what changed in 2022, how it fits with CNSSI 1253 and 800-37, and where it stands under CSRMC.

What DoDI 8510.01 requires, in one list

Strip away the enclosures and the instruction makes a short set of demands. Every DoD system, and the 2022 version is explicit that this includes IT, operational technology, weapon system components, and platform IT, must:

• Be categorized using CNSSI 1253, not FIPS 199 directly. The impact values for confidentiality, integrity, and availability come from the CNSSI 1253 tables, and the CNSSI 1253 categorization walkthrough covers how that differs from the civilian approach.
• Have a security control baseline selected from CNSSI 1253 and NIST SP 800-53, tailored with documented justification, and recorded in the authorization package.
• Implement the controls and document the implementation, using the RMF Knowledge Service and DISA STIGs as the primary sources for how to implement.
• Be assessed by a Security Control Assessor who is independent of the system owner for the purpose of the authorization decision.
• Receive an explicit authorization decision from an Authorizing Official before operating, recorded in eMASS or a component-approved tool. Operating without an authorization decision is prohibited.
• Be continuously monitored under an approved strategy, with the authorization reviewed when significant changes occur and, absent ongoing authorization, reauthorized before the ATO expires.
• Honor reciprocity: a system authorized by one DoD component is presumed acceptable to another, and the receiving component must review the existing authorization package rather than starting over.

None of that is new to anyone who has read the introduction to RMF, because the six steps are the same. What the instruction adds is the word “must,” the specific DoD roles who must do each thing, and the consequences.

The three tiers and who sits in them

8510.01 organizes risk management into the three tiers from 800-39 and names the DoD bodies at each level:

• Tier 1, Organization: The DoD CIO, the DoD Senior Information Security Officer (SISO), and the DoD Information Security Risk Management Committee (ISRMC). The RMF Technical Advisory Group (TAG) reports up here and maintains the RMF Knowledge Service, which is where the DoD-specific implementation guidance actually lives.
• Tier 2, Mission and Business Process: The DoD Component CIOs and Component SISOs. The Component SISO appoints AOs and SCAs, and the Component CIO is accountable for the component’s overall cybersecurity risk posture.
• Tier 3, System: The AO, the SCA, the Program Manager or System Manager, the ISSM, the ISSO, and the user representative. This is where the packages get built.

The tiers matter when you need an exception. An ISSO cannot waive a control. An AO can accept risk for a system. Only the Component SISO or higher can change how the component applies the framework. I have watched programs spend months asking a tier for a decision it had no authority to make.

The roles the instruction defines

The role definitions in 8510.01 are the reason DoD job descriptions look the way they do. Here is what the instruction actually says each one owns:

Authorizing Official (AO)

A senior official with the authority to formally assume responsibility for operating a system at an acceptable level of risk. The AO issues the authorization decision, must be a U.S. government employee (not a contractor), and can delegate day-to-day work to an Authorizing Official Designated Representative (AODR) but cannot delegate the authorization decision itself.

Security Control Assessor (SCA)

The independent assessor who conducts the assessment, produces the Security Assessment Report, and provides the risk recommendation to the AO. The independence requirement is explicit: the SCA cannot be under the management chain of the program being assessed for the purpose of the authorization decision.

Program Manager / System Manager (PM/SM)

The Information System Owner in NIST language. The PM/SM owns the system’s cybersecurity across the life cycle, funds the security work, and appoints the ISSM and ISSO. When something is not resourced, this role owns that decision.

Information System Security Manager (ISSM)

The primary cybersecurity technical advisor to the AO and the PM/SM, responsible for the cybersecurity program across a system or a set of systems. The ISSM maintains the authorization package, oversees the ISSOs, and is the person who formally submits the package for authorization.

Information System Security Officer (ISSO)

Appointed in writing, the ISSO is responsible for the day-to-day security of a specific system: maintaining the security posture, ensuring controls stay implemented, tracking POA&M items, coordinating with system administrators, and reporting to the ISSM. The instruction is clear that the ISSO is responsible for the system’s security state, not just its paperwork, which is a distinction worth remembering when a system administrator suggests that STIGs are “your thing.”

Common Control Provider (CCP)

An organization responsible for the implementation, assessment, and monitoring of common controls that other systems inherit. The CCP has its own authorization and its own ISSM, which is why inheritance in eMASS requires the provider to have approved controls before you can inherit them.

The instruction also requires the ISSM and ISSO to meet the qualification requirements of DoDM 8140.03, which is how the workforce policy and the RMF policy connect.

Authorization decisions and how long they last

8510.01 defines the four possible outcomes of an authorization decision and the rules around each:

• Authorization to Operate (ATO): The system may operate. The authorization term is set by the AO but may not exceed three years unless the system is under an approved ongoing authorization program, in which case the expiration is replaced by continuous review.
• ATO with conditions: An ATO in which the AO requires specific actions by specific dates. The system is authorized, but the AO can modify or revoke the decision if the conditions are not met.
• Interim Authorization to Test (IATT): Permission to operate in a test environment for a limited period, with the explicit restriction that live operational data and operational networks are not used except as specifically authorized.
• Denial of Authorization to Operate (DATO): The system may not operate, or must cease operating. A DATO is a decision, not the absence of one, and it is recorded in eMASS like any other.

The instruction also states that an expired ATO is not an authorization. There is no grace period built into policy; if the AO has not signed a new decision by the expiration date, the system is operating without authorization and the AO is expected to issue a DATO or an extension. The reauthorization process when an ATO expires exists because that deadline is real, even when the enforcement is uneven.

What changed in the 2022 reissue

The 2014 version served for eight years, and its age showed. The July 2022 reissue made changes that affect daily work:

• Scope expanded and clarified. The title changed from “for DoD Information Technology” to “for DoD Systems,” and the text explicitly pulls in operational technology, control systems, weapon systems, and platform IT. Programs that had argued their embedded systems were out of scope lost that argument.
• Alignment with NIST SP 800-37 Rev 2. The Prepare step, the emphasis on organization-level risk management, and the updated terminology were adopted. The instruction now references 800-53 Rev 5 and the corresponding CNSSI 1253 updates.
• Ongoing authorization formalized. The 2014 version allowed it in principle; the 2022 version defines the conditions under which an AO can move a system from a fixed-term ATO to ongoing authorization based on a mature continuous monitoring program. This is the policy basis for the cATO memo that followed.
• Reciprocity strengthened. The language moved from encouraging reciprocity to requiring it, with a stated expectation that a receiving AO reviews the existing authorization package and documents any additional requirements rather than re-assessing from scratch.
• Role titles updated. The Component Senior Information Assurance Officer became the Component SISO, and the qualification reference moved from 8570.01-M to the 8140 series.

If your templates date from the 2014 version, the differences you will feel are the Prepare step artifacts, the continuous monitoring strategy being due at authorization rather than after it, and the tighter reciprocity language.

How 8510.01 relates to CNSSI 1253, 800-37, and 8500.01

The document stack is easier to remember as a chain of “who says so.” NIST SP 800-37 defines the RMF process for the federal government. NIST SP 800-53 defines the control catalog. CNSSI 1253 is the Committee on National Security Systems instruction that adapts the categorization and baseline selection for national security systems, replacing FIPS 199 and FIPS 200 in that space. DoDI 8500.01, Cybersecurity, is the parent DoD policy that establishes the cybersecurity program and adopts the NIST and CNSS framework. DoDI 8510.01 sits under 8500.01 and implements RMF specifically, telling DoD components how to execute the process, using the CNSSI 1253 baselines and the 800-53 controls, inside eMASS, with the roles above.

When two of these appear to conflict, 8510.01 governs process questions inside DoD, CNSSI 1253 governs categorization and baselines, and the RMF Knowledge Service is where the DoD CIO publishes the reconciliation.

Where 8510.01 stands during the CSRMC transition

In September 2025 the DoD CIO announced the Cybersecurity Risk Management Construct, a five-phase model built around continuous monitoring, automation, and DevSecOps-aligned authorization. The overview of CSRMC and what it replaces covers the construct itself, and the comparison of CSRMC and RMF covers the practical differences for ISSOs. The policy question is simpler: as of this writing, DoDI 8510.01 has not been rescinded or reissued. CSRMC is being implemented under the existing instruction’s authority, using the ongoing authorization provisions the 2022 version added. Until a new instruction or a formal change is published, the roles, decision types, and requirements above remain the governing policy, and an assessor will hold your package to them.

Build packages that satisfy 8510.01 as written while adopting the CSRMC habits the instruction already permits: automated evidence collection, a continuous monitoring strategy that actually runs, and a POA&M that reflects reality. That package survives the transition in either direction.

What to do with this as an ISSO

Read the instruction once, front to back, with the enclosures. It takes an afternoon and settles a dozen arguments you have not had yet. The next time a contractor proposes to serve as the AO, the answer is a paragraph number. If you want the requirements above translated into a working package checklist that tracks each 8510.01 obligation to the artifact that proves it, the RMF Checklist is the document I built for exactly that purpose.