The DoD ATO Process, Step by Step (2026)

Commercial cloud software reaching a Department of War (DoW) mission has to clear two authorizations before it can carry live workloads: a Defense Information Systems Agency (DISA) Provisional Authorization (PA) for the underlying cloud offering, then a mission owner's Authority to Operate (ATO) for the workload itself.

The Department of War is the current name for the former Department of Defense (DoD), adopted under Executive Order 14347 (September 2025), yet the authorization pathway is still widely known as the DoD ATO process.

Those authorizations sit on top of the seven-step Risk Management Framework (RMF), and the timeline is rarely short. Under NIST's RMF, the ATO process typically takes 6 months to over 2 years. That range determines when a signed DoW deal can move into deployment.

Key Takeaways

• ATO is risk acceptance. The National Institute of Standards and Technology (NIST) explains that the AO accepts residual security risk left after controls are implemented and tested and cannot delegate that acceptance.  
• RMF has seven steps. The 2018 revision added Prepare, and the current DoW instruction follows all seven; older guides still list six.  
• Impact level drives everything. Impact level (IL) is set during categorization (Step 2 of the Risk Management Framework (RMF)) and drives DoW cloud security requirements and which DISA-authorized cloud environments are eligible for the workload.  
• Reciprocity is partial. IL-2 reciprocity is automatic, IL-4 and IL-5 add DoW-specific controls and a DISA review, and IL-6 has no Federal Risk and Authorization Management Program (FedRAMP) path.

A DoW ATO Is Official Acceptance of a System's Residual Security Risk

NIST defines an authorization to operate as an "Official management decision given by a senior Federal official or officials to authorize operation of an information system and to explicitly accept the risk to agency operations."

NIST SP 800-37 Rev2 adds that this acceptance "cannot be delegated to other officials within the organization," and DoD Instruction (DoDI) 8510.01, "Risk Management Framework (RMF) for DoD Systems" (last reissued July 19, 2022), applies that framework across the department's systems. The instruction retains its DoD number and title because it has not been reissued under the DoW issuances program. The named AO accepts whatever risk remains after implementing and testing controls. An ATO certifies nothing about zero risk, and the AO may downgrade or revoke it at any time.

A DISA PA pre-qualifies a cloud service offering at a given impact level for DoW contracts but authorizes no specific workload, while a FedRAMP authorization process covers unclassified federal data. That division of authorization scope determines how the RMF package is assembled.

The Seven RMF Steps Govern Every DoW Authorization Decision

(DoDI) 8510.01 aligns the DoW to the seven-step model in NIST SP 800-37 Rev2. The 2014 edition numbered six steps, Categorize through Monitor; Prepare is the step older guides miss. Each step has a named owner, and packages stall when the wrong role is holding the artifact.

1. Prepare

The organization assigns risk management roles across the enterprise and mission tiers and sets tailored control baselines that reflect the system's risk profile. The Program Manager (PM) or System Owner registers the system in the DoW Component Registry and defines the authorization boundary that scopes every downstream activity.

Output: system registration, defined authorization boundary, and tailored control baselines ready for categorization.

2. Categorize

The System Owner, supported by the Information System Security Manager (ISSM) and Information System Security Officer (ISSO), rates the impact of losing confidentiality, integrity, and availability for the information the system processes. That rating maps directly to a DoW cloud impact level and dictates which cloud environments and control sets apply downstream.

Output: the documented categorization decision that drives control selection.

3. Select

The System Owner selects and tailors controls from NIST SP 800-53 Rev5 (September 2020) to match the categorization decision, layering in DoW-specific FedRAMP+ controls where the impact level requires them. The tailoring must justify every added, removed, or modified control.

Output: the initial System Security Plan (SSP) and a Security Control Traceability Matrix (SCTM) listing every selected control and its inheritance source.

4. Implement

The System Owner and PM implement the selected controls in the system and document how each one is configured, enforced, and evidenced. Implementation covers technical, operational, and management controls, and records inherited controls with their provider. Any gaps identified here typically translate into remediation work before assessment begins.

Output: the SSP updated with detailed implementation narratives for every selected control.

5. Assess

An independent Security Control Assessor (SCA) tests whether the implemented controls are correctly configured, operating as intended, and producing the expected outcomes. Remediate non-compliant findings where possible, and place residual issues in a Plan of Action and Milestones (POA\&M) with owners and target dates.

Output: the Security Assessment Report (SAR) documenting test results and the POA\&M tracking open findings.

6. Authorize

