Manage Risk—Don’t Let It Manage You: Why RMF Shouldn’t Derail the Mission
In too many Federal and Defense environments, the Authorization to Operate (ATO) process becomes a monster—one that swallows time, budgets, and sometimes even the mission itself.
You know the story. A team builds an innovative capability. They’re fast, aligned with user needs, and rooted in sound engineering. But once it enters the risk management framework (RMF) pipeline, progress screeches to a halt. Months pass. Innovation fades. And what finally limps into production is a shadow of the original vision.
This is not a technical failure. This is a strategic failure of posture, leadership, and alignment.
Mission Owners: You Own the Risk
Let’s be clear: Mission Owners are the decision-makers. Not your ISSO. Not the SCA. Not the AO.
Security and compliance personnel are critical—moderators, auditors, validators—but they do not drive your mission. You do.
The legal authority to accept risk resides with you. That means:
You are empowered to push back when innovation is stifled by policy misinterpretation
You are accountable for balancing mission outcomes with security posture
You are not obligated to pursue the most conservative path—you’re expected to make sound, defensible decisions
Too often, RMF is treated like gospel. But it’s a framework, not a rulebook. It doesn’t replace judgment. It demands it.
Don’t Let Policy Dictate Architecture
One of the most damaging patterns in Defense IT is letting RMF policy dictate your technical strategy. Teams chase ACAS reports, inherit outdated controls, or shape architectures to appease a checklist—rather than designing with security and mission in mind.
The result? Less capable, value-poor systems that are secure on paper but weak in reality.
Instead, build your systems using modern, industry-proven best practices—zero trust, ephemeral infrastructure, automated compliance pipelines—not 2000s-era bureaucracy. If your security strategy hinges on what your ISSO can read from a Nessus export, you're not building to last.
Real Example: When RMF Missteps Make You Less Secure
On one recent project, we designed a secure cloud-native environment using Zero Trust Network Access (ZTNA). No flat networks, no perimeter scanning, and no long-lived credentials. We had a FedRAMP-authorized SaaS vulnerability scanning solution integrated directly with our CSP—approved by the AO and covered under the Provisional ATO.
Still, an ISSO demanded we implement ACAS “per policy.”
But here’s the issue: ACAS wasn't built for ZTNA environments. To use it, we would have needed to:
Open firewall rules and lateral network paths
Provision long-lived credentials for “credentialed scans”
Break isolation principles we intentionally designed
In short, ACAS would’ve increased our attack surface.
We pushed back and stuck with the integrated scanning solution. It required no network changes, no exposed ports, and no permanent secrets. It kept the environment more secure—and cost less.
That’s not noncompliance. That’s informed, mission-driven risk management.
Build It Right, and RMF Becomes a Byproduct
Here’s what most programs miss: if you build it right, RMF takes care of itself.
Start with security. Design for identity-based access, encryption, observability, and compliance as code. When you bake controls into your architecture and pipelines from day one, you're not “achieving RMF”—you're demonstrating it through design.
You cannot build first and bolt on RMF later. That’s the root of delay, frustration, and insecure-by-default environments. RMF should be a lens, not a leash.
RMF Professionals: Know the Mission, Know the Tech
If you're in an RMF role—ISSO, SCA, AO—you have an obligation to know your domain. Not just NIST controls, but the system itself:
Do you understand the architecture you’re reviewing?
Do you know modern cloud, DevSecOps, and threat models?
Can you distinguish real security risk from procedural noise?
Because if you can’t, you may be making things worse. RMF professionals must interpret policy with technical and operational context. If you’re blocking capability because of stale checklists, you’re not securing the mission—you’re paralyzing it.
Security is Cross-Functional, Always
Real security comes from collaboration across:
People – Mission owners, developers, security teams, operators
Processes – Agile workflows, CI/CD, incident response
Tools – Infrastructure as code, centralized logging, automation
No one pillar works alone. The best systems share accountability. Teams speak across domains. Misunderstandings are resolved through discussion, not deference.
If you silo risk management into a box labeled “cyber,” you will get brittle systems with limited value.
Guidance Is Not Gospel
Yes, the DoD has mountains of policy. Directives, memos, RMF overlays, STIGs. But don’t mistake volume for clarity.
Guidance is just that—guidance. It requires interpretation. And when conflicts or ambiguities arise, you must navigate, not freeze. That may mean:
Correcting an SCA’s misunderstanding
Requesting clarifications from policy authorities
Documenting risk decisions that deviate from the “default path”
Blindly applying every control interpretation to every system guarantees delay. It’s your job to cut through that fog with sound judgment.
Conclusion: Lead with Mission, Build with Security, Apply RMF Wisely
Risk management should support the mission—not suffocate it.
Mission owners: you are in control. RMF staff: you are advisors, not gatekeepers. Engineers: you are the tip of the spear—build with security from day one.
Together, you can move fast, deliver real outcomes, and stay compliant. But only if you stop letting frameworks drive your architecture, and start using architecture to prove your security.