DoD Impact Levels (IL2, IL4, IL5, IL6) Explained

What an impact level actually is

People say a system "is IL5" the way they might say a car is a sedan. The term is narrower than that shorthand, and more useful.

The DoD Cloud Computing Security Requirements Guide — the CC SRG, issued by the Defense Information Systems Agency — defines the levels this way in Section 3 of version 1, release 3: "Cloud security information impact levels are defined by the combination of: 1) the sensitivity or confidentiality level of information (e.g., public, private, classified, etc.) to be stored and processed in the CSP environment; and 2) the potential impact of an event that results in the loss of confidentiality, integrity, or availability of that information."

Two ingredients, then: how sensitive the data is, and how bad it would be to lose control of it. The SRG directs mission owners to categorize their system first, under DoDI 8510.01 and CNSSI 1253, and then "identify the Cloud Information Impact level that most closely aligns with the defined categorization." The severity words behind those categorizations come from NIST FIPS 199, which grades a loss of confidentiality or integrity as having a limited, serious, or severe adverse effect.

So an impact level starts as a property of the information and becomes a property of the environment allowed to hold it. That order is the thing most often gotten backwards.

The four levels, one at a time

IL2 — non-controlled unclassified information. Per SRG Section 3.2.2, Level 2 "includes all data cleared for public release... as well as some low confidentiality unclassified information NOT designated as Controlled Unclassified Information (CUI) or critical military/contingency operations mission data, but the information requires some minimal level of access control (e.g., user ID and password)." Access to an IL2 cloud service offering is via the Internet. A public-facing information site, a training catalog, an open dataset published for reuse: IL2 territory.

IL4 — Controlled Unclassified Information. Section 3.2.4 states that Level 4 "accommodates CUI and/or other mission critical data to include that used in direct support of military or contingency operations." CUI itself is defined by Executive Order 13556 and 32 CFR Part 2002; the categories are enumerated in the National Archives CUI Registry and include export-controlled information, privacy and health information, law enforcement material, and critical infrastructure information. A great deal of ordinary defense contractor work lands here.

IL5 — CUI needing more protection, and unclassified National Security Systems. Section 3.2.5 says Level 5 "accommodates CUI that may require a higher level of protection than that afforded by Level 4 as deemed necessary by the information owner, public law, or other government regulation," and that the call belongs to the Authorizing Official. Then comes the clause that surprises people: "Level 5 also supports unclassified National Security Systems (NSSs)... As such, NSS must be implemented at Level 5." An unclassified system can be pushed to IL5 not because its data got more sensitive but because of what the system is. NIST SP 800-59 supplies the NSS definition — intelligence activities, cryptologic activities related to national security, command and control of military forces, equipment integral to a weapons system, or functions critical to the direct fulfillment of military or intelligence missions.

IL6 — classified information up to SECRET. Section 3.2.6 limits Level 6 to information classified SECRET or below. Because the entire cloud infrastructure must be dedicated and separate from other providers' infrastructure, the SRG notes that IL6 offerings "may only be provided by CSPs under contract to the DoD or a Federal Agency," and that "access to the CSO is via one or more private SIPRNet connections." Microsoft's Azure compliance documentation, summarizing Section 5.2.2.4 of the SRG, describes an IL6 environment as a SIPRNet enclave: "a closed self-contained environment for the cloud service offering (CSO) processing, storage, and management planes connected only to SIPRNet."

Why there is no IL1 or IL3

New readers usually notice the gap before anything else. The answer is in SRG Section 3.2: the superseded DoD Cloud Security Model defined six levels, and "in order to simplify the selection process, the number of levels was reduced from 6 to 4. This was accomplished by integrating levels 1 (public information) and 3 (low impact CUI) into levels 2 and 4, respectively." The numbers were left alone so that older documents would still make sense.

One more line from that section is worth memorizing, because it settles a lot of arguments: "a higher level can process data from a lower level." IL4 data is fine in an IL5 environment. The reverse is not true, and no amount of scheduling pressure changes it.

Why the level decides where a workload may run

Here is the part that turns a classification exercise into an engineering constraint. Three separate mechanisms attach to the level.

The network path. The SRG cites the 15 December 2014 DoD CIO memo, which states that "Commercial cloud services used for Sensitive Data must be connected to customers through a Cloud Access Point (CAP)" — and for SRG purposes, Sensitive Data means CUI at Levels 4 and 5 or classified information up to SECRET at Level 6. A CAP is described as "a system of network boundary protection and monitoring devices (e.g., firewall, IPS, IDS, proxy, etc.)" standing between the provider's infrastructure and the DoD network. DISA's DISN Connection Process Guide repeats the requirement and adds that all CAPs must be approved by DoD CIO. IL2 reaches users over the Internet; IL4 and IL5 reach NIPRNet-based components through DoD-provided, DoD CIO-approved boundaries; IL6 runs on private SIPRNet connections.

Tenant separation. Summarizing SRG Section 5.2.2.3, Microsoft's IL5 documentation states that virtual or logical separation between DoD and federal government tenants is sufficient at IL5, while "physical separation from non-DoD/non-federal government tenants... is required." At IL6 the infrastructure must be dedicated and sited in facilities approved for processing classified information.

Who may operate it. The same documentation notes that Section 5.6.2 of the SRG restricts cloud provider personnel with access to IL4 and IL5 data to U.S. citizens, U.S. nationals, or U.S. persons, with further restrictions at IL6.

The practical consequence for anyone building software: the level fixes your network egress before you write a line of code. A tool that quietly assumes it can call a commercial API over the public Internet works beautifully at IL2, becomes a negotiation at IL4 and IL5, and cannot exist at IL6 at all. That is an architecture decision, and it is cheap to make early and expensive to retrofit — the connectivity and separation choices are better settled against the SRG than discovered during accreditation.

