Authorization to Operate (ATO) & FedRAMP

What this guide covers

A plain-language map of how a system becomes allowed to run in government: what an Authorization to Operate (ATO) is, the NIST Risk Management Framework (RMF) lifecycle it comes from, how FedRAMP (and its state cousin GovRAMP) lets you inherit a cloud vendor’s security work, and where Maryland’s own rules sit on top. The recurring theme across the whole SaaS Catalog — buy and configure the government edition — is explained here, once.

Who it’s for

Engineering and program staff at a Maryland State agency or education entity who keep seeing “Authorization and ATO” on the catalog pages and “Make It Government-Ready” on the setup pages, and want to understand the vocabulary before talking to security, procurement, or an Authorizing Official.

Part of the SaaS Catalog.

Disclaimer. This is plain-language orientation, not security, compliance, or legal advice. FedRAMP governance, NIST baselines, and state policy all change, and several items below were volatile or unconfirmed at the last_verified date (see each [VOLATILE] and OPEN ITEM flag). The actual decision to operate belongs to your Authorizing Official and your security team — not to this page. Verify every framework detail against the primary source linked in the Sources table before relying on it.

TL;DR

An ATO is a decision, not a document. A senior official formally accepts the residual risk of running a system and signs off on operating it.

It is the “Authorize” step of the NIST RMF (NIST SP 800-37 Rev 2) — one stop in a seven-step lifecycle, not a one-time gate.

FIPS 199 impact (Low / Moderate / High) picks which NIST SP 800-53 control baseline applies. Higher impact, more controls.

FedRAMP lets you inherit a cloud vendor’s controls — but only the ones the vendor is responsible for. You still own the customer-responsible controls yourself.

Buy and configure the government edition, or there is nothing to inherit. FedRAMP attaches to a specific boundary (GovCloud, GCC High, “for Government”). The commercial edition is not authorized.

FedRAMP is federal; GovRAMP (formerly StateRAMP) is the state/local analog. Maryland is NIST-aligned with no published blanket GovRAMP/FedRAMP mandate found — but its Nonvisual Access accessibility clause is law.

Continuous monitoring never ends. Authorization is the start of an ongoing obligation, not the finish line.

What an ATO Is

An Authorization to Operate (ATO) is a formal management decision. A senior official — the Authorizing Official (AO) — reviews the security state of a system, decides that the remaining (residual) risk of operating it is acceptable, and explicitly authorizes the system to run. The ATO is the signature on that decision, not a checklist of controls; the controls are the evidence the AO weighs.

In framework terms, the ATO is the output of the Authorize step of the Risk Management Framework (RMF), defined in NIST Special Publication (SP) 800-37 Revision 2. Everything else in this guide — categorize the system, select controls, implement them, assess them, monitor them — exists to give the AO enough to make that one decision responsibly.

You will hear several variants of the term. They are not interchangeable.

ATO — Authorization to Operate

The standard case: the AO authorizes a specific system, within a specific boundary, to operate.

IATO — Interim Authorization to Operate

A legacy term for a time-limited, conditional authorization. UNVERIFIED under Rev 2: the interim/conditional construct from older RMF guidance is not a clean, current concept under SP 800-37 Rev 2 — treat “IATO” as legacy vocabulary and confirm what your agency actually means by it rather than assuming a formal Rev 2 definition.

ATU — Authority (Authorization) to Use

Used for shared or cloud systems an agency consumes but does not itself own. Rather than authorizing the system from scratch, the AO issues an ATU that leverages an existing authorization. A FedRAMP authorization can be the basis for an agency ATU — the agency reviews the cloud provider’s authorization package and authorizes its own use of that service.

cATO / Ongoing Authorization

Continuous ATO. Instead of a fixed authorization that expires and forces a periodic re-authorization scramble, continuous monitoring keeps the authorization live. The system stays authorized as long as it keeps meeting its security obligations and the AO keeps accepting the risk based on current data.

ATOs have traditionally been time-bound — commonly cited as up to about three years. Treat the three-year figure as practice and policy, not a hard NIST mandate; the move toward cATO and ongoing authorization exists precisely to replace the calendar-driven re-auth with continuous evidence.

The RMF Lifecycle

The RMF (NIST SP 800-37 Rev 2) is a seven-step lifecycle. The ATO is step six.

Prepare · Categorize · Select · Implement · Assess · Authorize · Monitor

Prepare — get the organization and system ready: roles, risk strategy, common controls.
Categorize — classify the system’s impact level (see Impact Levels).
Select — choose the control baseline that matches that impact level, then tailor it.
Implement — actually configure and deploy the controls.
Assess — test whether the implemented controls work as intended.
Authorize — the AO weighs residual risk and issues (or withholds) the ATO.
Monitor — keep watching, scanning, and reporting for as long as the system runs.

Each step produces artifacts the AO and assessors rely on. These are the documents you will hear named in any authorization conversation.

