RMFInsider

If you want to know how to get an ATO step by step, here is the short version before the long one: you take a system through the six steps of the Risk Management Framework, produce a package of evidence that a control set is implemented and the residual risk is understood, and hand it to an Authorizing Official who signs the Authorization to Operate. The ISSO doesn’t sign the ATO — but the ISSO does almost everything that makes it signable. This is that job, walked as a to-do list rather than a textbook.

I’ve shepherded systems through this process more than once, and the sequence below is what I actually do at each step. If you’re a new ISSO who’s been handed a system and told to “get it authorized,” read this once end to end so the map makes sense, then use it as a checklist.

What an ATO Actually Is (and Who Signs It)

An Authorization to Operate is a formal decision by a senior official — the Authorizing Official, or AO — to accept the risk of running an information system and let it operate on the network. It is a risk decision, not a compliance checkbox. Everything you assemble is there to let the AO make that decision with eyes open. When people ask how long an ATO takes, the honest answer is: as long as it takes to build a package the AO trusts, which is why doing each step cleanly the first time is the fastest path.

The RMF has six steps: Categorize, Select, Implement, Assess, Authorize, and Monitor. The ISSO lives inside all six. Here’s what you personally do in each.

Steps 1–2: Categorize and Select (What the ISSO Prepares)

Categorize. Everything downstream is driven by the impact level you set here, so get it right. Using FIPS 199 and CNSSI 1253, you rate the system’s confidentiality, integrity, and availability as Low, Moderate, or High based on the information types it processes. A Moderate-Moderate-Low system pulls a very different control set than a High system. As ISSO you gather the information types from the system owner and mission owner, document the categorization rationale, and make sure the system owner and AO concur before you move on. A categorization that gets challenged during assessment sends you back to the start.

Select. The categorization maps to a NIST SP 800-53 control baseline (Low, Moderate, or High), and then you tailor it — applying overlays (classified, privacy, cloud), adding organization-defined parameters, and documenting inherited controls. This is where you decide what the system implements itself versus what it inherits from a data center, an enclave, or a cloud service provider. Getting inheritance right here is the single biggest workload lever in the whole process; I broke down how that works in control inheritance in RMF. The output of this step is a defined control set and the skeleton of your System Security Plan.

Steps 3–4: Implement and Assess (SSP, Artifacts, and the SCA)

Implement. Now the controls get built and documented. The engineers configure the system; you document how each control is met in the System Security Plan (SSP). This is the heaviest writing phase of the job. For every control you write an implementation statement that says specifically how the system satisfies it — not “the system enforces least privilege” but which mechanism, on which components, configured how. You also apply and document STIGs, run initial ACAS scans, and start collecting artifacts: configuration exports, screenshots, policy documents, diagrams.

A practical tip that saves weeks: build your artifact inventory early and track it like a project. Every control that needs evidence, what evidence, and whether you have it yet. Half of ATO delays are not technical failures — they’re missing paperwork discovered late.

Assess. A Security Control Assessor (SCA) — independent of the system team — tests the controls against the assessment procedures and produces a Security Assessment Report (SAR). They’ll rescan with ACAS, review your STIG results, sample your artifacts, and interview your team. Findings come back rated CAT I (high), CAT II (medium), or CAT III (low). Your job during assessment is to be the single point of contact, produce evidence fast, and never argue a finding you can’t back up. The cleaner your SSP and artifacts from the Implement step, the fewer surprises land in the SAR.

Step 5: Authorize — Building the Package the AO Will Sign

This is where you assemble the authorization package. At its core it’s three things: the System Security Plan, the Security Assessment Report, and the Plan of Action and Milestones (POA&M). The SSP says what you built, the SAR says what the assessor found, and the POA&M says what you’re doing about everything still open.

Every open finding from the SAR becomes a POA&M entry, because an AO will rarely authorize a system with unmanaged open findings — but will routinely authorize one with well-documented, mitigated, scheduled findings. Writing those entries so they read as managed risk rather than loose ends is a skill in itself; I walk through it field by field in how to write a POA&M. The AO then reviews the risk, and issues one of a few outcomes:

Decision	What it means
Full ATO	Authorized to operate, typically up to three years, with continuous monitoring
ATO with conditions	Authorized, but specific POA&M items must be closed on a set timeline
Interim authorization (IATT / conditional)	Time-boxed authorization to operate or test while work continues
Denial (DATO)	Risk is unacceptable; the system may not operate

Step 6: Monitor — Continuous Monitoring Keeps the ATO Alive

An ATO is not a finish line; it’s a state you have to maintain. The moment it’s signed you’re in continuous monitoring: ongoing ACAS scans, patching, POA&M closure, control reviews, and reporting security-relevant changes to the AO. A system that stops being monitored is a system whose authorization quietly rots until reauthorization time, when all that deferred work lands at once. Build the rhythm from day one — I laid out exactly what that looks like day to day in the RMF continuous monitoring checklist.

Track every artifact your ATO package needs

The hardest part of a first ATO isn’t understanding the six steps — it’s not losing track of the dozens of artifacts each one demands. The RMF Checklist ($27) is the step-by-step artifact tracker I use to keep a package moving from Categorize to Authorize without gaps.

Timeline Expectations and the 5 Things That Stall an ATO

A moderate system with an engaged team commonly runs six to twelve months from kickoff to signature — longer if any of these stall it:

1. A shaky categorization. If the impact level gets challenged late, you re-tailor controls and rewrite SSP sections — weeks lost.
2. An incomplete SSP. Vague implementation statements generate assessor questions, and every question is a round-trip.
3. Missing artifacts. The evidence exists in someone’s head or on a server, but not in the package. This is the most common delay of all.
4. Open CAT I findings with no mitigation. An unmitigated high finding is often an automatic stop until it’s addressed or credibly mitigated in the POA&M.
5. A cold AO. If the AO first sees the system when the package lands, expect questions. Brief them early so authorization is a confirmation, not a first impression.

Final Thoughts

Learning how to get an ATO step by step is really about internalizing one idea: every step exists to make the AO’s risk decision defensible. Categorize accurately, select and inherit smartly, implement and document thoroughly, survive the assessment with evidence, package the residual risk honestly, and monitor relentlessly. Do that and the signature at Step 5 stops feeling like a hurdle and starts feeling like the natural result of work you already did right.