Provisional authorization is not an ATO

Section 2.6 of the SRG defines a DoD Provisional Authorization as "an acknowledgement of risk based on an evaluation of the CSP's CSO and the potential for risk introduced to DoD networks," following the same do-once-use-many logic as FedRAMP. Crucially, "a DoD PA is granted to the CSP for a CSO, not the CSP itself." Section 4 adds that the PA and its supporting documentation "must then be leveraged by the Mission Owner's Authorization Official in granting the required ATO for the mission system operating within the cloud."

Two things follow. First, a cloud platform holding an IL5 PA does not make your application authorized — your own Authorizing Official issues the ATO for your system. Second, when a vendor says their software "is IL5 certified," the precise question to ask is: is the offering provisionally authorized at that level, and who is issuing the ATO for the system you would actually be fielding? The two answers usually come from different organizations.

On baselines, the 2014 DoD CIO memo established that "FedRAMP will serve as the minimum security baseline for all DoD cloud services." Microsoft's summary of SRG Section 5.1.1 describes the practical mapping: full reciprocity with a FedRAMP Moderate or High authorization at IL2; acceptance of a FedRAMP High authorization at IL4 without an additional control-enhancement assessment, though other SRG requirements are still assessed; and FedRAMP High supplemented with DoD FedRAMP+ controls at IL5 and IL6.

Which version of the SRG to read

An honest caveat about sourcing. The definitional quotations above are from CC SRG version 1, release 3, dated 6 March 2017, because it is a complete copy that is publicly posted and easy for a reader to check. DISA has since revised the guidance — aligning it to NIST SP 800-53 Revision 5, adding CNSSI 1253 Appendix D overlay requirements at the higher levels, and retiring v1r4 in favor of separate Cloud Service Provider and Mission Owner guides.

The four levels carry over into the new guides. Control baselines, separation language, and the specific FedRAMP path required at IL5 do not carry over unchanged. Before you rely on a specific control, parameter, or baseline, pull the current release from the DoD Cyber Exchange rather than any summary, including this one. Providers publish their own status too: AWS and Microsoft both list which regions hold which DoD provisional authorizations.

How we use this, and what we will not do

Precision Federal builds small AI models that read through a body of records and produce a written conclusion, with every statement traced back to the exact record it came from. We mention it here only because the impact level shapes that design directly: a model small enough to run inside a closed enclave, with citations an assessor can spot-check, survives a move up the levels in a way that an architecture depending on an outbound call to a commercial API does not. We treat the accreditation boundary as an input to the design, not a review to clear afterward.

Some limits worth stating plainly, because they are the kind of thing that is better said before an engagement than during one:

• We will not tell you a piece of software "is IL5." Offerings hold provisional authorizations; systems get ATOs from their own Authorizing Official. We will not blur the two, and we do not issue, hold, or broker ATOs.
• We are not a cleared facility and we do not operate classified environments. At IL6 the enclave, the facility, and the cleared staff belong to the customer or their provider; our contribution is code and documentation delivered into it.
• We will not build at IL2 and promise a painless lift to IL5 or IL6 later without naming what the lift costs — which is almost always the model-hosting decision and every outbound network call.
• We will tell you when a workload does not need the level being asked for. Pushing IL4-appropriate data into an IL5 environment buys cost and friction, not safety.

If the level is genuinely undecided, the useful first move is not a vendor conversation. It is a categorization conversation with your Authorizing Official under DoDI 8510.01 and CNSSI 1253, because everything downstream — network, separation, personnel, hosting — follows from that answer.

Sources: DoD Cloud Computing Security Requirements Guide, v1r3 (DISA, 6 March 2017), Sections 2.6, 3, 3.2, 4 and 5.10.1; DoD Cyber Exchange — Cloud Computing Security; Microsoft Learn — DoD Impact Level 2, Impact Level 4, Impact Level 5 and Impact Level 6, summarizing SRG Sections 5.1.1, 5.2.2.3, 5.2.2.4 and 5.6.2; DISA — DISN Connection Process Guide; NIST FIPS 199; NIST SP 800-59; National Archives CUI Registry; Schellman on the DoD CSP SRG and MO SRG. Analysis and framing by Precision AI Academy.

Common questions

What are DoD impact levels? Information Impact Levels are the categories the DoD Cloud Computing SRG, issued by DISA, uses to match information to a cloud environment. The SRG defines a level by the sensitivity of the information plus the potential impact if its confidentiality or integrity were lost. Four levels are in use: IL2, IL4, IL5 and IL6.

Why is there no IL1 or IL3? The superseded DoD Cloud Security Model defined six levels. Per Section 3.2 of the SRG, the number was reduced from six to four by integrating Level 1 (public information) into Level 2 and Level 3 (low-impact CUI) into Level 4. The original numbering was kept for consistency, leaving IL2, IL4, IL5 and IL6.

What is the difference between IL4 and IL5? Both hold Controlled Unclassified Information. Per the SRG, IL5 accommodates CUI that requires a higher level of protection than IL4 as deemed necessary by the information owner, public law or other government regulation, with the determination left to the Authorizing Official. IL5 also supports unclassified National Security Systems, and the SRG states that NSS must be implemented at Level 5.

Does an IL5 provisional authorization mean my application is authorized? No. Per Section 2.6 of the SRG, a DoD Provisional Authorization is an acknowledgement of risk granted to a cloud service offering, not to the mission system running on it. Section 4 states that the PA must then be leveraged by the mission owner's Authorization Official in granting the required ATO for the mission system operating within that cloud.