DoD’s Cybersecurity Risk Management Construct: Keeping Authorization Connected to Operations

Continuous monitoring has a history

The department described CSRMC as a response to checklist-heavy, manual implementations that did not adequately serve operational needs. That criticism should not be confused with a claim that the earlier Risk Management Framework lacked continuous monitoring: NIST's 2018 RMF explicitly includes it and supports ongoing authorization and near-real-time risk management. CSRMC announcement and NIST SP 800-37 Rev. 2

The execution gap is familiar. Documentation can describe the approved baseline while the fielded system changes through patches, dependencies, new connections, or altered missions. Monitoring can also become a collection of alerts without a clear decision owner. Neither problem is solved by renaming a framework.

The practical objective is to keep the authorization basis connected to current conditions. A program should be able to explain what is running, what has changed, which controls remain effective, and what action follows when the accepted risk assumptions no longer hold.

Five phases, with evidence carried forward

The announcement defines Design, Build, Test, Onboard, and Operations. Its ten tenets cover automation; critical controls; continuous monitoring and ATO; DevSecOps; cyber survivability; training; enterprise services and inheritance; operationalization; reciprocity; and cybersecurity assessments. The test phase emphasizes validation before full operating capability, while onboarding and operations emphasize monitoring and visibility. Official phases and tenets

For an implementation team, a useful way to translate those phases is to ask what evidence passes from one to the next:

• Design to build: a threat model, trust boundaries, critical functions, and an agreed set of security requirements.
• Build to test: a traceable configuration, known dependencies, control implementations, and documented limitations.
• Test to onboarding: results against the intended configuration, unresolved findings, and explicit conditions for deployment.
• Onboarding to operations: working telemetry, identified responders, escalation routes, and an approved process for changes.
• Operations back to engineering: observed weaknesses, incidents, drift, and mission changes that require another technical decision.

These are practical recommendations for connecting the lifecycle. The announcement is not, by itself, an instruction to discard existing authorization conditions or assume that a dashboard confers approval.

A constant posture still needs accountable decisions

Automation can collect evidence and identify changes faster than a periodic manual review. It cannot decide every mission tradeoff. A high-severity finding on one system may have a very different consequence on another, depending on exposure, compensating controls, and the effect of interrupting the mission.

Program leadership and the authorizing official need an agreed response model. It should state who can accept a temporary condition, who can require mitigation, and who can limit or stop operation. The evidence supporting those decisions should remain available after the immediate incident has passed.

Inherited services and reused assessments can reduce duplication, but the receiving program still needs to understand scope. A platform's assessment may cover hosting controls while leaving application behavior, identities, mission data, and local configuration to the application owner. Reciprocity is most useful when the boundaries and assumptions are explicit.

Design monitoring for disconnected operation

A system operating in a denied, degraded, intermittent, or limited-bandwidth environment may be unable to send continuous telemetry to an enterprise service. Its design should account for that condition rather than silently presenting stale central data as a current picture.

The local operating concept should specify:

• Which security events and configuration changes are recorded on the platform.
• How records are protected and retained when storage or power is constrained.
• Which local actions are permitted when a suspected compromise occurs.
• How the operator distinguishes lost connectivity from a security failure.
• How records and configuration state are reconciled when connectivity returns.

The acceptable behavior depends on mission and system design. Some functions may continue under approved conditions; others may require restriction. Those choices need to be made with the mission owner before deployment, then exercised with the personnel expected to carry them out.

Threat-informed testing must resemble the intended system

CSRMC's assessment emphasis supports testing against relevant threats. It does not establish that every program must use one particular live red-team event or that a cyber range alone satisfies every requirement. The test plan should select methods and environments appropriate to the risk and produce evidence the responsible authority can use.

A representative test campaign can combine code and configuration review, automated checks, penetration testing, operational exercises, and recovery demonstrations. Where a range is used, document what it reproduces and what it omits. Network topology, identity relationships, interfaces, third-party dependencies, and disconnected conditions can materially affect the result.

Security testing should also ask whether the mission recovers. Detecting an intrusion is useful; restoring a trustworthy configuration, preserving essential records, and resuming an authorized function demonstrate a different part of resilience.

Questions for the next program review

1. Can the team identify the current deployed configuration and the evidence supporting its authorization?
2. Which changes invalidate prior test assumptions, and who determines the necessary reassessment?
3. Are monitoring findings routed to someone with the authority and resources to act?
4. Have response and recovery procedures been exercised on representative equipment, including disconnected conditions?
5. Does the program baseline fund ongoing assessment, telemetry, remediation, and staff training?

Resolving weaknesses earlier can avoid disruptive changes after fielding, but the savings depend on the system and defect; a universal cost multiplier is not a sound planning basis. Build the actual test and sustainment effort into the schedule and budget.

The strongest result of this shift would be an authorization process that remains useful after deployment: current evidence, timely decisions, and a system that can continue its mission within understood risk limits.

Sources and further reading

• DoD CIO: CSRMC announcement, phases, and tenets
• NIST SP 800-37 Rev. 2: lifecycle risk management, authorization, and monitoring

Spartan X's cybersecurity, engineering, and program-execution practices connect authorization evidence with the fielded system and its mission. That work brings monitoring, representative testing, and clear response ownership into the same operational plan.