RMFInsider

The Cybersecurity Risk Management Construct carries ten foundational tenets as published by the DoD CIO, and the honest translation for an ISSO is that nine of them describe evidence you should already be able to produce on demand. The published list, from the September 24, 2025 announcement titled “Department of War Announces New Cybersecurity Risk Management Construct,” is Automation, Critical Controls, Continuous Monitoring and ATO, DevSecOps, Cyber Survivability, Training, Enterprise Services & Inheritance, Operationalization, Reciprocity, and Cybersecurity Assessments. Nothing in that announcement changes an eMASS field today. What it does is tell you which parts of your package are about to be read as live data rather than as a document. Here is each tenet mapped to work you can actually do this month.

I am not going to redefine CSRMC here

That ground is already covered. If you need the definition, the scope and the organizational background, read the CSRMC explainer first, and if the question in your head is whether this replaces RMF outright, the post on what CSRMC actually replaces answers it better than a paragraph here would. This post assumes you know what the construct is and want to know what to do on Monday.

One framing point before the mapping. CSRMC is a construct, not an instruction. DoDI 8510.01, Risk Management Framework for DoD Systems, effective July 19, 2022, remains the governing issuance for the process you are executing, and its Monitor step task M-6 already reads that AOs conduct ongoing authorizations using the results of continuous monitoring activities. The construct sharpens an expectation that was already written down.

The ten tenets, as published

Quoting the published names rather than paraphrasing them, because the wording matters when you cite this in a brief. The published list is the authority; if the DoD CIO revises it, the revision wins over anything here.

• Automation. Evidence collected by machines rather than assembled by people.
• Critical Controls. Prioritizing the controls that carry real risk rather than treating a baseline as a flat list.
• Continuous Monitoring and ATO. Authorization fed by live control status.
• DevSecOps. Security built into the pipeline that delivers the capability.
• Cyber Survivability. The system keeps performing its mission while under attack.
• Training. The workforce can operate the construct, not just describe it.
• Enterprise Services & Inheritance. Use the common service and inherit its controls instead of rebuilding them.
• Operationalization. Cybersecurity treated as an operational function rather than a compliance deliverable.
• Reciprocity. Accept another authorization’s work instead of reassessing it from scratch.
• Cybersecurity Assessments. Assessment as a recurring activity rather than an event before a signature.

Tenet to task, one at a time

Automation and Critical Controls

These two travel together, because automation without prioritization produces a dashboard nobody reads. The ISSO task is to go through your control set and sort it into three buckets: controls where status already arrives from a tool, controls where status could arrive from a tool if somebody wired it up, and controls that will stay manual because they are policy or procedure. Write the list. It takes an afternoon, and it is the one artifact an ISSM told to prepare for CSRMC can use immediately. Then rank the automatable ones by how badly a failure would hurt, which is your working version of critical controls, and start with the top five rather than the alphabetical first five.

Continuous Monitoring and ATO

This is the tenet that changes your calendar. Today an annual security review and a quarterly scan cadence satisfies an assessment schedule. Under a construct that feeds authorization from live status, the frequency has to be justified by how fast each control can break, not by the rotation on a spreadsheet. The task is to rewrite your continuous monitoring frequencies control by control and get them signed, which is the same work described in RMF Step 6, done with intent instead of inherited from whoever wrote the plan before you.

DevSecOps

If your system is a vendor appliance and a Windows domain, this tenet largely passes you by, and saying so plainly is better than pretending. If there is a pipeline anywhere near your boundary, the ISSO task is to find out which security gates it runs, whether a failed gate stops a deployment or files a note, and who gets the output. The answer to the second question is the one assessors will care about, and in my experience the honest answer is frequently that the gate reports and the deployment proceeds.

Cyber Survivability and Operationalization

These two ask a question your System Security Plan probably does not answer: what does the mission do when a control fails? The task is to write down the degraded mode for your top three mission functions. If the identity provider is unavailable, what still works and who decides to fail over. If the SIEM stops ingesting, how long before anyone notices. If the primary circuit drops, which capability survives. This is contingency planning language applied to cyber events, and it is the part of a package that reads as operational rather than clerical.