The Authorizing Official (AO) reviews the full authorization package. DoDI 8510.01 defines that package as the security plan, SAR, all POA\&Ms, and the authorization decision document. Based on residual risk, the AO issues an ATO, an ATO with conditions, an Interim Authorization to Test (IATT), or a Denial of Authorization to Operate (DATO).

Output: the signed authorization decision document.

7. Monitor

The ISSM and ISSO track configuration changes, run scheduled control assessments, respond to incidents, and update the SSP, SAR, and POA\&Ms so the package reflects the system's current posture. Continuous monitoring is what keeps the AO's risk decision defensible between reauthorizations.

Output: continuous monitoring compliance reports and updated package artifacts.

Authorizing Officials, ISSOs, and Assessors Each Own a Distinct ATO Role

NIST SP 800-37 Rev2 and DoDI 8510.01 fix each role's duties, and packages move faster when each artifact lands on the right desk.

• AO. Government personnel only; NIST calls the role "an inherent U.S. Government function." Other duties can pass to an Authorizing Official Designated Representative (AODR); the decision itself cannot. For cloud offerings, the DISA AO issues every DoW PA.  
• System Owner. Owns the system description and categorization, selects and tailors controls, assembles the authorization package, and submits it to the AO.  
• Program Manager (PM). Implements the RMF for the program and owns schedule and resources.  
• ISSM and ISSO. The ISSO holds day-to-day security responsibility for the system's security posture. The ISSM, a DoW-specific supervisory role, reports authorization status and directs the ISSO.  
• SCA and Third-Party Assessment Organization (3PAO). The SCA independently determines whether controls are implemented correctly and writes the SAR. A commercial 3PAO assessment firm is an accredited commercial firm that assesses cloud service offerings for FedRAMP and for DISA PAs.

A 3PAO tests the SaaS vendor's cloud offering for the PA; the mission owner's SCA and AO handle the workload ATO. Those role assignments determine who makes and documents the impact-level decision at categorization.

Impact Level Is Set at Categorization and Drives Every Control Decision

DoW cloud categorization uses the DoD Cloud Computing Security Requirements Guide (CC SRG) V1R6 (December 2025). The CC SRG maps data sensitivity to impact levels and is published in two forms: a Cloud Service Provider (CSP) SRG for cloud providers and a Mission Owner SRG for DoW program managers.

The impact level dictates which DoW-specific FedRAMP+ controls and data-handling requirements apply, along with which DISA-authorized cloud environments can host the workload.

• IL-2. Public-release data and non-critical internal information that is not Controlled Unclassified Information (CUI). The offering must hold a qualifying current FedRAMP Moderate authorization and satisfy applicable DoW additions, and DISA's blanket PA covers any FedRAMP Moderate offering without a separate DoW authorization.  
• IL-4. CUI and mission data supporting military or contingency operations. The offering must hold a qualifying current FedRAMP Moderate or High authorization, satisfy applicable FedRAMP+ controls, route connectivity through a Cloud Access Point, and have a DISA PA.  
• IL-5. Unclassified National Security Systems (NSS). The offering must satisfy FedRAMP High plus additional DoW requirements, and it requires a DISA PA.  
• IL-6. Information classified up to SECRET, on dedicated classified infrastructure with cleared personnel. A DISA PA is required, and no FedRAMP reciprocity path exists.

Moderate and High remain Federal Information Processing Standards (FIPS) 199 security categories, not control-baseline selectors. IL-1 needs no categorization, and IL-3 was folded into IL-4.

Current FedRAMP Rev5 control lists use NIST SP 800-53 Rev5 baseline controls. Under the FedRAMP Consolidated Rules for 2026, those lists are selected by Certification Class. The rules were released June 24, 2026, and become mandatory January 1, 2027.

DoW ATO Timelines Run from Four to Eighteen Months, Longer for Complex Systems

A DoW Code and Defense Acquisition University (DAU) training guide puts the ATO process at four to six months. Systems that run through sequential, manual workflows commonly take six to eighteen months, and the longest published estimates run past two years. For a cloud offering, the PA starts its clock before the mission-owner ATO begins.

Several recurring bottlenecks extend that schedule.

• Documentation volume. The SSP, SAR, SCTM, and POA\&M for a moderate system cover hundreds of controls, and maintaining them in Word and spreadsheets is slow and error-prone.  
• Assessor scheduling. Assessor availability and scheduling can extend the authorization timeline.  
• AO queue depth. AO review and decision-making can add time to a completed package.  
• Boundary definition. If the AO judges the authorization boundary improperly drawn, the package goes back for major rework.  
• Sponsorship. A vendor submits its package to a sponsor's AO, and a vendor without an active DoW contract has none.

