Who Owns RMF, ATO and STIG Work on a Custom DoD Application?

Quick answer. As of October 2026, a custom application built for a DoD program goes through the Risk Management Framework, which according to NIST is a preparatory step and six main steps, and in the split this guide recommends, the build implements and describes the controls the application does not inherit, hardens it and produces the evidence, while the government side categorizes the system, its authorizing official chooses the impact level, and the program has the controls assessed and the authorizing official decides whether the system may operate. The authorization to operate is the authorizing official’s decision to explicitly accept the risk, it carries an authorization termination date that official sets, and no contractor can grant it, so scope the evidence into the statement of work before the build starts and name who monitors the system and its controls on an ongoing basis after go-live.

When the evidence for an ATO was never scoped into the build, the go-live date waits on work no one priced. When a statement of work says the contractor will support the ATO and comply with the applicable STIGs, and says nothing more, the work that decides the go-live date has no owner and no line in the budget. This guide sets out what NIST SP 800-37 Revision 2 and Microsoft’s pages on Microsoft Learn, read in October 2026, say about that work, where the i3solutions recommendation sits beside them, and which calls belong to your program.

The ATO Is a Decision, Not a Deliverable

If a statement of work makes the contractor responsible for obtaining the ATO, it has assigned a decision the contractor cannot make. NIST’s Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy (NIST SP 800-37 Revision 2, published December 2018) quotes the OMB Circular A-130 definition in its glossary: an authorization to operate is “The 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, agency assets, individuals, other organizations and the Nation. The same publication says “An authorization termination date is established by the authorizing official as a condition of the authorization.”

The impact level is the government’s call too. Microsoft’s Department of Defense (DoD) Impact Level 5 (IL5) page says: “The determination of whether CUI and/or mission data fits the IL5 category is up to the authorizing official responsible for categorizing the information and choosing the cloud impact level.”

Never accept a statement of work, from either side, that makes the contractor responsible for obtaining the ATO. Make it responsible for the evidence the assessment report draws on, the hardening and the fixes, and leave the decision where NIST puts it.

What You Inherit from Microsoft, and What Stays with Your Application

When the team hears that the cloud is already authorized, the next assumption is that the application is too. Microsoft’s Department of Defense (DoD) Impact Level 4 (IL4) page describes the DoD Cloud Computing Security Requirements Guide (SRG) as the baseline DoD uses to assess a cloud service offering for a DoD provisional authorization, and says the SRG “maps to the DoD Risk Management Framework (RMF)”. That authorization is the cloud service’s. Your application still goes through its own.

Inheritance is checked per service, not per cloud. Microsoft’s Azure, Dynamics 365, Microsoft 365, and Power Platform services compliance scope page says: “This article provides a detailed list of Azure, Dynamics 365, Microsoft 365, and Power Platform cloud services in scope for FedRAMP High, DoD IL2, DoD IL4, DoD IL5, and DoD IL6 authorizations across Azure, Azure Government, and Azure Government Secret cloud environments.” Its tables carry “Last updated: February 2026”.

Even the controls Microsoft maps are split. The same Department of Defense (DoD) Impact Level 4 (IL4) page says Azure Policy’s regulatory compliance initiative lists controls by responsibility, “customer, Microsoft, or shared”, and warns that “compliance in Azure Policy is only a partial view of your overall compliance status.” NIST makes the general point about inherited controls in Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy: “Authorizing officials also consider the risk of inheriting common controls as part of their system authorizations.” Whether FedRAMP applies to the application at all, and where Microsoft draws the inheritance line, is covered in FedRAMP High for government contractor applications.

Build a control responsibility list for every service the application uses before the design is final: what Microsoft carries, what is shared, and what your code and configuration carry.

The RMF Steps, Read as Build Work

If the security plan is written after the code is finished, the evidence is reconstructed from memory and the assessment finds the gaps. NIST’s Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy says “There are seven steps in the RMF”, a preparatory step and six main steps. It names them Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor, and says “The RMF is applied iteratively, as applicable, during the system development life cycle for any type of system development approach (including Agile and DevOps approaches).”

The build’s core step, in NIST’s words, is to “Implement the controls and describe how the controls are employed within the system and its environment of operation.” The assessment that follows is to “Assess the controls to determine if the controls are implemented correctly, operating as intended, and producing the desired outcomes with respect to satisfying the security and privacy requirements.” And NIST says “the expected outputs required by the RMF (e.g., security and privacy plans, assessment reports, plans of action and milestones), can be routinely obtained from the SDLC processes in place within organizations and may not need to be developed solely for RMF implementation.”

