An Authority to Operate is a formal decision by a named official that a system's security risk is acceptable, and that it may run on the network and handle real data. No ATO, no production. It is the gate every government system passes through, and the one commercial vendors consistently underestimate.
What it actually is
Strip away the framework language and an ATO is a risk decision with a paper trail. Someone senior — the authorizing official — is putting their name to the statement that this system's risks have been identified, mitigated where practical, and accepted where not.
Everything in the process exists to let that person make that decision defensibly. Once you see it that way, the documentation burden stops looking like bureaucracy and starts looking like evidence.
The steps, in plain terms
- Categorize the system. How bad would it be if this data were exposed, altered, or unavailable? The answer (low, moderate, high) determines how many controls apply — and it is the single biggest driver of effort.
- Select controls. Pull the applicable control set for that level, then tailor it to the system with justification for anything you exclude.
- Implement. Actually build the controls, and write down how each one is satisfied. This produces the security plan.
- Assess. An independent assessor tests whether the controls work as described. Findings go into a remediation plan with owners and dates.
- Authorize. The authorizing official reviews the package and issues the ATO — often with conditions and an expiry.
- Monitor continuously. Ongoing scanning, reporting, and reassessment. The ATO is not permanent; it is a state you maintain.
Realistic timelines
Assuming a competent team and no major surprises:
- Low-impact system, inheriting most controls from an authorized platform: 3–6 months.
- Moderate-impact system on authorized infrastructure: 6–12 months.
- Moderate or high impact, new infrastructure: 12–18 months.
- FedRAMP authorization for a cloud service offering: 12–24 months and a seven-figure budget. Genuinely.
If a vendor tells you they will have an ATO in eight weeks, they are describing a different thing — usually inheriting an existing authorization, which is legitimate but is not the same as obtaining one.
The five things that double the timeline
- Starting the paperwork after building the system. Retrofitting controls is dramatically more expensive than designing for them. This is the big one.
- Unclear boundaries. If nobody can draw exactly what is inside the system and what it connects to, the assessment cannot begin. Diagram it first.
- Inherited controls nobody documented. "The platform handles that" is not evidence. You need the platform's authorization package and a statement of what you inherit.
- Findings with no owner. Remediation plans stall when items have dates but no named person.
- Assessor availability. Independent assessors are booked months ahead. Schedule before you think you need to.
How to make it faster
- Inherit aggressively. Building on already-authorized infrastructure lets you inherit a large share of the controls. This is the single biggest lever available.
- Write the security plan as you build, not afterward. Every control implemented should be documented the same week.
- Automate the evidence. Continuous monitoring you have to assemble by hand will not survive contact with reality.
- Keep the boundary small. Every additional component is more controls, more testing, more documentation. Scope discipline is security discipline.
- Engage the assessor early. Ask what they will want to see. They will tell you, and it costs nothing.
The part worth internalizing
An ATO is not a certificate you obtain and file. It expires, it carries conditions, and continuous monitoring is a standing obligation with real staffing implications. Budget for the ongoing programme, not just the initial package — agencies that treat authorization as a one-off project are the ones scrambling three years later.
This work sits at the centre of our cybersecurity practice, and where a system is being built from scratch it runs alongside application development so the controls are designed in rather than bolted on. The Zero Trust buyer's guide covers the architecture side in more depth.
Have a system heading toward authorization? The earlier the conversation, the shorter the path.