The US Department of Defense (now also styled the Department of War) says its Risk Management Framework had become a static, checklist-driven process, and on 24 September 2025 it announced the Cybersecurity Risk Management Construct (CSRMC) as its replacement. The CSRMC reorganises system authorisation around a five-phase lifecycle and ten strategic tenets, with continuous monitoring and a continuous Authorization to Operate (ATO) as the default end state rather than a periodic paper exercise. The public material so far is short: an announcement, a phase diagram and a tenets sheet, with implementation guidance still being finalised. This guide explains what the CSRMC contains, how it maps to the RMF steps practitioners already know, what is still unknown, and how programme offices, system owners, assessors and defence suppliers can prepare. It does not cover contractor systems under CMMC, which is a separate programme.
Source note: the announcement, phases and tenets are from the DoD (Department of War) CIO release and slides of 24 September 2025, which quote Katie Arrington as performing the duties of the CIO; the RMF comparison column is our own summary. Confirm against the official text before relying on it.
Key takeaways
- Five phases. Design, Build (to Initial Operational Capability), Test (to Full Operational Capability), Onboard and Operations, each lining up with familiar RMF steps from Prepare through Monitor.
- Ten tenets. Automation, critical controls, continuous monitoring and ATO, DevSecOps, cyber survivability, training, enterprise services and inheritance, operationalisation, reciprocity, and cybersecurity assessments.
- The CSSP becomes central. In the Onboard phase the Cybersecurity Service Provider decides on full onboarding, partial onboarding or risk review only, and in Operations a CSSP watch officer can decide to disconnect a high-risk system.
- Details are still missing. The published material names no list of critical controls, no metrics and no timeline, and does not mention DoDI 8510.01 or NIST SP 800-37; expect the RMF to keep applying to legacy programmes during transition.
- Evidence becomes live data. Commentators expect future acquisitions to ask suppliers for automated, continuous evidence rather than static documents, so pipeline and monitoring telemetry will matter more than binders.
What the CSRMC is and why it replaces the RMF
The DoD Chief Information Officer's office announced the CSRMC on 24 September 2025, with Katie Arrington, then performing the duties of the CIO, calling it a cultural shift in how the Department approaches cybersecurity. The announcement says the previous framework relied too heavily on static checklists and manual processes that did not account for operational needs or cyber survivability, and that the new construct moves from "snapshot in time" assessments to dynamic, automated, continuous risk management. Its stated purpose is cyber defence at operational speed, with systems hardened, verifiable, continuously monitored and actively defended across air, land, sea, space and cyberspace.
Not everyone sees a clean break. An expert quoted by Breaking Defense described it as largely a rearrangement of current processes under a new name, and criticised the lack of quantified metrics in the Build phase, the weak treatment of supply chain risk, and the operational risk of letting cybersecurity providers disconnect systems in real time. Both views are useful: the phases reuse RMF activities, but the decision rights and evidence model change.
| Aspect | RMF as commonly practised (DoDI 8510.01, NIST SP 800-37) | CSRMC as described |
|---|---|---|
| Authorisation model | Point-in-time ATO, typically renewed every few years, with a package of documents | Continuous monitoring enabling a continuous ATO (cATO) from onboarding |
| Evidence | Manually assembled artefacts in a system of record | Automated data feeds into Information Security Continuous Monitoring (ISCM) and dashboards |
| Key decision maker after deployment | Authorising Official | CSSP onboarding decision and CSSP watch officer disconnect decision, alongside risk owners |
| Testing | Control assessment before authorisation | Threat-informed testing, with penetration testing for high-risk systems before Full Operational Capability |
| Reuse | Reciprocity and inheritance possible but inconsistent | Reciprocity and enterprise inheritance named as core tenets |
The RMF column reflects the established DoD process from DoDI 8510.01 and NIST SP 800-37, written from general knowledge; the CSRMC column is from the DoD CIO material. For background on the RMF itself, see the NIST Risk Management Framework (SP 800-37) Guide.
The five phases
| Phase | Closest RMF step | Activities in the DoD CIO material | Gate or decision |
|---|---|---|---|
| 1. Design | Prepare, Categorize, Select | Identify the capability need; select functional, cybersecurity and cyber survivability requirements; team of Mission Owner, System Owner or Program Manager, engineers and CSSP | Agreed requirements set |
| 2. Build | Implement | Implement requirements; tailor the mission for ISCM; feed data to the ISCM alignment system | Initial Operational Capability (IOC) |
| 3. Test | Assess | Submit for evaluation; assess and remediate findings; penetration test high-risk systems; review automated test report dashboards | Full Operational Capability (FOC) |
| 4. Onboard | Authorize | CSSP chooses full onboarding, partial onboarding (isolation, re-sensoring, extra risk review) or risk review only (validate critical controls and mandatory artefacts); system accepted into ISCM, enabling cATO; data redirected to operational ISCM | CSSP onboarding decision |
| 5. Operations | Monitor | Repeatable playbook for real-time risk monitoring with automated dashboards and alerts; elevate and address high risks | CSSP watch officer may decide to disconnect a high-risk system |
The RMF step alignment is drawn from the layout of the DoD CIO phase diagram and should be treated as an interpretation. Note what is absent: no decommissioning phase is described, and red teaming is not named, only penetration testing.
The ten strategic tenets
| Tenet | What the DoD CIO tenets sheet says (paraphrased) | Practical implication |
|---|---|---|
| Cybersecurity Assessments | Combine threat-informed testing with mission-tied risk management | Test against realistic adversary behaviour, not just control presence |
| Enterprise and Inheritance | Share controls, policies and risks across the enterprise to reduce compliance burden | Build on enterprise services and inherit their controls rather than re-documenting |
| Critical Controls | Adhere to identified critical controls with adaptive recovery strategies | A prioritised subset will matter most at onboarding; the list is not yet public |
| Reciprocity | Accept each other's assessments and reuse system resources | Keep assessment evidence in a form other components can consume |
| Continuous Monitoring, Control and ATO | Real-time visibility of threats, vulnerabilities and compliance gaps | Instrument systems for automated evidence from the Build phase |
| DevSecOps | Integrate security and automation into continuous development, testing and deployment | Pipeline gates and software factory evidence become authorisation inputs |
| Operationalization | Threat detection, incident response, compliance management and proactive monitoring | CSSP integration and playbooks are part of being authorised |
| Cyber Survivability | Protect through encryption, MFA, continuous monitoring and incident response planning | Design for operation in contested environments, not just compliance |
| Training | Role-based training for RMF practitioners | Assessors and system owners need new skills in automation and data |
| Automation | Automate risk management to reduce human error and improve efficiency | Machine-readable control evidence and automated test reports |
Two tenets have an obvious identity angle. Cyber survivability names MFA explicitly, and automation means pipelines, scanners and monitoring agents will hold privileged credentials across many systems. Those service accounts and tokens need ownership, least privilege and rotation; see the DevSecOps Guide and the Continuous Authorisation and Ongoing Authorisation Guide.
Status and what is still unknown (November 2026)
- Policy instruments: the public CSRMC material does not mention DoDI 8510.01, NIST SP 800-37, NIST SP 800-53 or CNSSI 1253. A vendor analysis in February 2026 said implementation guidance was still to be finalised and legacy programmes would transition in the following months. We could not confirm a revised DoDI by November 2026, so assume the RMF instruction still governs until your authorising chain says otherwise.
- Control baselines: nothing published replaces CNSSI 1253 categorisation or the NIST SP 800-53 catalogue. Critical controls are likely to be a prioritised view over existing controls, but that is an inference. See the CNSSI 1253 guide.
- Contractors: the CSRMC applies to DoD systems. It does not change CMMC, which the Department separately paused at Phase 2 in July 2026 (Federal News Network, WilmerHale) while a review took place, with Phase 1 self-assessments remaining. See the NIST SP 800-171 and CMMC 2.0 Guide.
- Leadership: the DoD CIO role has changed hands since the announcement; Kirsten Davies was DoD CIO when the CMMC pause was announced. Watch the CIO's library for CSRMC updates.
Roles and decision rights
| Role | Where it appears in the CSRMC material | What changes in practice |
|---|---|---|
| Mission Owner | Design phase team | Owns cyber survivability requirements and must agree disconnect thresholds that affect the mission |
| System Owner or Program Manager | Design phase team | Accountable for building ISCM data feeds by IOC, not only for producing an authorisation package |
| Engineers | Design phase team | Implement requirements and automation; DevSecOps evidence becomes their output |
| Cybersecurity Service Provider (CSSP) | Design team, Onboard decision, Operations | Chooses full, partial or risk review only onboarding; runs operational monitoring |
| CSSP watch officer | Operations phase | Decides whether to disconnect a system when risk is high |
| Vulnerability remediation and assessment team | Test phase | Assesses, penetration tests high-risk systems and drives remediation before FOC |
The material does not describe how the Authorising Official role changes. Until guidance says otherwise, keep the AO informed of every onboarding decision and every disconnect, and record risk acceptance in the existing system of record.
Decision guidance
| Situation | What to do now |
|---|---|
| New programme in Design | Build to the five phases: involve the CSSP from requirements, define cyber survivability requirements, plan ISCM data feeds before IOC |
| Legacy system with a current ATO | Keep the RMF package current; add automated evidence sources so the system is ready to onboard to ISCM when transition guidance arrives |
| Software factory or DevSecOps platform | Expose pipeline security evidence (scan results, SBOM, signed builds) in machine-readable form; pursue enterprise inheritance for tenant programmes |
| Defence supplier delivering a system to DoD | Expect requests for live monitoring data or automated evidence in future acquisitions; design telemetry export from the start |
| Small programme without its own security team | Lean on enterprise services and inheritance; push for risk review only onboarding with validated critical controls |
How to prepare: a phased approach
- Map current artefacts to phases. For each system, list which RMF artefacts and test results exist and which CSRMC phase they support.
- Engage the CSSP early. Agree sensor coverage, log feeds and incident playbooks before IOC, so onboarding is a full onboarding rather than partial.
- Automate evidence. Generate control evidence from configuration scans (for example STIG compliance), vulnerability scanners and pipeline tools rather than screenshots. See the DISA STIG Guide.
- Pilot one system. Run a single system through the five phases with dashboards, measure effort and gaps, and record what the authorising chain accepted.
- Agree disconnect criteria. With the mission owner and CSSP, define in advance what risk level triggers isolation or disconnection, and the fallback for mission continuity. This is the rollback plan for a construct that can take a system offline.
- Extend and inherit. Move further systems through, inheriting controls from the piloted enterprise services and accepting reciprocal assessments.
Detection and measurement
- Evidence automation rate: share of controls whose evidence is produced automatically rather than manually.
- Monitoring freshness: age of the latest data for each system in ISCM dashboards; stale data undermines a cATO.
- Time to onboard: days from FOC to CSSP onboarding decision.
- High-risk finding dwell time: time from a high-risk alert to remediation or risk acceptance.
- Reciprocity reuse: number of assessments accepted from other components instead of repeated.
- Credential hygiene of automation: share of pipeline and monitoring service accounts with a named owner and rotation in the last policy period.
Framework mapping
| CSRMC element | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Design: requirements and risk strategy | PM-9 Risk Management Strategy; SA-8 Security and Privacy Engineering Principles; RA-3 Risk Assessment | GV.RM-01 |
| Build and DevSecOps | SA-10 Developer Configuration Management; SA-15 Development Process, Standards, and Tools | PR.PS-06 |
| Test and cybersecurity assessments | CA-2 Control Assessments; CA-8 Penetration Testing; SA-11 Developer Testing and Evaluation | ID.RA-01, ID.IM-01 |
| Onboard and ATO | CA-6 Authorization; PM-10 Authorization Process | GV.PO-01 |
| Continuous monitoring and operations | CA-7 Continuous Monitoring; PM-31 Continuous Monitoring Strategy; SI-4 System Monitoring; CA-5 Plan of Action and Milestones | DE.CM-01 |
| Supply chain (named as a gap by critics) | SR-3 Supply Chain Controls and Processes | GV.SC-07 |
The mapping is ours, not DoD's; the CSRMC material does not cite control IDs.
Common failure patterns
- Rebranding without change. Relabelling RMF steps as phases while still producing the same static package gains nothing; the value is in automated evidence.
- Dashboards with stale data. A continuous ATO built on feeds that silently stop is worse than a dated ATO, because it looks current.
- Undefined disconnect authority. Without agreed thresholds, a watch officer's disconnect decision can surprise the mission owner.
- Ignoring the supply chain. The construct says little about supplier risk; compromise through a trusted vendor, as in the SolarWinds supply chain compromise, bypasses well-monitored systems.
- Over-privileged automation. Scanners and pipelines with standing admin rights across the estate become the highest value credentials in the environment.
Practitioner checklist
- Confirm with your authorising chain which instruction governs your system today.
- Map each system's artefacts to the five CSRMC phases.
- Bring the CSSP into Design and agree ISCM data feeds before IOC.
- Automate control evidence from scanners, STIG checks and pipelines.
- Penetration test high-risk systems before FOC and record results in dashboards.
- Agree written disconnect criteria and mission fallback with the CSSP.
- Pursue enterprise inheritance and reciprocity to avoid duplicate assessments.
- Give every automation service account an owner, least privilege and rotation.
- Track DoD CIO releases for critical controls lists and implementation guidance.
Standards and references
- DoD CIO: Department of War announces new Cybersecurity Risk Management Construct
- DoD CIO: Cyber Security Risk Management Construct
- DoD CIO: Cyber Security Risk Management Construct Strategic Tenets
- NIST: SP 800-37 Rev. 2 Risk Management Framework
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Breaking Defense: DoD issues replacement for risk management framework
- Federal News Network: Pentagon suspends CMMC phase two requirements
Related NHI Mgmt Group resources: NIST Risk Management Framework (SP 800-37) Guide · Continuous Authorisation and Ongoing Authorisation Guide · DoD Zero Trust Strategy and Reference Architecture Guide · FedRAMP 20x. This guide summarises the DoD Cybersecurity Risk Management Construct as checked on 11 November 2026 and is not legal advice.