From IATT to ATO: Getting a System Authorized Without Delays

Few things frustrate a program office more than a finished system that cannot go live because it is not authorized. The authorization to operate (ATO) is the gate between a system that works and a system that can be used on the mission, and it routinely becomes the long pole in a schedule.

It does not have to. Authorization delays are rarely mysterious. They come from a small number of predictable causes, and each one has a remedy.

The decisions along the way

Under DoD Instruction 8510.01, which applies the Risk Management Framework to Department of War systems, the authorizing official (AO) can make several kinds of decisions:

• Interim authorization to test (IATT): permission to test the system in an operational environment, or with live data, for a defined period and purpose.
• Authorization to operate (ATO): the AO accepts the residual risk and the system may operate, typically with a termination date or under continuous monitoring.
• ATO with conditions: the system may operate, but specific conditions must be met, such as closing named weaknesses by a date.
• Denial of authorization: the risk is not acceptable, and the system may not operate.

Using an IATT well

An IATT exists because some testing can only happen in a realistic environment: integration with production networks, operational test events, or performance under real load. It is useful, but it is not a partial ATO. To get one approved and keep it useful:

• Define exactly what will be tested, where, for how long and with what data.
• Show that testing risk is contained, such as through segmentation, limited users and monitoring.
• Implement the core security controls first, especially account management, logging and hardening.
• Use the test period to generate evidence for the eventual ATO, not only functional test results.

Why authorizations stall

1. Security joins too late

When security requirements arrive after the architecture is fixed, every finding becomes a redesign. Bring the information system security manager and engineers into requirements and design reviews, and build to the control baseline from the start.

2. The boundary is unclear

If the program, the assessor and the AO disagree about what is in the system, including interconnections, shared services and cloud components, work stalls while it is resolved. Settle the boundary early and document it with diagrams everyone signs off on.

3. Documents describe a different system

System Security Plans often describe the design as intended, not the system as built. Assessors test the system, find differences, and the package goes back for rework. Keep documentation aligned with configuration management.

4. The first real test is the formal assessment

If no one has run the scans, reviewed the STIG checklists or tried the controls before the assessor arrives, the assessment becomes the discovery phase. Run an internal validation first, fix what it finds, and walk into the assessment with evidence ready.

5. POA&Ms are not credible

An AO can accept risk when there is a believable plan to reduce it. POA&M items with vague fixes, no owners and past-due dates make that hard. Write specific items with realistic milestones.

6. Inheritance is assumed, not documented

Controls inherited from a hosting environment or enterprise service need documented agreements and evidence. Confirm them early, and understand exactly what remains your responsibility.

Accelerating responsibly

Programs looking to shorten the path should focus on reuse and automation rather than shortcuts:

• Reuse authorized components and inherit from accredited platforms and enterprise services.
• Standardize baselines so hardening is applied the same way every time.
• Automate evidence, such as scans, configuration checks and compliance reports, so it is always current.
• Adopt continuous monitoring early, which supports ongoing authorization after the ATO.

When conditions are the right answer

An ATO with conditions is not a failure. It lets a needed capability operate while specific risks are addressed. The key is that the conditions are realistic and tracked. If a program cannot meet its conditions, it should raise the issue with the AO before the date passes, not after.

A realistic schedule

Every program differs, but authorization milestones usually follow the system's development. A simplified example for a new system:

• At concept and requirements: register the system, agree on the boundary and categorization, and identify inheritable controls.
• During design: select and tailor controls, and design them into the architecture: identity, logging, segmentation, hardening.
• During build: implement controls, apply STIG baselines, and write the System Security Plan as the system takes shape.
• Before operational test: request an IATT if testing needs an operational environment, with its limits clearly defined.
• Internal validation: scan, check STIGs, test controls and fix what fails, before the formal assessment.
• Formal assessment: the assessor tests and documents results; the team responds quickly to requests.
• Authorization: the package goes to the AO with an honest risk picture and credible POA&Ms.

Programs that follow this sequence tend to experience authorization as a series of small steps. Programs that skip the early steps tend to experience it as a wall at the end.

Questions to ask at every program review

• Is the boundary agreed and documented, including interconnections and cloud services?
• Which controls are we inheriting, and do we have the agreements and evidence?
• When did we last scan and check STIGs, and what did we find?
• Is the System Security Plan current with the as-built system?
• What would we tell the AO about residual risk today?

How CDT can help

CDT prepares systems and packages for authorization, runs internal validations before formal assessments, and hardens systems to the required baselines, through our RMF, A&A and ATO, system hardening and classified solutions services.

Sources

• DoD Instruction 8510.01, Risk Management Framework for DoD Systems
• NIST SP 800-37 Rev. 2, Risk Management Framework