I have executed full Risk Management Framework (RMF)/Authority to Operate (ATO) lifecycles across seven operational submarines. That is seven packages — each with its own command climate, its own readiness timeline, its own cast of engineers who did not get the memo about why documentation matters. After all of it, I can tell you this with certainty: the framework does not fail. People fail the framework.
And usually, they fail it the same way every time.
The Gap Is Never Technical
When I get brought in to troubleshoot an ATO problem, the first thing I do is not open eMASS. I talk to people. I ask the XO what the CO thinks the system does. I ask the engineer what controls he is confident about. I ask the Information System Security Officer (ISSO) how long it has been since they actually reviewed their Plan of Action and Milestones (POA&M).
Nine times out of ten, the gap is not a missing Security Technical Implementation Guide (STIG) finding or an unplugged vulnerability. The gap is that nobody owns the narrative. The package exists, but the people responsible for it cannot explain it — and when the Designated Accrediting Authority (DAA)’s office calls with a question, that silence becomes a delay that stretches into months.
The most dangerous thing in an RMF package is a control marked "Implemented" that nobody can speak to from memory.
What Most Contractors Get Wrong Before the Package Hits My Desk
1. They treat the System Security Plan (SSP) like a compliance document, not a communication tool
The System Security Plan (SSP) is the story of your system. It should read like something a two-star could hand to their chief of staff and get a confident briefing on. Instead, I regularly see SSPs copy-pasted from templates — control descriptions that reference systems that do not exist, inherited controls applied wholesale without tailoring, and "see attached" pointing to attachments that are not attached.
If your DAA cannot trust that your SSP reflects reality, your ATO is already in trouble.
2. The POA&M is treated as a parking lot, not a management tool
A POA&M should be a living, actively-managed document that shows your command is in control of its risk posture. What I usually find instead is a list of findings that have not been touched since the last inspection, with scheduled completion dates that passed two quarters ago.
Authorizing officials notice this immediately. An overdue POA&M does not just reflect a security gap — it reflects a leadership gap. It says nobody is watching.
3. Assured Compliance Assessment Solution (ACAS) scans are run, not read
I have seen commands run ACAS scans on a perfect schedule and still get hammered on inspection because nobody analyzed the output. Running the scan is not the mission. Understanding what the scan is telling you — and being able to explain what you have done about it — that is the mission.
Vulnerability Remediation Asset Manager (VRAM) entries need to tell a story. When did we find it, what is the risk, what did we do, and what is the residual? If the answer to any of those is "I would have to look it up," you are not ready.
4. They underestimate the human element of the authorization review
The most underrated skill in RMF is being able to walk a senior official through your package in a 15-minute brief and leave them with confidence. This is not a technical skill — it is a communication skill. And most technical people have never been taught to do it.
I train my ISSOs to brief the package the way a department head briefs a readiness review: status, risk, mitigation, recommendation. When an Authorizing Official (AO) can ask any question and get a clean, direct answer, the authorization moves fast. When they cannot, it does not.
What Actually Works
The commands I have seen achieve and sustain ATOs most effectively have a few things in common:
- Senior leader engagement. The CO or department head knows the system’s authorization status and authorization boundary. They cannot explain every control, but they know the risk posture and they have signed off on it consciously.
- Continuous monitoring as a habit, not a checkbox. ACAS scans reviewed weekly. POA&M milestones tracked monthly. No findings go stale without a deliberate decision to accept residual risk.
- A single ISSM who owns the narrative. Not a committee. Not a contractor with an email. One person who can walk any assessor through any part of the package at any time.
- Inheritance done right. Inherited controls are documented with specificity — what's actually provided, what's actually required of the system, and who verified it. Not a blanket statement that common controls are "inherited from the platform."
The framework is sound. NIST 800-37 gives you everything you need to run a rigorous authorization process. The checklist is not your problem. Your problem is whether the people responsible for the system actually understand it well enough to defend it — and whether anyone in the chain of command cares enough to find out before the assessor does.
The Takeaway
If you are a contractor supporting an ISSM or running an ATO package, the highest-value thing you can do is not find more findings — it is to make sure the humans in the loop can speak to what is already documented. Hold a tabletop. Run a mock assessment. Force the hard questions before the real ones arrive.
RMF is not a one-time event. It is an ongoing demonstration that your organization is in control of its systems and its risk. If your package tells that story clearly, the authorization follows. If it does not, no amount of completed controls will save you.
— Travis D. Butera