Category: Authorization & Accreditation

Interim Authority to Test

Also known as: IATT, Interim Authorization to Test, Interim Approval to Test

Simply put

An Interim Authority to Test (IATT) is a temporary permission granted by an authorizing official that lets an organization test an information system in a real operational setting, sometimes with live data, before the system receives a full authorization to operate. It is a short-term, testing-focused authorization and should not be treated as approval for ongoing operational use. Once testing concludes or its conditions expire, the system generally still needs a separate authorization decision before it can operate in production.

Formal definition

An IATT is a temporary authorization issued by an authorizing official (AO), or a principal accrediting authority (PAA) in older DoD terminology, permitting an information system to be tested within a specified operational information environment for a defined timeframe and under stated conditions and constraints. Per available evidence, an IATT is intended to enable testing and evaluation of a system in an operational environment, which may include the use of live data, rather than to authorize routine operational use; applicable security controls are generally expected to be tested during this period. An IATT is distinct from an Authority to Operate (ATO): the IATT authorizes a bounded testing activity, whereas an ATO is the authorization decision permitting operational use of the system. Practitioners should not conflate an IATT with an ATO or with an Interim Approval/Authority to Operate (IATO), and should confirm the specific timeframe, conditions, data-handling constraints, and documentation or test-plan requirements against the governing authorization process and current authoritative sources, as these vary by agency, component (for example, specific DoD Service processes), and the applicable revision of governing guidance. Evidence for scope-specific procedural details in this entry is limited, and implementation, contractual, and legal specifics are out of scope and must be verified against official process documentation.

Why it matters

An Interim Authority to Test matters because it addresses a practical gap in the authorization lifecycle: some systems cannot be fully evaluated in a laboratory or isolated environment and must be tested in a realistic operational setting, sometimes with live data, before an authorizing official can make a confident authorization decision. The IATT provides a bounded, condition-based mechanism for that testing while keeping the activity distinct from routine operational use. Treating it as anything more than a temporary, testing-focused permission is a common and consequential mistake.

The most frequent expert-flagged error is conflating an IATT with an Authority to Operate (ATO). An IATT authorizes a specific testing activity for a defined timeframe and under stated conditions; it is not an authorization to place a system into ongoing production use. When testing concludes or the IATT's conditions expire, the system generally still requires a separate authorization decision before it can operate. Practitioners should also avoid confusing the IATT with an Interim Approval/Authority to Operate (IATO), which is a different concept. Because live data may be involved during IATT testing, the data-handling constraints and conditions attached to the authorization carry real risk-management weight and should be observed precisely.

Equally important, an IATT is not a shortcut around continuous monitoring or a substitute for demonstrating that security controls actually function. Available evidence indicates that applicable security controls are generally expected to be tested during the IATT period, which reinforces that the goal is evaluation and evidence-gathering rather than operational blessing. The specific timeframe, conditions, documentation, and test-plan requirements vary by agency and component and by the applicable revision of governing guidance, so readers should verify the details against their own authorization process rather than assuming a uniform standard.

Who it's relevant to

Authorizing Officials (AOs) and Principal Accrediting Authorities (PAAs)

AOs, or PAAs in older DoD terminology, are the officials who grant an IATT. They define the timeframe, conditions, constraints, and data-handling limits under which testing may occur and are responsible for keeping the IATT distinct from an operational authorization. They should ensure that the temporary nature of the IATT is clearly understood and that a separate authorization decision is made before any move to production use.

Information System Security Managers and Assessment Teams

These practitioners plan and execute the control testing that the IATT is intended to enable. Because applicable security controls are generally expected to be tested during the IATT period, they are responsible for documenting test plans, capturing evidence, and observing any live-data constraints. They should verify the specific documentation and test-plan requirements against their governing process, as these vary by agency and component.

Government Contractors and System Developers

Organizations building or delivering systems that must be evaluated in an operational environment rely on the IATT to conduct that testing before full authorization. They must not treat an IATT as permission to operate the system for production purposes and should confirm the applicable timeframe, conditions, and data-handling constraints, along with any contractual specifics, against official process documentation rather than assuming an IATT satisfies operational authorization requirements.

Auditors and Compliance Officers

Those reviewing authorization decisions need to distinguish an IATT from an ATO and from an IATO when assessing a system's authorization posture. They should verify that testing conducted under an IATT stayed within its stated conditions and timeframe, and that a separate authorization decision was obtained before operational use. Because procedural details differ by agency and revision, they should anchor their review to the governing authorization process.

Inside IATT

Time-Limited Testing Authorization

An IATT is a special, short-duration authorization decision that permits an information system to operate in an operational or representative environment for the specific purpose of testing, rather than for ongoing mission use. As a Risk Management Framework (RMF) authorization decision under DoD implementation, it is inherently time-bound and expires at the end of the defined testing period.

Narrowly Scoped Purpose

The authorization is generally granted for a defined testing objective, such as evaluating system functionality, security controls, or interoperability under conditions that cannot be adequately replicated in a laboratory or development environment. It does not convey authorization for production processing of live mission data.

