Authority to Operate: what an ATO is and how to get one

What an authority to operate is

An ATO is a formal risk-acceptance decision, not a technical certification and not a guarantee that a system is free of vulnerabilities. The authorizing official reviews a defined evidence package, weighs the residual risk it documents, and decides whether that risk is acceptable given the system's mission and the sensitivity of the data it handles.

The package the AO reviews has a consistent shape: the System Security Plan describing the system and its implemented controls, the Security Assessment Report documenting an independent assessor's test results, and the Plan of Action and Milestones tracking anything not yet resolved. A Risk Assessment Report often accompanies the package as a standalone summary of the risk picture the other three documents support.

The output is an ATO letter, a signed memorandum recording the decision: full authorization, a time-limited interim authorization, or denial. Historically an ATO ran on a fixed cycle, commonly three years, though continuous monitoring has increasingly shifted agencies toward ongoing authorization rather than waiting for a calendar date to force a full reassessment, the model a continuous ATO formalizes.

Who needs an authority to operate

Any federal information system needs an authorization decision before it operates, and that requirement extends well past agency-owned hardware.

• Federal agencies, for every system in their inventory, including systems that have been running for years and are due for reauthorization.
• Contractors and cloud service providers operating a system on an agency's behalf, including FedRAMP-authorized cloud providers, whose authorization is sponsored by the agency relying on the system.
• Component bureaus and sub-agencies, each of which typically needs its own system-level ATO even where it inherits common controls from a parent agency's shared infrastructure.

A system that inherits controls from an already-authorized environment underneath it still needs its own authorization decision at the system level; inheritance reduces the work, it does not eliminate the requirement.

The ATO package, piece by piece

Who signs an ATO?

The authorizing official signs it: a senior agency official, often a CIO or CISO delegate, with the budget authority and mission accountability to accept risk on the agency's behalf. The AO is deliberately distinct from the ISSO or ISSM who prepared the package and from the assessor who tested it; the signature represents an independent risk decision, not a rubber stamp on someone else's work.

Before a full ATO is granted, a system sometimes needs to operate briefly in a live or production-like environment to complete testing. An Interim Authorization to Test, or IATT, permits that limited operation for a defined window; it is not a substitute for a full authorization and typically comes with restrictions that a full ATO does not carry.

The path to an authority to operate, step by step

1. Categorize and scope the system: Determine the system's impact level and draw the authorization boundary; typically two to four weeks.
2. Build the System Security Plan: Document how every applicable control is implemented across the boundary; often the largest single authoring effort, commonly two to four months.
3. Undergo independent assessment: An assessor tests the implemented controls and produces the Security Assessment Report; four to twelve weeks depending on system size and complexity.
4. Remediate and build the POA&M: Close what can be closed before the package goes to the AO, and document the rest with realistic dates rather than placeholders.
5. Authorizing official reviews the package: The AO reviews the SSP, SAR, and POA&M together and weighs the residual risk; typically four to eight weeks for a clean package.
6. AO issues the decision: Full authorization, a time-limited Interim Authorization to Test, or denial pending further remediation.
7. Maintain authorization over time: Reauthorize on a fixed cycle, historically three years, or maintain currency through ongoing authorization backed by continuous monitoring; this phase does not end.

How long does getting an ATO take and what does it cost?

A first-time ATO for a moderately complex system, starting without an existing authorized environment to inherit controls from, commonly takes six to eighteen months end to end. A system that inherits a substantial share of its controls from an already-authorized common control provider can close faster, often in four to nine months; a large, novel system with significant remediation needed after assessment can run well past eighteen months.

Cost splits between internal labor, building the SSP and remediating findings, and the independent assessor's fee for testing the package. Assessor costs vary widely by program and system size: figures in the tens of thousands of dollars are typical for a small system, and $75,000 to $250,000 or more is common for a large, complex one, broadly consistent with the assessment costs described on the NIST RMF and FedRAMP pages, since both processes produce an ATO through essentially the same package structure. Reauthorization is typically cheaper than the first pass, since the SSP and much of the control evidence already exist and only need updating rather than authoring from zero.

ACTA is licensed per environment, and every engagement starts with a conversation. ACTA automates the SSP, SAR, POA&M, and Risk Assessment Report generation described below; it does not perform, and cannot replace, the independent assessor's own testing of the package.

Common failure points

The same handful of mistakes shows up across most ATO efforts, whether it is a first authorization or a reauthorization.

• POA&M items that describe an intended fix without a verifiable date or owner, which an AO reads as an open risk rather than a managed one.
• An SSP that describes an environment that has already changed by the time the assessor tests it.
• An authorization boundary drawn inconsistently between what the SSP claims and what the assessor actually finds in scope.
• Treating an Interim Authorization to Test as a full ATO and operating past its defined window.
• Waiting until the three-year reauthorization deadline is imminent before starting the refresh, rather than treating currency as an ongoing responsibility.
• An AO's risk-acceptance rationale left undocumented, which makes the decision harder to defend, or transfer to a successor, later.

How ACTA automates authority to operate work

ACTA generates the full ATO package, System Security Plan, Security Assessment Report, POA&M, and Risk Assessment Report, from a live environment, deterministically, rather than as a document authored once and left to describe a system that keeps changing underneath it. If the environment does not exist yet, ACTA can provision it as code, on AWS commercial, AWS GovCloud, Microsoft GCC High, Azure, Google Cloud, or bare metal, with a small environment standing up in roughly 25 minutes.

Because ACTA runs on goRapide, BMD's deterministic causal engine, with no LLMs, no agents, and nothing probabilistic in the compliance path, the package an AO reviews carries an inspectable causal chain behind every control determination, and running the same environment through the same journey again produces identical artifacts and identical evidence, a property that matters directly when an AO's decision needs to be defensible months or years later.

ACTA's federal pack library includes the frameworks that typically drive an ATO package, FedRAMP, NIST 800-53, the NIST RMF, and FISMA, and every pack ships with every license. Packs are editable YAML, so control narratives reflect a specific system rather than a generic template.

After authorization, ACTA's continuous monitoring tracks credential health, evidence freshness, endpoint posture, and drift from previously passing controls, the exact areas where an ATO quietly goes stale between the point it is signed and the next scheduled review. A stale posture refreshes to current in two clicks, the foundation the continuous ATO model builds on to move beyond a fixed reauthorization date entirely.

Authority to operate and adjacent frameworks

The NIST RMF's Authorize step is where an ATO gets produced: the framework's earlier steps build the SSP, SAR, and POA&M, and Authorize is the point an AO reviews that package and signs the decision. FedRAMP is effectively a cloud-specific ATO process, with an agency sponsor standing in for the authorizing role and a 3PAO performing the independent assessment.

A traditional ATO is a snapshot, accurate the day it is signed and steadily less accurate afterward. A continuous ATO replaces that fixed reauthorization cycle with ongoing evidence, so the authorization stays current continuously instead of waiting for the next scheduled full reassessment.

See the compliance framework directory for how the authorization decision connects to the rest of the federal and defense frameworks this corpus covers.