The RMF and the SDLC are designed to run together. NIST SP 800-37 Rev 2 maps each RMF step directly onto SDLC phases — not as a parallel process, but as the structure that determines what security decisions get made, when, and in what form. The artifacts the RMF produces at each step are inputs to the next phase of development. The sequencing is intentional.
The SDLC, for Reference
The standard SDLC runs through seven phases: Plan, Requirements, Design, Develop, Test, Deploy, and Maintain/Monitor. The naming varies by organization but the sequence doesn’t. What matters for RMF integration is which security decisions belong in which phase, and why placing them earlier rather than later changes the outcome.
Where Each RMF Step Lands
Prepare
Before any design work starts, establish the system boundary, identify the data types the system will handle, document stakeholders, and confirm risk tolerance from the authorizing official. This context drives every downstream decision — you can’t select controls without knowing what you’re protecting or who owns the risk.
Output: System boundary & stakeholder documentationCategorize
Apply FIPS 199 to determine the system’s overall impact level. Rate Confidentiality, Integrity, and Availability independently for each data type, apply the high water mark rule, and document the result. The impact level determines which SP 800-53B baseline applies — getting this wrong at Requirements means you’re either over-controlling or under-controlling for the rest of the project.
Output: System Categorization documentSelect
The categorization from step two drives control baseline selection. During Design, the security and GRC functions work the tailored control set into the system architecture — determining how encryption is implemented, where logging sits, what access model the system uses, what MFA mechanism applies. Controls aren’t selected after the architecture is finalized; they inform the architecture while it’s being built.
Output: Tailored control baselineImplement
Engineers build the controls. The GRC function’s primary output here is the System Security Plan — capturing how each control is actually implemented, not how it was planned to be implemented. The SSP is largely a GRC-authored document maintained in parallel with development, not written after the fact once the system is complete.
Output: System Security Plan (SSP)Assess
An independent assessor tests whether the controls described in the SSP work as described — not whether they exist on paper. This aligns with the test phase, where QA runs functional tests at the same time security testing runs control effectiveness tests. Gaps become POA&M entries rather than blockers, but they’re documented before deployment.
Output: Security Assessment Report (SAR) + POA&MAuthorize
The Authorizing Official reviews the full package — SSP, SAR, and POA&M — and makes a risk-based decision before the system goes into production. An ATO is the authorization to deploy. An IATO authorizes deployment with a documented timeline to close residual findings. A denial means deployment doesn’t happen until the package improves.
Output: Authorization to Operate (ATO)Monitor
Continuous monitoring runs for the life of the system — tracking control effectiveness, configuration drift, incidents, and periodic reassessment. A material change to the system can trigger a return to Categorize or Select. It rarely means restarting from Prepare.
Output: Continuous monitoring programWhy Prepare Changed Everything in Rev 2
The original RMF had six steps and started at Categorize. The problem was that organizations were beginning categorization without the organizational context to do it correctly. Who owns the risk? What’s the system boundary? What’s the mission dependency? Those questions were being answered inconsistently, or not at all, and the downstream artifacts reflected it.
Adding Prepare as an explicit first step — and anchoring it to the earliest SDLC phases — created a forcing function. You establish organizational and system context before any categorization or control work begins. It’s the step that makes everything else tractable.
The Shift Left Argument
A control requirement identified during Design is an architecture decision. The same requirement identified after deployment is a remediation project — often involving re-architecture, additional infrastructure, and a POA&M that creates ongoing risk visibility until it’s closed.
The categorization that drives control selection needs to happen while the system is still malleable. Under-categorizing at that stage means under-controlling a system that actually needs more protection. Over-categorizing means burning engineering effort on controls that don’t match real risk. Either way, the error compounds through every downstream step.
RMF integration with the SDLC is the formal expression of shift-left security for federal systems and systems following NIST guidance. It’s not a compliance process that follows development. It’s a risk management process that runs through it.
The Point
The RMF and the SDLC aren’t separate workflows that converge at the end. Each RMF step produces an artifact that feeds the next SDLC phase. The sequencing exists because the cost of a security decision goes up the later it’s made — and the RMF is structured so the most consequential decisions happen at the beginning, not the end.
Last edited:
