​Overview of Authorization to Operate (ATO)

When you pursue authorization, you are fundamentally presenting a structured argument about risk backed by technical and procedural evidence. In practice, many Authorizing Officials (AOs) frame authorization not as “Is this system perfectly secure?” but rather as “Do we understand the risks well enough to consciously accept them for this mission?” Authorization comes in several different forms, including the following:

​

• ATO (Authorization to Operate). The standard, full-scope operational authorization. This article focuses on this path.

• cATO (Continuous ATO). A sustained form of ATO based on continuous monitoring and automated evidence. You must first obtain a traditional ATO; the cATO model governs how that authorization is maintained over time.

• IATT (Interim Authorization to Test). A limited-scope, time-boxed authorization to conduct testing in a controlled environment. In systems with Medium or High System Security Classification, IATT can often require ~70–85% of the total initial ATO labor.

• Provisional ATOs, Risk Acceptances, and others may apply in certain cloud or mission-specific contexts.

​

The taskflow diagram below summarizes our experience with the technical work required to prepare a system for ATO. Its purpose is not to enumerate every possible artifact or approval path, but to make the scope intelligible to software engineering teams: What categories of work exist, how they relate, and where engineering time is typically spent. The task IDs shown in the diagram (for example, BASE-1 or CONT-1) are used as references in later sections of this guide. To view this taskflow in table form, see Appendix A – ATO Preparation Task List.