A boundary rewrite in month six pushes the assessor slot and the AO review behind it. That schedule pressure continues after authorization unless the program can replace periodic reauthorization with continuous risk determination.

Continuous ATO Replaces Periodic Reauthorization with Ongoing Real-Time Compliance

Under DoDI 8510.01, a standard ATO carries an Authorization Termination Date within three years, and a significant change in cybersecurity posture can force reauthorization earlier. Continuous Authorization to Operate (cATO) is DoW's alternative to that cycle.

The DoD CIO memorandum of February 3, 2022, issued the same day as the DoD Software Modernization Strategy, established it as a move from point-in-time assessment toward continuous risk determination. A cATO does not expire as long as the required real-time risk posture is maintained; it can be revoked if that posture lapses.

The memo names three competencies the AO must see:

• Continuous monitoring of RMF controls inside the boundary.  
• Active cyber defense in real time.  
• An approved DevSecOps reference design.

A system must already hold an RMF ATO before pursuing cATO, and the cATO Evaluation Criteria review the existing authorization and continuous monitoring strategy. Continuous evidence can keep an existing decision current, while reciprocity determines which prior assessments can be reused to reach that decision.

FedRAMP and DoW ATO Share Reciprocal Credit in Specific Circumstances

DoDI 8510.01 directs the DoW Information Enterprise to use cybersecurity reciprocity to cut redundant testing and documentation. The CC SRG implements that direction through the FedRAMP reciprocal security framework: FedRAMP assessment results are the base, and the DoW-specific controls in Appendix D of the CSP SRG are added on top.

At IL-2, the blanket PA makes reciprocity automatic for any FedRAMP Moderate offering. At IL-4, FedRAMP Moderate or High provides a base, but additional DoW requirements and review still apply before DISA issues the PA.

At IL-5, FedRAMP High is the starting point, but additional DoW requirements apply. DoW reciprocity reduces duplicate work but does not eliminate DoW review. Teams can implement that residual scope themselves or inherit more of it from a pre-authorized boundary.

Pre-Authorized Infrastructure Reduces the RMF Work Vendors Must Run Themselves

Authorization timing is a deployment constraint because full, temporary, and denied authorizations determine what a program can do next. Both authorizations are required, but the provisional authorization is the layer a vendor can inherit. When a SaaS vendor builds its own infrastructure, it executes more of the seven steps; when it operates inside a boundary already covered by a DISA PA, it inherits most of the controls.

Knox Systems delivers FedRAMP in about 90 days for 90% less, running a pre-authorized FedRAMP-as-a-Service boundary that enables vendors to inherit up to 80% of the required NIST SP 800-53 Rev5 controls. It currently supports FedRAMP Moderate, FedRAMP High, and DISA IL-4; IL-5 authorization is in process, with estimated completion in December 2026.

Book a meeting to map data impact level and boundary against the deal at hand.

FAQs about the DoD ATO Process

What Is the Difference Between an ATO, an IATT, and a DATO?

An ATO is a full authorization letting a system operate in production, typically valid for up to three years. An Interim Authorization to Test (IATT) is a short-term decision allowing a system to run in a controlled environment for testing only, not production use. A Denial of Authorization to Operate (DATO) means the AO has judged residual risk unacceptable and blocked operation.

Who Can Serve as an Authorizing Official for a DoW System?

Only U.S. Government personnel can serve as an AO, because NIST classifies the role as an inherent government function that cannot be outsourced. The AO may delegate supporting duties to an Authorizing Official Designated Representative (AODR), but the risk-acceptance decision itself is non-delegable. For DoW cloud service offerings seeking a Provisional Authorization, the DISA AO issues the decision.

How Long Does a DoW ATO Remain Valid?

Under DoDI 8510.01, a standard ATO carries an Authorization Termination Date of up to three years, at which point the system must be reauthorized. Significant changes to the system's cybersecurity posture can trigger reauthorization sooner. A continuous ATO (cATO), by contrast, does not expire on a fixed schedule and remains in effect as long as the required real-time monitoring and defense competencies are sustained.

Does a FedRAMP Authorization Automatically Grant a DoW ATO?

No. FedRAMP is the base layer for reciprocity, but only IL-2 workloads get automatic coverage through DISA's blanket PA for FedRAMP Moderate offerings. At IL-4 and IL-5, DoW adds FedRAMP+ controls, connectivity requirements, and a DISA review before issuing a PA. IL-6 has no FedRAMP reciprocity path at all because classified systems require dedicated infrastructure and cleared personnel.

‍