NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, National Institute of Standards and Technology, December 2018. https://doi.org/10.6028/NIST.SP.800-37r2 NIST SP 800-18 Revision 1, Guide for Developing Security Plans for Federal Information Systems, National Institute of Standards and Technology, February 2006. https://doi.org/10.6028/NIST.SP.800-18r1 NIST SP 800-53A Revision 5, Assessing Security and Privacy Controls in Information Systems and Organizations, National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53Ar5 NIST Risk Management Framework, Authorize Step, Computer Security Resource Center, National Institute of Standards and Technology. https://csrc.nist.gov/projects/risk-management/about-rmf/authorize-step

Latest / Story

Why Do ATO Packages Get Sent Back?

Q: Why packages get sent back

The returns below come up again and again. The SSP is incomplete. NIST SP 800-18 Revision 1 is the guide for writing security plans. It says the plan must describe the controls in place or planned ( NIST SP 800-18 Revision 1 ). Packages fail when sections are blank or marked to be determined. They fail when text is copied from a template with no system specifics. Controls are marked implemented with no evidence. Every control in the SSP needs proof in the SAR. The assessment methods are examine, interview, and test. NIST SP 800-53A Revision 5 describes them for assessing security and privacy controls ( NIST SP 800-53A Revision 5 ). A claim of implemented with no artifact behind it is a finding, not a control. Vulnerability scan findings are unaddressed. The SAR must include recent scan results and the assessor's analysis. High and critical findings with no POA&M entry tell the AO the risk is unknown. Unknown risk is not acceptable risk. The POA&M is missing entries or dates. Every open finding needs a POA&M entry with an owner and a target date. Entries without owners or dates are promises, not plans. The AO will not accept promises. The scope does not match the system. The authorization boundary defines what is in the system. If the SSP describes ten servers and the scans cover eight, two servers are unaccounted for. The AO cannot authorize a system with unknown parts. Implementation descriptions are vague. Writing we use a firewall describes nothing. The SSP must name the firewall, its location, its rules, and its owner. Vague text forces the AO to guess. The AO will not guess.

ATO Evidence · October 14, 2026

You submitted the package and it came back with questions. That is normal, but it is also avoidable. Most returned packages fail for the same handful of reasons.

What the package contains

An ATO, or Authorization to Operate, follows the Risk Management Framework. The Risk Management Framework, or RMF, is the NIST process for managing security and privacy risk. NIST is the National Institute of Standards and Technology. It is described in NIST SP 800-37 Revision 2 (NIST SP 800-37 Revision 2). SP stands for Special Publication.

The authorization package holds four documents (NIST RMF Authorize step). They are an executive summary, a security plan, assessment reports, and a plan of action and milestones. These go to the authorizing official, or AO. The AO is the senior official who decides whether the risk of operating the system is acceptable.

The security plan, or SSP, describes what the system should do and which controls protect it. The security assessment report, or SAR, says whether the controls actually work. The POA&M, the Plan of Action and Milestones, lists open findings and their fix dates. If any document is thin, the AO cannot make the decision. The package comes back.

Why packages get sent back

The returns below come up again and again.

The SSP is incomplete.

NIST SP 800-18 Revision 1 is the guide for writing security plans. It says the plan must describe the controls in place or planned (NIST SP 800-18 Revision 1). Packages fail when sections are blank or marked to be determined. They fail when text is copied from a template with no system specifics.

Controls are marked implemented with no evidence.

Every control in the SSP needs proof in the SAR. The assessment methods are examine, interview, and test. NIST SP 800-53A Revision 5 describes them for assessing security and privacy controls (NIST SP 800-53A Revision 5). A claim of implemented with no artifact behind it is a finding, not a control.

Vulnerability scan findings are unaddressed.

The SAR must include recent scan results and the assessor's analysis. High and critical findings with no POA&M entry tell the AO the risk is unknown. Unknown risk is not acceptable risk.

The POA&M is missing entries or dates.

Every open finding needs a POA&M entry with an owner and a target date. Entries without owners or dates are promises, not plans. The AO will not accept promises.

The scope does not match the system.

The authorization boundary defines what is in the system. If the SSP describes ten servers and the scans cover eight, two servers are unaccounted for. The AO cannot authorize a system with unknown parts.

Implementation descriptions are vague.

Writing we use a firewall describes nothing. The SSP must name the firewall, its location, its rules, and its owner. Vague text forces the AO to guess. The AO will not guess.

Pre-submission checklist

Run this list before the package leaves your hands.

Every SSP section is complete, with no placeholder text.
Each control marked implemented has at least one evidence artifact in the SAR.
Scan results are current, and every finding has a fix or a POA&M entry.
Every POA&M entry has a named owner and a target date.
The system boundary in the SSP matches the assets in the scans.
A reader new to your system can follow the SSP without asking questions.

PolicyCortex reads live Azure configuration and builds a System Security Plan, a Security Assessment Report, and POA&M output at https://policycortex.com.

Sources

NIST SP 800-37 Revision 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, National Institute of Standards and Technology, December 2018. https://doi.org/10.6028/NIST.SP.800-37r2
NIST SP 800-18 Revision 1, Guide for Developing Security Plans for Federal Information Systems, National Institute of Standards and Technology, February 2006. https://doi.org/10.6028/NIST.SP.800-18r1
NIST SP 800-53A Revision 5, Assessing Security and Privacy Controls in Information Systems and Organizations, National Institute of Standards and Technology. https://doi.org/10.6028/NIST.SP.800-53Ar5
NIST Risk Management Framework, Authorize Step, Computer Security Resource Center, National Institute of Standards and Technology. https://csrc.nist.gov/projects/risk-management/about-rmf/authorize-step