FISMA ATO: Risk Management Framework, Package, and Monitoring

Under the Federal Information Security Modernization Act, no federal information system may process government data until a senior agency official has formally accepted its security risks and signed an Authority to Operate. The FISMA authority to operate process is a structured, seven-step path defined by the NIST Risk Management Framework: an agency categorizes the system by impact, selects and implements security controls, has those controls independently assessed, and then submits a documented package to an Authorizing Official who either approves the system, denies it, or approves it with conditions. The steps below explain what each stage requires, who is responsible for it, and what the final decision actually looks like.

What an ATO Is and Why It’s Required

FISMA, originally enacted in 2002 and updated in 2014, makes each agency head responsible for protecting the information and systems that support agency operations. Under 44 U.S.C. § 3554, that protection must be proportional to the risk of unauthorized access, disruption, or destruction, and the obligation reaches contractor-operated systems that handle federal data.¹

OMB Circular A-130 operationalizes that duty. It directs agencies to designate senior officials to authorize systems and common controls, and it requires that an initial authorization be completed before a system enters operational status.² Without an ATO, a system cannot go live, cannot connect to government networks, and cannot process federal data.

The Seven Steps of the Risk Management Framework

The ATO is the output of a process, not a document you assemble at the end. NIST Special Publication 800-37 Revision 2 defines seven steps that structure the work from earliest planning through post-authorization monitoring:³

Prepare: establish organizational context, identify key roles, and set risk priorities.
Categorize: classify the system and its data by impact.
Select: choose security controls from the NIST SP 800-53 catalog that match the risk profile.
Implement: put those controls in place and document exactly how they are deployed.
Assess: have an independent assessor test whether the controls actually work.
Authorize: a senior official reviews the evidence and makes a risk-based decision.
Monitor: track control effectiveness and emerging risks after authorization.

Most of the effort lives in Categorize, Select, Implement, and Assess. By the time the Authorize step arrives, the groundwork should already show that the system’s risk is manageable.

Categorizing the System and Choosing Controls

Federal Information Processing Standards Publication 199 requires agencies to categorize every system against three security objectives: confidentiality, integrity, and availability. Each objective is rated low, moderate, or high depending on the severity of the consequences if it were compromised.⁴ A public-facing site with no sensitive data may land at low across the board; a system holding personnel or financial records typically sits at moderate or high. NIST SP 800-60 gives agencies a methodology for mapping specific information types to impact levels so the categorization isn’t guesswork.⁵

Once impact levels are set, the organization selects controls from NIST SP 800-53 Revision 5. The catalog contains more than a thousand individual controls across 20 families, from Access Control and Incident Response to Supply Chain Risk Management and PII Processing.⁶ The baseline grows substantially as the impact level rises, and enhanced control variants kick in for moderate and high systems.

One family often underestimated is Supply Chain Risk Management. Revision 5 introduced dedicated SR controls that require formal supply chain risk plans, documentation of component provenance, recurring supplier assessments, and anti-counterfeit and tamper-detection measures across the full system lifecycle. For moderate- and high-impact systems, gaps here are a frequent cause of authorization delays.

The Authorization Package

The authorization package is what the Authorizing Official actually reads. Three documents form its core, and one additional policy is required at the agency level.

System Security Plan

The System Security Plan describes what the system does, defines its boundaries, and explains how each selected control is implemented. NIST SP 800-18 frames the SSP as structured documentation of adequate, cost-effective security for a system, including who can access it and how it fits into the agency’s broader environment.⁷ NIST and FedRAMP publish templates, though agencies often use their own variants.

Security Assessment Report

The Security Assessment Report captures the results of an independent evaluation performed under NIST SP 800-53A. The assessor tests each control and records either a “satisfied” or “other than satisfied” finding, along with the methods used, dates, and recommendations.⁸ For moderate- and high-impact systems, assessor independence is required, which protects the evidence base the AO is relying on.

Plan of Action and Milestones

Weaknesses identified during assessment go into the Plan of Action and Milestones. Each entry describes the risk, the remediation steps, the person responsible, and a completion timeline. The POA&M shows the AO that known problems have a path to resolution, and after authorization it becomes the tracking tool for continuous improvement.

Vulnerability Disclosure Policy

Beyond the three core documents, CISA Binding Operational Directive 20-01 requires every federal agency to develop and publish a vulnerability disclosure policy as part of enterprise vulnerability management.⁹ Systems on classified or national security networks are exempt.

Who Signs Off and Who Does the Work

The RMF deliberately separates the person who builds the system from the person who approves it. Four roles carry the process.

The Authorizing Official is a senior official with the authority to formally accept risk to organizational operations, assets, individuals, and the Nation.¹⁰ The AO signs the decision and can revoke it if conditions change.

The System Owner is responsible for the system’s procurement, development, operation, and maintenance. This person develops the SSP with security staff, assembles the full package, submits it to the AO, and ensures users receive required training.¹¹

The System Security Officer runs day-to-day security operations, advises on security matters, monitors the environment, maintains policies and procedures, and manages incident handling.

The Security Control Assessor independently tests the implemented controls, produces the SAR, and delivers findings to both the system owner and the AO.

The Authorization Decision

