How should organisations implement the NIST Risk Management Framework across a system development lifecycle?

Why This Matters for Security Teams

NIST RMF is often treated as paperwork that happens after architecture is “done,” but that pattern creates avoidable gaps across the system development lifecycle. Control selection, tailoring, assessment, and authorization only work when they are tied to design decisions, acquisition, development, deployment, and change management. NIST’s own guidance in the NIST Cybersecurity Framework 2.0 reinforces the need to integrate governance, identification, protection, detection, response, and recovery as continuous activities rather than isolated checkpoints.

For organisations managing non-human identities and secrets, the lifecycle problem is especially sharp. NHIs are created quickly, reused widely, and left behind when projects change, which makes late-stage control mapping ineffective. NHIMG research shows the scale of that exposure: in the 2024 ESG Report: Managing Non-Human Identities, 72% of organisations said they have experienced or suspect a breach of non-human identities. That is a lifecycle failure, not just a tooling problem. In practice, many security teams encounter weak RMF outcomes only after systems are already in production and exceptions have become permanent.

How It Works in Practice

Implementing RMF across the SDLC means translating each RMF step into a lifecycle gate with accountable owners. Early in design, teams should define risk tolerance, identify system boundaries, and categorize the system so security requirements are not guessed later. During architecture and build, control selection should be tailored to the actual data, trust relationships, suppliers, and identity model in use. The NIST SP 800-53 Rev. 5 Security and Privacy Controls is the practical control catalogue most teams use to map requirements into implementation details.

As development proceeds, each control should be traced to evidence that can be assessed, not just documented. That includes configuration baselines, test results, logging, access reviews, and exception handling. For NHI-heavy systems, this also means tracking secrets issuance, rotation, service account ownership, and revocation paths. NHIMG’s NHI Lifecycle Management Guide and Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs are useful references because they show how identity governance and system governance need to move together.

• Map RMF steps to stage gates: plan, design, build, test, authorize, operate, and retire.
• Assign a control owner and an evidence owner for every significant requirement.
• Use continuous monitoring to detect drift in config, access, vulnerabilities, and identity state.
• Revisit residual risk whenever code, dependencies, permissions, or suppliers change.

The authorizing official should base the decision on current evidence and mission impact, not on a one-time checklist. These controls tend to break down when DevOps teams ship continuously but the RMF process still depends on quarterly reviews and static system descriptions.

Common Variations and Edge Cases

Tighter control mapping often increases delivery overhead, requiring organisations to balance speed against evidence quality. That tradeoff becomes visible in cloud-native, SaaS, and multi-team environments where system boundaries shift faster than governance documents can be updated. Current guidance suggests that the RMF should adapt to iterative delivery, but there is no universal standard for exactly how much automation is enough.

In practice, the hardest edge cases are shared services, inherited controls, and third-party dependencies. A platform team may provide authentication, secrets storage, logging, or runtime isolation, while product teams inherit those controls without fully understanding the residual risk. That makes boundary definition and responsibility mapping essential. It also matters for agentic and highly automated systems, where tool access, runtime permissions, and short-lived secrets can change frequently. For that reason, the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10 help teams connect RMF requirements to the realities of identity sprawl, while the 2024 ESG Report: Managing Non-Human Identities shows why unmanaged NHIs quickly turn into enterprise risk.

Organisations should also treat decommissioning as part of RMF, not an afterthought. If system retirement, key revocation, and record retention are skipped, the authorization decision remains valid on paper but false in practice.

Related resources from NHI Mgmt Group

• How should security teams implement an AI risk management framework across discovery, policy, and monitoring?
• How should security teams implement an AI-native human risk management platform in a large enterprise?
• When should organisations treat an NHI as a high-priority risk?
• How should organisations automate user lifecycle management across HR and SaaS systems?