For the statement of work, the i3solutions recommendation is the split in the RMF step table. NIST names the steps, not the contract lines, and your program decides the final split.

RMF step (NIST)	Government side	What the build produces
Prepare	Sets the program’s context and priorities	Its questions about boundary, hosting and data, asked before the build is scoped
Categorize	Categorizes the system and its information; the authorizing official chooses the impact level	Nothing to decide; the build records the result
Select	Selects and tailors the controls	The control responsibility list per service
Implement	Reviews	The controls in code, configuration and hosting, and the description of how each is employed
Assess	Has the controls assessed	The evidence, test results and fixes the assessment asks for
Authorize	The authorizing official decides and sets the termination date	Nothing to decide; the build supplies the package inputs it was scoped for
Monitor	Monitors on an ongoing basis, or names who does	Change records and updated evidence for the application it built

The pipeline can already hold that evidence. i3solutions delivery includes ALM practices with Power Platform pipelines or Azure DevOps integration, environment separation strategies, and change control processes. Treat the pipeline’s change history, test run logs and environment records as evidence from the first sprint, not as something exported at the end. The contract language for secure development practices is a separate decision and is not covered in this guide.

STIG Hardening Belongs in the Build, Not After It

When hardening starts after functional testing, every finding on the application or its hosts lands in the schedule at the worst moment. DoD programs harden systems to DISA Security Technical Implementation Guides, and the program names which guides apply to your application and its hosts. Scope that hardening, test it and keep its evidence during the build, the same way as any other requirement.

Configuration-as-code tooling is a design choice to confirm against Microsoft’s current guidance. Microsoft’s Configure data based on Security Technical Information Guide (STIG) page carries this note: “Azure Automation State Configuration will be retired on September 30, 2027, please transition to Azure Machine Configuration by that date.”

The assessment itself sits with the government side in the recommended contractor-versus-government split. Whether to add independent verification of the build on top of it is a separate buyer decision, covered in IV&V versus traditional testing.

Ask the program to name the applicable STIGs and the assessment tooling in the statement of work, before the build is priced.

The Contractor-Versus-Government Split, in One Table

If the split lives in email threads, the first assessment finding starts an argument about who owns it. This contractor-versus-government table is the i3solutions recommendation, built on the NIST and Microsoft statements quoted in this guide; your program’s authorizing official and contracting officer decide the final version.

Work	Government side	The build (your team or contractor)
Categorize the system and its information	Yes	Supplies what the system holds and how data flows
Choose the impact level	Yes, the authorizing official	Designs to the level chosen
Select and tailor controls	Yes	Proposes the control responsibility list per service
Implement controls in code, configuration and hosting	Reviews	Yes
STIG hardening and the findings	Names the applicable guides	Hardens, tests and fixes
Security and privacy plan inputs	Owns the plans	Writes the system-specific descriptions
The assessment	Yes	Supplies evidence and fixes findings
Plans of action and milestones	Owns and tracks	Supplies the fix plan for application findings
The authorization decision	Yes, the authorizing official	No
Continuous monitoring	Yes, or names who does	Supplies change records for what it built

Put this table, filled in, into the statement of work. A row with no name on it is a row that will slip.

After Go-Live: The Authorization Ends, and Monitoring Does Not

When the application goes live, the RMF work does not stop; it changes owner. NIST’s Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy describes the last step as “Monitor the system and the associated controls on an ongoing basis”, which it goes on to spell out as assessing control effectiveness, documenting changes, conducting risk assessments and impact analyses, and reporting the system’s security and privacy posture. The authorization itself carries the termination date the authorizing official set, unless the system runs under what NIST calls ongoing authorization: “For ongoing authorization, the authorization frequency is specified in lieu of an authorization termination date.”

Who performs that monitoring is a decision for the program and the system owner: the program’s own security staff, the system owner’s team, or an outside provider. Name it before go-live.

The application’s own operation, support and enhancement is a separate line. For applications i3solutions built or modernized, that work can be scoped as application managed services. i3solutions does not sell ongoing managed IT operations, such as a managed security operations service. Warranty and transition terms at handoff are a separate decision and are not covered in this guide.

When This Guide Is the Wrong Frame

If your situation matches one of these cases, a different first move applies:

