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 does not. 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 Plan and Requirements
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 cannot select controls without knowing what you are protecting or who owns the risk.
Output: System boundary and stakeholder documentationCategorize Requirements
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 are either over-controlling or under-controlling for the rest of the project.
Output: System Categorization documentSelect Design
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, and what MFA mechanism applies. Controls are not selected after the architecture is finalized. They inform the architecture while it is being built.
Output: Tailored control baselineImplement Develop
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 Test
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 are documented before deployment.
Output: Security Assessment Report (SAR) and POA&MAuthorize Deploy
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 does not happen until the package improves.
Output: Authorization to Operate (ATO)Monitor Maintain and Operations
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 is the system boundary? What is 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 is 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 is 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 do not 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 is not a compliance process that follows development. It is a risk management process that runs through it. The earlier a security requirement enters the process, the cheaper and cleaner it is to satisfy and the less likely it is to become a POA&M item after the fact.
The Point
The RMF and the SDLC are not 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 is made, and the RMF is structured so the most consequential decisions happen at the beginning, not the end.