Artifact	What it is	Anchored in
SSP — System Security Plan	Describes the system, its authorization boundary, and how each control is implemented.	NIST SP 800-37 / 800-53
SAP / SAR — Security Assessment Plan / Report	The plan for testing controls, and the results of that testing.	NIST SP 800-53A
POA&M — Plan of Action & Milestones	The list of known weaknesses plus the schedule and owners to remediate them.	RMF / 800-37
ConMon — Continuous Monitoring	The ongoing program of scanning, reporting, and reassessment after authorization.	NIST SP 800-137

The authorization boundary defined in the SSP is the single most consequential idea for procurement — it is what FedRAMP attaches to. See Buy and Configure the Government Edition.

Impact Levels and Control Baselines

How many controls a system needs depends on how much damage its failure would cause. FIPS 199 (Federal Information Processing Standard 199) categorizes a system by the potential impact of losing each of three properties:

Confidentiality — unauthorized disclosure.
Integrity — unauthorized modification or destruction.
Availability — disruption of access or use.

Each property is rated Low, Moderate, or High, and the system takes the high-water mark — the single highest rating across the three becomes the system’s overall impact level. That level selects a control baseline from NIST SP 800-53 Revision 5, with the baselines themselves defined in NIST SP 800-53B.

The baselines grow with impact. Approximate control counts (mark as approximate — verify against 800-53B):

Impact level	Approximate control count	Notes
Low	≈ 149 controls	Smallest baseline.
Moderate	≈ 287 controls	The most common SaaS target.
High	≈ 370 controls	For systems whose loss is serious or catastrophic.

The controls are organized into roughly 20 control families (access control, incident response, configuration management, and so on). The counts above are approximate and from a secondary source — use them to understand the relative jump between levels, not as exact figures.

FedRAMP

The Federal Risk and Authorization Management Program (FedRAMP) standardizes how cloud services are assessed, authorized, and continuously monitored for use by federal agencies. Instead of every agency independently authorizing the same cloud product, a cloud service provider (CSP) is assessed once against a FedRAMP baseline, and agencies can leverage that work. Authorized products are listed on the FedRAMP Marketplace.

[VOLATILE — flag clearly. FedRAMP governance changed in 2024–2025; treat every specific below as a snapshot to re-verify on fedramp.gov.]

The Joint Authorization Board (JAB) was replaced. Per OMB Memo M-24-15 (2024), the JAB authorization path was dissolved.
A FedRAMP Board now governs the program (launched 2024).
The program is shifting to a single “FedRAMP Authorized” designation reached via agency authorization, rather than the old JAB-vs-agency split.
FedRAMP 20x is an automation-first initiative — built around Key Security Indicators (KSIs) and machine-readable validation — in pilot through 2025. Its specifics are early and changing.

Present all post-JAB governance and FedRAMP 20x details as point-in-time and subject to change. Confirm current state on fedramp.gov before citing any of it in a security package.

Inheritance vs. Customer Responsibility

A FedRAMP authorization is not a blanket compliance stamp for whatever you build on top of it. The CSP publishes a Customer Responsibility Matrix (CRM) — also called the Control Implementation Summary (CIS), found in SSP Appendix J — that marks each control as:

CSP-responsible — the provider implements it; you inherit it.
Customer-responsible — you implement it, in your own configuration and tenant.
Shared — both parties have a part.
Inherited — provided by an underlying authorized service.

Inheriting a FedRAMP authorization does not make your agency automatically compliant. You still have to implement every customer-responsible control yourself. The CRM is the document that tells you which ones those are — read it before assuming the vendor’s authorization covers you.

StateRAMP / GovRAMP

FedRAMP is federal. For state, local, tribal, and education entities, the analogous program is GovRAMP — which rebranded from StateRAMP in February 2025. Use both names when searching, because older citations and product listings still say “StateRAMP.”

Based on NIST SP 800-53, the same control catalog FedRAMP uses.
Recognizes FedRAMP — a FedRAMP authorization is honored (reciprocity), so a vendor does not have to be assessed twice from scratch.
Voluntary. Membership in and use of GovRAMP is not an automatic mandate; whether it applies to a given procurement depends on the entity’s own policy or contract language.

Maryland Specifics

Maryland follows the NIST approach but layers its own policy on top. Three things matter for a procurement.

The State IT Security Manual is NIST-aligned

The State of Maryland IT Security Manual, published by the DoIT Office of Security Management, is aligned to NIST SP 800-53. If you understand the RMF and 800-53 baselines, you understand the spine of Maryland’s security expectations.

Data Classification has four levels

The Maryland Data Classification Policy defines four levels: Public, Protected / Internal-Only, Confidential, and Restricted. Where your data lands on this scale drives how much security rigor the system needs — it is Maryland’s parallel to the FIPS 199 impact decision.

Whether GovRAMP/FedRAMP is required — OPEN ITEM

