Authority to Operate (ATO)

An Authority to Operate (ATO) is a senior official's formal decision to accept the security risk of running an information system, reached through the Risk Management Framework in NIST SP 800-37. Federal systems need one before processing live data, and keeping one is continuous work.

FISMA (44 U.S.C. 3554) makes agency heads responsible for security protections commensurate with risk, and the Risk Management Framework in NIST SP 800-37 Revision 2 turns that duty into an operating decision. Revision 2 (December 2018) added a Prepare step ahead of the cycle practitioners know: categorize the system, select and implement controls, assess them, authorize, monitor.

DoD runs the framework under DoDI 8510.01 (July 2022). The authorizing official is a senior government official who cannot delegate the decision itself, and the outcomes are an ATO, an ATO with conditions, an interim authorization to test, or denial. The instruction also directs reciprocity, so one component's authorization evidence carries to another instead of being reassessed from scratch.

An ATO is not a diploma. It rests on continuous monitoring, and the authorizing official can downgrade or revoke it whenever risk warrants. For program offices, assess-and-authorize is the schedule item that swallows fielding plans; a vendor that defers the authorization package until delivery produces a system that is finished and unusable.

Regulatory Reference

44 U.S.C. 3554; NIST SP 800-37 Rev. 2; DoDI 8510.01

RFO Status

System authorization lives in FISMA, OMB policy, and NIST and DoD issuances rather than the FAR, so the overhaul does not reach it; the June 2026 proposed rule (FAR Case 2026-001) consolidates the FAR's information-security clauses into Part 40 without touching the ATO process.

Category

Processes & Methods

How AcqBot Helps

AcqBot surfaces authorization requirements at requirements-definition time: whether the system will need an ATO, whose authorizing official owns the decision, and what evidence the solicitation should demand, so the authorization timeline lands in the schedule instead of after award.