Once the package is complete, it moves through the agency’s review workflow, often via a GRC platform. The AO and supporting staff read the SSP, SAR, and POA&M and decide whether the risks are acceptable given the system’s mission value. Clarification requests are normal, and every exchange becomes part of the permanent record. Duration depends on system complexity, documentation quality, and the agency’s backlog.

NIST SP 800-37 Rev 2 defines four possible outcomes, not the three that many summaries describe:¹¹

Authorization to Operate: the AO determines risk is acceptable, and the system is approved to operate for a specified period under defined terms. Many agencies set this at three years, though the framework itself doesn’t mandate a universal duration.¹²
Common Control Authorization: the same decision applied to controls shared across multiple systems.
Authorization to Use: issued when an agency adopts a system or cloud service another organization has already authorized, after confirming the security posture works for its own environment.
Denial of Authorization: the AO finds risk unacceptable. The system cannot operate; if already in production, activity halts immediately.¹³

A widely repeated misconception is that agencies can issue an “Interim Authority to Operate.” NIST’s RMF guidance explicitly states that a system cannot be given an interim authorization to operate. What agencies can grant is a short-term authorization with a near-term termination date, which lets a system be tested in an operational environment while controls are still being implemented.¹³ Some agencies use their own labels and cap the duration, but any time-limited approval still requires an explicit risk acceptance by the AO.

A denial is not permanent. The system owner works with the AO to revise the POA&M, correct the deficiencies, and resubmit. The system stays offline until a new decision is rendered.

After the ATO: Monitoring and Reauthorization

An ATO is not a one-time approval. The Monitor step of the RMF requires ongoing tracking of control effectiveness, emerging threats, and environmental changes. NIST SP 800-137 defines this as Information Security Continuous Monitoring: maintaining ongoing awareness of vulnerabilities, threats, and security posture to support risk decisions.¹⁴

OMB Circular A-130 permits agencies to move from periodic reauthorization to ongoing authorization when two conditions are met: the system has an initial ATO, and a mature ISCM program monitors all implemented controls at appropriate frequencies and rigor.² Under ongoing authorization, the ATO doesn’t expire on a fixed date. Instead, events trigger reassessment: a spike in vulnerability findings, a significant system change, new threat intelligence, or a shift in risk assessment results.¹⁵

Ongoing authorization is where the federal government is headed, but many agencies haven’t reached the ISCM maturity to make the switch. For those, the traditional three-year reauthorization cycle remains the default, and reauthorization involves a review similar to the initial one but conducted during operation rather than before deployment.

Cloud Systems and FedRAMP

If the system in question is a cloud service, the path runs through the Federal Risk and Authorization Management Program rather than a single-agency ATO from scratch. FedRAMP was codified by the FedRAMP Authorization Act and exists so a cloud vendor serving ten agencies doesn’t need ten separate assessments.¹⁶

FedRAMP supports two authorization paths. An agency authorization is signed by a sponsoring agency’s AO after a Third-Party Assessment Organization evaluates the cloud service provider. A program authorization is signed by the FedRAMP Director following FedRAMP’s own review.¹⁷ Both paths use NIST SP 800-53 controls with cloud-specific requirements layered on top.

Reciprocity is the point. Once a provider earns a FedRAMP authorization at a given FIPS 199 impact level, the law requires other agencies to presume the assessment is adequate for their use at or below that level. An agency can override that presumption only by showing a need for additional requirements beyond the FedRAMP package, or that the package is substantially deficient for its specific use case.¹⁷

1
Office of the Law Revision Counsel. 44 USC 3554 – Federal Agency Responsibilities
2
The White House. OMB Circular A-130 – Managing Information as a Strategic Resource
3
National Institute of Standards and Technology. NIST SP 800-37 Risk Management Framework Overview
4
National Institute of Standards and Technology. FIPS 199 – Standards for Security Categorization of Federal Information and Information Systems
5
National Institute of Standards and Technology. NIST SP 800-60 Volume II Revision 1 – Guide for Mapping Types of Information and Information Systems to Security Categories
6
National Institute of Standards and Technology. NIST SP 800-53 Rev 5 – Security and Privacy Controls for Information Systems and Organizations
7
Computer Security Resource Center. NIST SP 800-18 Rev 1 – Guide for Developing Security Plans for Federal Information Systems
8
National Institute of Standards and Technology. NIST SP 800-53A Rev 5 – Assessing Security and Privacy Controls in Information Systems and Organizations
9
Cybersecurity and Infrastructure Security Agency. BOD 20-01 – Develop and Publish a Vulnerability Disclosure Policy
10
Cybersecurity and Infrastructure Security Agency. Authorizing Official
11
National Institute of Standards and Technology. NIST SP 800-37 Rev 2 – Risk Management Framework for Information Systems and Organizations
12
CMS Information Security and Privacy Program. Authorization to Operate (ATO)
13
National Institute of Standards and Technology. NIST RMF Authorize Step FAQs
14
National Institute of Standards and Technology. NIST SP 800-137 – Information Security Continuous Monitoring for Federal Information Systems and Organizations
15
National Institute of Standards and Technology. Ongoing Authorization
16
U.S. Congress. H.R. 8956 – FedRAMP Authorization Act
17
FedRAMP. M-24-15 Section IV – The FedRAMP Authorization Process