• If the application will run inside an environment the government already operates and authorizes, the program’s authorizing official decides how the application enters that boundary. Ask before scoping a separate package; NIST’s point that authorizing officials weigh inherited controls in their decisions applies to this case.
• If the system is your own company’s information system handling CUI, rather than a system operated for the DoD program, the obligations are the contractor-side ones. Which CMMC level applies, and when, is covered in CMMC levels and timeline.
• If the program has not categorized the system or named the impact level, stop and get that first. Microsoft’s IL5 page puts the choice of impact level with the authorizing official.
• If the application is a prototype that will not connect to a DoD network or hold DoD data, the full package may not be the first gate. The program decides.

What to Require from Whoever Builds It

If a proposal promises an ATO, it is promising a decision the firm cannot make. Require these from any team, internal or contracted:

• A written split of the RMF work, like the contractor-versus-government table, with a name on every row.
• The control implementations, their descriptions and the STIG hardening evidence as named deliverables, not as effort.
• People who have delivered inside government-hosted environments.
• US-based delivery.
• A plain statement of what the firm will not do, starting with granting an ATO.

How to vet a firm for FedRAMP High and IL4 work is covered in hiring a firm for FedRAMP High and DoD IL4 work.

How i3solutions Answers

When the build carries the RMF work, it is scoped, staffed and priced as part of the project. As a Microsoft-focused application development and integration firm, i3solutions builds the custom application with the control implementation, STIG hardening, evidence from the lifecycle and remediation of findings scoped into it, and can embed specialists fluent in NIST, DoD RMF, and IL4 and IL5 requirements inside the build team where the program needs them. i3solutions installs and helps configure applications inside IL4 and IL6 government cloud environments and other government networks. i3solutions does not hold a FedRAMP or DoD authorization of its own and does not authorize, accredit or issue an ATO for any system. i3solutions advises clients on federal compliance posture as its own assessment rather than as a restatement of Microsoft’s documentation, including whether SharePoint Online meets NIST 800-53, whether Azure Government is required under the DoD Cloud Computing SRG, and whether a CMMC gap assessment is needed to bid. i3solutions provides dedicated US-based Microsoft teams for aerospace and defense programs. i3solutions is an SBA certified small business providing technical and professional services to US Federal Agencies, the DoD and the private sector. Delivery is senior and US-based. The wider practice is custom application development services.

Key Takeaways

• According to NIST SP 800-37 Revision 2, the RMF has a preparatory step and six main steps, applied iteratively during the system development life cycle, including Agile and DevOps approaches.
• The authorization to operate is the authorizing official’s decision to explicitly accept the risk, with an authorization termination date that official sets; no contractor can grant it.
• According to Microsoft, the authorizing official chooses the cloud impact level, and compliance in Azure Policy is only a partial view; inheritance is checked per service.
• In the split this guide recommends, the build owns implementing and describing the controls it does not inherit, the STIG hardening the program names, and the evidence, which NIST says can come out of the development lifecycle.
• Monitoring continues after go-live on an ongoing basis; name who does it before the application goes live.

Frequently Asked Questions

Who issues the ATO for a custom application built for a DoD program?

The authorizing official issues it. According to the glossary of NIST SP 800-37 Revision 2, which quotes OMB Circular A-130, an authorization to operate is “The official management decision given by a senior Federal official or officials to authorize operation of an information system and to explicitly accept the risk”, and Microsoft’s IL5 page says the determination of the IL5 category “is up to the authorizing official responsible for categorizing the information and choosing the cloud impact level.” No contractor issues it.

Does building on Azure Government mean our application inherits an ATO?

No. The application inherits controls, per service, and still goes through its own authorization. Microsoft’s IL4 page says Azure Policy lists controls by responsibility, “customer, Microsoft, or shared”, and that “compliance in Azure Policy is only a partial view of your overall compliance status.” NIST says “Authorizing officials also consider the risk of inheriting common controls as part of their system authorizations.”

Does an ATO expire?

Yes, unless the system is under ongoing authorization. NIST says “An authorization termination date is established by the authorizing official as a condition of the authorization.” and, for a system under ongoing authorization, “the authorization frequency is specified in lieu of an authorization termination date.”

When should RMF work start on a custom application?

It should start when the build starts. NIST says “The RMF is applied iteratively, as applicable, during the system development life cycle for any type of system development approach (including Agile and DevOps approaches)”, and that its expected outputs “can be routinely obtained from the SDLC processes in place within organizations”.

Who performs continuous monitoring after go-live?

Whoever the program and the system owner name before go-live performs it. NIST describes the step as “Monitor the system and the associated controls on an ongoing basis”, so it has to be assigned, not assumed.