By Who Owns What in Ongoing Authorization: An RMF Roadmap for Program Offices
Ongoing authorization only works when every RMF task has a named owner: the program, the ISSM, the integrator, the independent assessor, or the AO. This roadmap maps each step to its owner, controls and evidence, and shows how to contract for the work without blurring the lines.
Most authorization delays trace back to an ownership gap. The integrator assumes the ISSO will write the implementation statements, the ISSO assumes the assessor will catch the gaps, and the Authorizing Official receives a package nobody fully stands behind. Moving to ongoing authorization makes the gap worse, because evidence now has to stay current every month, not just at signature.
OMB Circular A-130 (opens in a new tab) frames security as a continuous, risk-based program, and NIST SP 800-37 Rev. 2 (opens in a new tab) supports ongoing authorization built on continuous monitoring. This roadmap is for the program manager, ISSM or AO staff who have to decide who does what before the work starts.
The Ownership Map
Rev. 2 has seven steps, not six. The first, Prepare, is where most programs skip the ownership decisions that later stall them.
| RMF step | Owner of the decision | Who does the work | Evidence the AO sees |
|---|---|---|---|
| Prepare | ISSM and system owner | Program staff, with an integrator if engaged | Roles, risk strategy, boundary, common control providers identified |
| Categorize | System owner | ISSO or integrator | FIPS 199 and SP 800-60 worksheets; CNSSI 1253 for national security systems |
| Select | ISSM, with AO representative concurrence | ISSO or integrator | Tailored SP 800-53B baseline with organization-defined parameter values |
| Implement | System owner | Engineers, with integrator support | Implementation statements that match actual configuration |
| Assess | Independent assessor | Security control assessor | Assessment report |
| Authorize | Authorizing Official | AO and AO designated representative | Authorization decision and accepted residual risk |
| Monitor | ISSM | ISSO, operations, monitoring tools | Monitoring strategy results, POA&M currency, reports to the AO |
Two rows cannot be delegated to the integrator. The assessment belongs to an independent assessor, and a firm that prepared the system should not assess it, for organizational conflict of interest reasons. The authorization decision belongs to the AO, always. Any statement of work or status brief that says a contractor "delivers the ATO" misstates the process.
The Controls That Carry the Program
Ongoing authorization rests on a small set of NIST SP 800-53 Rev. 5 controls. A review board should expect each to have an owner and a current artifact.
- CA-2, CA-5, CA-6, CA-7: assessment, POA&M, authorization and continuous monitoring. CA-7 is the control that makes authorization ongoing.
- PL-2: the system security plan, which must describe the system as it runs today.
- PM-9, PM-10, PM-31: the organization's risk management strategy, authorization process and continuous monitoring strategy. These sit above the system and are often missing.
- RA-3, RA-5, RA-7: risk assessment, vulnerability monitoring and risk response.
- CM-2, CM-3, CM-6: baseline, change control and configuration settings, which are the richest source of automated evidence.
The POA&M is where ownership shows first. Every open item needs a named owner, a scheduled completion date and a milestone history. An AO reviewing an ongoing authorization will look at how many items are past due and how long high-severity findings stay open, because those two numbers say more about the monitoring program than any narrative in the security plan.
Organization-defined parameters deserve their own line in the plan. Values such as scan frequency or the timeline for remediating high-severity findings must be set once, approved, and applied everywhere the control appears. Undefined parameters are a common reason an assessor cannot reach a finding.
What Changes Under DoD Rules
DoD programs work under DoDI 8510.01, reissued in July 2024, with eMASS as the record of authorization. Programs seeking continuous authorization face a higher bar. The February 2022 cATO memorandum (opens in a new tab) requires the AO to see three competencies demonstrated: continuous monitoring of RMF controls, active cyber defense, and use of an approved DevSecOps reference design. The same memo states that continuous authorization can be revoked.
The construct is also changing. DoD announced its Cybersecurity Risk Management Construct (opens in a new tab) on September 24, 2025 as the successor to RMF, built on tenets that include automation, continuous monitoring, inheritance and reciprocity. Current DoD issuances and eMASS still reference RMF processes while implementation details are issued. For a program office, the safe course is to tie evidence to controls rather than to document templates, and to write the roadmap so it can absorb new guidance at a phase gate.
Architecture choices decide how much of this is achievable. A program building on a landing zone built as code with mapped guardrails (opens in a new tab) can generate much of its CA-7 evidence from the pipeline; a legacy system cannot, and the roadmap should say so.
Inheritance and Adjacent Programs
Inherited controls need their own owner. For systems on a FedRAMP-certified cloud service, the customer responsibility matrix records which controls the provider covers, which are shared, and which the system owns. The provider side is being reorganized: the FedRAMP Consolidated Rules (opens in a new tab) become mandatory January 1, 2027, and Rev5 authorizations end December 31, 2028. A program should plan to refresh its inheritance mapping as its providers transition.
Enterprise common control providers need the same treatment as cloud providers. When a system inherits identity, logging or incident response from an agency-level service, the program should hold a written record of which controls that provider covers, who its point of contact is, and how the provider reports changes. Without it, the AO is asked to accept controls nobody in the program can evidence.
Keep one adjacent program out of the plan. NIST SP 800-171 and CMMC govern contractor systems handling CUI, not agency system authorization, and DoD suspended the Phase 2 requirement for C3PAO-certified Level 2 status on July 13, 2026 (opens in a new tab). Stakeholders conflate the two often enough that the distinction belongs in the kickoff briefing.
Contracting for the Work Without Blurring Ownership
A statement of work for RMF integration should make the ownership map enforceable. Five clauses do most of the work:
- Named scope. List systems by name and governance record ID, and cap the number of records and controls in scope.
- Access as a condition. Governance platform accounts, including eMASS sponsorship, requested at kickoff, with the schedule running from access grant.
- Capped remediation. Define implementation as engineering specification and integration, cap hands-on remediation hours, and route overflow by change order.
- Separation from assessment. State that the integrator will not perform the independent assessment.
- Approved language. The integrator "positions the system for independent assessment and the authorization decision." It does not promise an outcome or a date the AO controls.
A single Moderate system typically takes four to eight months and prices between $75K and $250K firm fixed price. The entry step, a readiness assessment at $15K to $35K, falls under the $350,000 simplified acquisition threshold (opens in a new tab).
Taking It to the Review Board
A review board will ask what the program is buying and what could go wrong. The answer should be a risk register with owners, not a promise:
| Risk | Owner | Containment |
|---|---|---|
| Access provisioning delays the start | Program office | Requests at kickoff; schedule from access grant |
| Scope grows from one system to the enclave | Contracting officer | Named systems; change-control trigger |
| Integration becomes indefinite ISSO staffing | ISSM | Time-boxed transition; support scoped separately |
| New DoD guidance mid-engagement | ISSM | Evidence tied to controls; roadmap updated at phase gates |
The board should also see what the program pays for delay, since the cost of authorization delays for a program (opens in a new tab) is usually larger than the integration itself.
Avalon's RMF Integration service is the execution layer for this roadmap. It produces the posture assessment and costed roadmap, the tailored baseline with parameter workbook, the inheritance matrix, implementation statements in your governance record, and the continuous monitoring strategy, then hands the process to your staff. The independent assessment and the authorization decision stay where they belong.