Enterprise Services and Inheritance, plus Reciprocity

Both tenets reward you for not rebuilding what exists. The task is a current inheritance map: every control you claim from a hosting provider, an enterprise service or a common control provider, with the provider named, the scope stated, and the date of the assessment you are relying on. Stale inheritance is the first thing I find when I open an unfamiliar package, usually a provider that got reorganized two years ago. For reciprocity, keep a short list of the artifacts another authorizing official would need from you to accept your work, and keep them exportable. That is the whole mechanic.

Training and Cybersecurity Assessments

Training here means role-based competence, not the annual awareness click-through. The task is to name, in writing, who on your team can do each thing the construct assumes: pull control status from the tool, interpret a STIG finding against a control, write a security impact analysis, run a tabletop. Gaps on that list become your training request. For assessments, shift from preparing for one event to keeping a rolling record: what was assessed, when, by whom, with what result. For the relationship between all of this and the instruction you still execute against, the DoDI 8510.01 walkthrough is the reference I keep open.

The five phases, and why I am not giving you a fiscal-year date

The published announcement describes five phases: Design, Build, Test, Onboard and Operations. As published, those phases are tied to system lifecycle milestones rather than to calendar dates. Build covers secure designs implemented as systems reach Initial Operating Capability. Test covers validation and stress testing before Full Operating Capability. Onboard activates continuous monitoring at deployment. Operations covers real-time dashboards and alerting.

What I did not find in the primary announcement is a fiscal-year schedule, a named pilot list, or a transition deadline for legacy programs. Published commentary through early 2026 said implementation guidance was still being finalized. So I am not going to hand you a fiscal-year date to put in a brief, because I would be making it up, and you would be the one standing there when somebody asked for the source. Treat the published phase list as the authority, ask your Component ISSM or AO office what their transition plan says, and write down the date they give you along with who gave it to you.

I have sat through a briefing where CSRMC was presented as the end of cybersecurity paperwork, delivered as a forty-slide deck, which is at least a genre-aware choice.

What changes in your eMASS workflow, and what does not

Nothing in the published announcement rewrites eMASS. The realistic near-term changes are in what you are asked to show, not in where you click:

• Test results get asked about by freshness. The question moves from whether a control was assessed to when, and by what.
• Control status starts to be read alongside a dashboard rather than on its own, so a status of compliant that no tool corroborates draws a follow-up.
• Inheritance gets inspected rather than accepted, because the construct explicitly rewards enterprise services.
• POA&M volume rises before it falls, since faster detection surfaces findings that an annual cycle would have missed.

What stays exactly the same, and this is the part worth telling an anxious team:

• Control implementation statements, test results and the POA&M remain the structure of the package.
• The authorization boundary still has to be defined and defended, and a vague one still sinks everything downstream.
• The AO still owns the risk decision and, under DoDI 8510.01 section 4.4, can downgrade or revoke an authorization at any time if risk conditions warrant.
• Your artifacts, your signatures, your workflow roles. None of that is replaced by a construct.

If you want the side-by-side version of that comparison rather than a list, I worked it through in CSRMC against RMF.

Five things to start now that cost nothing

1. Build the automation triage list: controls already fed by a tool, controls that could be, controls that stay manual.
2. Date-stamp your inheritance. Provider, scope, assessment date, for every inherited control.
3. Write a one-page degraded mode note for your top three mission functions.
4. Rewrite three continuous monitoring frequencies based on failure speed and take them to your ISSM as a proposal.
5. Ask your AO office one question in writing: what is our Component’s CSRMC transition plan, and who owns it? Keep the answer.

Every one of those is defensible under the current instruction, so none of it is wasted effort if the construct’s timeline slips. That is the test I apply to any guidance that arrives before its implementation detail does.

The common thread across all ten tenets is evidence that exists before somebody asks for it. If you want the artifact-by-artifact version of that, with owners and the order to build them in, work through the RMF Checklist and start with the inheritance and monitoring sections, because those are the two the construct reads first.