Authorizing Official (AO) Decision

As with other RMF authorization decisions, an IATT is issued by an Authorizing Official who accepts the residual risk associated with the limited testing activity. Readers should verify current DoD RMF guidance for the specific approval authorities and documentation applicable to their environment.

Conditions and Constraints

An IATT typically carries constraints on the environment, duration, data types permitted, and connectivity, intended to bound the risk of testing. The specific conditions are determined during the authorization process and documented in the authorization decision.

Relationship to Full Authorization

An IATT is distinct from an Authority to Operate (ATO) and from an Interim Authority to Operate (IATO) where such constructs apply. It supports testing activities and does not by itself establish that a system is authorized for operational use; a separate authorization decision is generally required before the system operates in production.

Common questions

Answers to the questions practitioners most commonly ask about IATT.

Is an Interim Authority to Test (IATT) the same as an Authority to Operate (ATO)?

No. An IATT and an ATO are distinct authorization decisions and should not be treated interchangeably. An IATT generally authorizes testing of a system in an operational or representative environment for a limited, specified purpose and period, whereas an ATO authorizes a system to operate and process, store, or transmit real mission data. An IATT is not a substitute for an ATO, does not authorize operational use, and is issued by the authorizing official under the applicable authorization process. Confirm the specific conditions, scope, and duration against the governing authorization documentation and current official guidance.

Does receiving an IATT mean my system has satisfied its security requirements and can be considered compliant?

Not necessarily. An IATT authorizes testing under defined conditions and limitations; it does not by itself indicate that the system has met all security or compliance requirements needed for operation. Assessment and authorization are separate activities, and an IATT reflects a risk decision to permit testing rather than a determination that the system is fully secure or compliant. The system must still complete the applicable authorization process to obtain an ATO before operational use. Verify the specific expectations against the current authoritative process documentation.

What conditions or limitations are typically attached to an IATT?

IATTs are generally issued with specific conditions that constrain the testing activity, which may include the permitted scope of testing, the environment in which testing may occur, restrictions on the use of live or production data, a defined time period, and required safeguards. The exact conditions are set by the authorizing official and documented in the authorization decision. Because these terms are situation-specific and can vary by organization and system, confirm the applicable conditions in the governing authorization documentation rather than assuming a standard set.

How long does an IATT remain valid?

An IATT is time-bound and issued for a limited period tied to the testing purpose, rather than being open-ended. When the specified period ends or the testing objectives are met, the authorization to test generally concludes. The precise duration and any provisions for extension are determined by the authorizing official and stated in the authorization decision. Verify the effective and expiration dates against the current authorization documentation for your system.

Can operational or live mission data be used under an IATT?

Use of live or operational data under an IATT depends on the specific conditions the authorizing official establishes. In many implementations, IATTs are oriented toward testing rather than operational data processing, and restrictions on the type of data permitted are common. Because handling requirements can vary based on the data involved and the system's environment, confirm what data may be used under the IATT in the governing authorization documentation and applicable guidance before proceeding.

What steps generally follow the conclusion of an IATT?

After the testing authorized under an IATT concludes, the system generally proceeds through the applicable assessment and authorization process to seek an operational authorization decision such as an ATO. The IATT itself does not transition automatically into operational authority. The specific next steps, required artifacts, and decision points are defined by the governing authorization process and the authorizing official, so confirm them against current official process documentation for your environment.

Common misconceptions

An IATT is the same as an ATO and permits the system to go into operational use.

An IATT authorizes testing for a limited time and purpose only. It is not an operational authorization; a separate ATO decision is generally required before the system may process live mission data or operate in production.

An IATT lasts indefinitely or can simply be extended to keep testing going.

An IATT is time-bound by design and expires at the end of the defined testing period. Continued testing beyond that period generally requires a new authorization decision, and readers should confirm current DoD RMF procedures for renewals.

Receiving an IATT means the system has passed its security assessment and is compliant.

An IATT reflects an Authorizing Official's acceptance of risk for a bounded testing activity, not a determination that the system is secure or fully compliant. Assessment and authorization are distinct steps, and completing testing does not equate to completed authorization.

Best practices

Define the testing scope, duration, permitted data types, and environmental constraints explicitly before requesting an IATT, and ensure they are reflected in the authorization decision.

Coordinate early with the Authorizing Official to confirm what residual risk is being accepted and under what conditions, treating the IATT as a bounded risk-acceptance decision rather than an operational approval.

Track the IATT expiration date and plan the transition to a full authorization decision well in advance, since the IATT does not permit continued operation once it lapses.

Avoid processing live or production mission data under an IATT unless the authorization decision explicitly permits it, and confirm any data-handling limitations against the current authorization terms.

Verify the applicable authorities, documentation requirements, and procedures against current DoD RMF guidance, because authorization constructs and terminology can change across revisions and agency tailoring.

Keep assessment and authorization activities distinct in planning, and do not treat successful testing under an IATT as evidence of a completed authorization or of overall system security.