Latest / Story
The ATO Paperwork, in Plain Order: What Comes First
The ATO package looks scary from the outside. Inside, it is documents in a fixed build order. Each one feeds the next. Work them in sequence and the process stays sane.
First: write the System Security Plan
Start with the System Security Plan, the SSP. It describes the system, its boundary, and the security controls in place.
The plan covers the purpose of the system and the state of each control. It also names the people responsible for it. That is what NIST asks for in a security plan. NIST SP 800-18 Rev. 2
NIST revised this guide as Rev. 2 in June 2026, replacing the 2006 Rev. 1. The core idea is unchanged: the plan is the reference every other document points to. NIST SP 800-18 Rev. 1
Write the SSP before any testing starts. An assessor cannot test claims that do not exist yet. A plan written after the testing is just a rewrite of the results.
Concrete example: take the control that requires multi-factor login. The SSP names the tool you use and who it applies to. It also says where the settings live. That one paragraph drives the whole assessment of that control.
Second: test the controls
Next, someone tests each control the SSP claims. This is the Assess step of the Risk Management Framework. NIST SP 800-37 Rev. 2
Testers read settings, run scans, and interview staff. They check whether each control works as written, not just whether it exists.
Keep the tester close while this runs. Ask questions early instead of guessing what they want. Surprises at report time cost weeks.
Third: write the Security Assessment Report
The test results go in the Security Assessment Report, the SAR. It records what was tested, how it was tested, and what passed or failed.
The SAR follows the SSP control by control. Each control gets a clear verdict and the evidence behind it. Failed controls get a plain description of the gap.
Be honest in this report. A failed control found now becomes a fix. A failed control found later becomes a delay. Most first assessments find real problems, and that is normal.
Fourth: fix the gaps and write the POA&M
Every failed control needs a fix or a plan. Fix what you can right away, then re-test the fix. A fix without fresh proof is just a claim.
Unfinished fixes go in the Plan of Action and Milestones, the POA&M. Each item names the problem, the planned fix, the owner, and the date. POA&M stands for Plan of Action and Milestones.
The POA&M is a plan, not a confession. A real schedule with real owners builds trust. A page of wishes does the opposite.
Some risks get accepted instead of fixed. The Authorizing Official can accept a low risk in writing. Accepted risks still need watching during monitoring.
Fifth: hand the package to the Authorizing Official
The full package goes to the Authorizing Official. They read the SSP, the SAR, and the POA&M together.
Then they decide how much risk they accept. The decision is written and signed. That memo is the actual ATO. Everything before it was the argument for it.
The decision can come with conditions. The official may set limits on how the system runs or require fixes by a date. Conditions are common and workable.
Then: monitoring begins
Authorization starts the monitoring phase, not a vacation. The team watches for changes, runs scans, and reports the security status on a set schedule. NIST SP 800-37 Rev. 2
Big changes can restart the cycle. New features and new data types may need fresh testing and a fresh decision. Teams that kept their evidence current handle this without panic.
PolicyCortex keeps live Azure configuration evidence on hand. That way the SSP, the SAR, and the POA&M all point to current proof instead of stale exports.
Sources
- NIST SP 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations
- NIST SP 800-18 Rev. 2, Developing Security, Privacy, and Cybersecurity Supply Chain Risk Management Plans for Systems
Next step
Building the package step by step? Start collecting evidence now, so step one never waits on screenshots.