OPEN ITEM — mark clearly: Maryland publishes no blanket statewide StateRAMP / GovRAMP / FedRAMP mandate that was found at the last_verified date. That does not mean no requirement applies to you — any such requirement for a specific agency or buy generally lives in the solicitation or contract language, not in a single statewide rule. Confirm with DoIT for your agency and your procurement.

Nonvisual Access is law — and is frequently overlooked

This one is not optional and not a framework: it is statute and regulation. Maryland’s Nonvisual Access (NVA) requirement — State Finance & Procurement Article §3A-311 plus COMAR 14.33.02 — requires that state IT contracts deliver equivalent visual and nonvisual access to information technology. This is exactly why every catalog and setup page keeps a VPAT / ACR (accessibility conformance) gate. A product that cannot demonstrate nonvisual access can fail the procurement regardless of its security posture.

Buy and Configure the Government Edition

This is the single point the entire SaaS Catalog keeps returning to, and it follows directly from the authorization boundary concept in the RMF.

A FedRAMP authorization attaches to one specific boundary — the exact system, region, and configuration that was assessed. Vendors run their government editions as separate boundaries from their commercial products:

AWS GovCloud is a separate partition from commercial AWS.
Microsoft GCC High is a separate environment from commercial Microsoft 365.
A “for Government” / “FED” region is a separate tenant from the commercial SaaS.

The commercial edition is not covered by the government boundary’s authorization. If you buy or provision the commercial product, there is no authorization to inherit, and the gap typically surfaces late — during the security review, after money has been committed. This is why procurement insists on ordering the government edition and why setup insists on configuring that edition’s console. They are the same requirement seen from two ends.

See the per-tool ATO caveats in the SaaS Catalog Playbook and the configuration side in the Implementation hub.

After the ATO — Continuous Monitoring

Authorization is the beginning of an obligation, not the end of one. Once a system has its ATO, it enters continuous monitoring (ConMon) — the Monitor step of the RMF, anchored in NIST SP 800-137. The typical obligations:

Monthly vulnerability scanning — recurring authenticated scans of the authorized boundary. See Tenable for the scanning tool side of this.
Ongoing POA&M updates — every known weakness gets tracked with a remediation owner and deadline. Remediation timelines are commonly cited as High 30 days / Moderate 90 days / Low 180 days — mark as “commonly cited, verify”; the exact windows depend on the program (FedRAMP, agency, GovRAMP) and change.
Annual assessment — a periodic reassessment of a subset of controls.
Significant-change re-authorization — a material change to the system (new boundary, new data type, major architecture shift) can trigger a fresh authorization decision.

The entire point of cATO and FedRAMP 20x is to turn this from a calendar-driven scramble into a continuous, data-driven state where the authorization stays live because the evidence stays current.

Sources

Claim	Source
RMF lifecycle and Authorize step (SP 800-37 Rev 2)	NIST SP 800-37 Rev 2
Control baselines defined in 800-53B	NIST SP 800-53B
FIPS 199 categorization / baseline context	NIST — Control Baselines (SP 800-53B)
Approximate control counts (Low/Mod/High) — secondary	Secureframe — NIST 800-53 baselines
cATO / continuous authorization	DoD — Continuous ATO memo
ATU as a basis from FedRAMP	FedRAMP — ATO vs ATU
FedRAMP program overview / Marketplace	FedRAMP
FedRAMP governance (post-JAB)	FedRAMP — Governance
FedRAMP Board launch	GSA — FedRAMP Board launched
JAB replacement (OMB M-24-15)	Federal News Network — OMB replaces FedRAMP JAB
Single authorization designation	ExecutiveGov — one FedRAMP designation
FedRAMP 20x	FedRAMP 20x
Authorization boundary guidance	FedRAMP — Authorization Boundary Guidance (PDF)
Inheritance / CRM / shared responsibility	Elevate Consulting — FedRAMP inheritance & shared responsibility
StateRAMP → GovRAMP rebrand (Feb 2025)	GovRAMP — rebrand announcement
GovRAMP overview / FedRAMP reciprocity	Secureframe — GovRAMP overview
Maryland IT Security Manual (NIST-aligned)	Maryland IT Security Manual (PDF)
Maryland Data Classification (four levels)	Maryland Data Classification Policy
Maryland NVA — §3A-311	Md. State Finance & Procurement §3A-311
Maryland NVA — COMAR 14.33.02	COMAR 14.33.02

FedRAMP governance and the FedRAMP 20x program were actively changing at the last_verified date. Re-verify any post-JAB or 20x specifics on fedramp.gov before relying on them.

SaaS Catalog — Playbook — every tool’s “the one ATO caveat,” in one matrix
Datadog — a worked catalog page showing the gov-edition boundary in practice
Tenable — the vulnerability-scanning side of continuous monitoring
Implementation hub — “Make It Government-Ready”: configuring the gov edition’s console
Maryland Procurement — BPW, eMMA, COMAR thresholds that still bind the order
Tools and Software — the functionality gates, including the VPAT/ACR accessibility gate Maryland NVA requires