Your Application Does Not Have an Impact Level

"We're IL5."

Vendors say this in capability briefings, and there are three separate things wrong with the sentence. It implies a ladder that does not exist, it describes a category that changed materially in 2025, and it claims a property that belongs to somebody else's product rather than to yours.

Impact levels are the third vocabulary in this series, and they are the one people most often think they already understand.

The numbers are not a ladder

Three observations.

IL1 and IL3 do not exist, and were already retired in the first release. The original Cloud Computing SRG — Version 1 Release 1 of 12 January 2015, carried unchanged into Release 2 of March 2016 — kept both as numbered headings with a single sentence under each: "Level 1 is no longer used and has been merged with Level 2," and "Level 3 is no longer used and has been merged with Level 4." The numbering stayed. So the gaps are not missing documentation; they are tombstones that were there from the start. If you have ever gone looking for IL3, that is why you did not find it.

That same 2015 release gave Levels 3, 4 and 5 the identical title — "Controlled Unclassified Information" — which tells you how little the numbers were ever meant to describe on their own.

Three of the four levels are unclassified. IL2, IL4 and IL5 all handle unclassified information. Only IL6 is classified. So the number does not track classification, and moving from IL4 to IL5 is not a step up in classification — it is a step into a different regulatory category. This is the single most misleading thing about the numbering.

The ladder stops at Secret. IL6 is the top, and the SRG says so directly: "At this time, only information classified as SECRET or below, in accordance with the applicable executive orders, is permitted to be hosted at this Impact Level." There is no IL7, and no impact level for Top Secret or compartmented information.

That does not mean Top Secret cloud does not exist — it does, and the SRG quotes the 2023 Joint Warfighting Cloud Capability memo directing components to JWCC for new cloud "at the Secret (Impact Level 6) or Top Secret." Read that phrasing closely: Secret gets an impact level in parentheses and Top Secret does not. The capability is real; the vocabulary simply stops. If you learned this framework doing unclassified DoD cloud work and assumed it continued upward, that assumption is where a schedule breaks — and it is why the question that started this series gets asked at all.

IL5 changed in July 2025, and it matters

This is the part worth checking your assumptions against, because most people learned the old version.

IL5 used to cover higher-sensitivity CUI and non-national-security systems. The change is in the Cloud Service Provider SRG, Version 1 Release 3, dated 02 July 2025 — part of a family of documents, one for cloud service providers and others for mission owners, that replaced the single Cloud Computing SRG in June 2024. Its revision history records the change in one sentence: IL5 "now accommodates Unclassified National Security System/National Security Information with CUI no longer part of this Impact Level."

The section heading changed to match. In V1R2, section 3.7.3 read "Impact Level 5: Controlled Unclassified Information and Unclassified National Security System." In V1R3 it reads "Impact Level 5: Unclassified National Security System/National Security Information." CUI came out of the title and out of the categorization sentence — reversing a definition a decade old, since the 2015 original titled Level 5 simply "Controlled Unclassified Information." Most controlled unclassified information now belongs at IL4 — which the same revision widened to address both moderate and high categorizations.

One caveat if you go and read it yourself, because it will confuse you otherwise: the body of that section has not caught up. The sentence saying IL5 "includes CUI and/or other mission data that may require a higher level of protection than that afforded by Impact Level 4" survives into V1R3 unchanged. So the revision history and the heading say CUI is out, and a paragraph inside the same section still says it is in. Read the revision history as the intent, and expect to meet people quoting the stale sentence.

The consequence for providers was not cosmetic. By the SRG's own Table 3-1, an IL5 assessment runs against the FedRAMP High baseline plus CNSSI 1253 overlays and the Appendix D NSS controls, at high confidentiality and high integrity. The SRG does not count them; one analysis puts the delta at roughly 170 additional controls, about a 40% increase.

If your mental model, a briefing deck, or a competitor's marketing predates July 2025, your understanding of what IL5 means and what it costs is out of date. And check version numbers carefully, because the documents are part of the problem. The release numbers restarted at Version 1 Release 1 when the replacement documents were issued in June 2024 — the revision history records one of them as an "Initial Release. Replaces Cloud Computing SRG" — so a release number from before that date and one from after it refer to different documents. Within the current one, the V1R3 PDF's title page says V1R3, 02 July 2025, while more than a hundred of its page headers still say V1R2, 30 January 2025.

IL4 vs IL5 vs IL6, side by side

Search for the difference between the levels and you mostly find definitions. What changes in practice is the assessment baseline, who is allowed to host the workload, and the network the customer reaches it from. Here is what the SRG requires for each.

IL4 vs IL5

Start with what does not differ in wording. The SRG describes the information at IL4 and IL5 alike as information where disclosure "could be expected to have a serious adverse effect." What changes is the category, and the gate into it is whether the system is a national security system.

Three requirements follow from that gate.

The baseline. IL4 accommodates systems categorized at moderate or high confidentiality and integrity, and an IL4 authorization can rest on FedRAMP Moderate or High. IL5 requires high confidentiality and integrity, starts from FedRAMP High, and adds the NSS controls, the additional controls described earlier in this post.

The tenancy. IL4 can be offered on any deployment model, provided the provider shows strong virtual separation. For IL5 the SRG limits eligibility to "federal government community or DOD private clouds" and requires "physical separation from non-DOD/nonfederal government tenants." Logical separation is enough between DoD and federal tenants, but not from the public. Put plainly, an ordinary shared public-cloud tenancy can meet IL4's tenancy rule and cannot meet IL5's.

The caveat. The IL5 separation section carries a note in the current release that it is "under review for updating based on CNSSP-32." Treat those rules as moving.

So if your data is CUI and the system is not an NSS, IL4 is the level, and the pool of providers is much larger. Asking for IL5 as a precaution shrinks the market and adds cost, which the next sections come back to. The mission-owner guidance allows it, noting a mission owner "may choose a higher level to process data from a lower level of information," but adds that "DISA recommends organizations select cloud services based on appropriate risk levels."

IL5 vs IL6

IL5 to IL6 is a bigger jump than the numbering suggests, because it is not a stronger version of the same environment. It is a different one.

It is a different network. IL4 and IL5 serve customers on unclassified networks, chiefly NIPRNet-based DoD components. IL6 is reached "via one or more private SIPRNet connections or approved CNSSP-11 circuits." That is the move from the unclassified transport service to the Secret one that the first post in this series described.

It is a different kind of infrastructure. IL6 information must be stored and processed "in a dedicated cloud infrastructure located in facilities approved for the processing of classified information," and the offering is "a SECRET enclave" that is "a closed self-contained environment." IL5 only requires physical separation from non-government tenants.

It is not commercially available. Because the entire infrastructure must be dedicated, IL6 offerings "may only be provided by CSPs under contract to the DOD or another federal department or agency." The SRG says directly that in this sense the offering "is not considered 'commercially available.'" At IL4 commercial offerings exist and the SRG describes their customers.

For a vendor, a customer who says IL6 is telling you the work is classified, handled by a different provider pool, on a different network, with cleared people. A customer who says IL5 is telling you the system is a national security system, but the work is still unclassified. Those are different conversations, and the first question in each is the classification and compartmentation of the data.

So is it actually a national security system?

Since July 2025 this is the question that decides IL4 or IL5, and it is a statutory test rather than a judgment about how important the work feels. 44 U.S.C. § 3552(b)(6) defines a national security system as any information system "used or operated by an agency or by a contractor of an agency" whose function, operation or use:

• involves intelligence activities;
• involves cryptologic activities related to national security;
• involves command and control of military forces;
• involves equipment that is an integral part of a weapon or weapons system; or
• is critical to the direct fulfillment of military or intelligence missions

— or which is protected at all times by procedures for information classified under an Executive order or an Act of Congress.

There is also a carve-out, and note that it attaches to exactly one of those prongs. Subparagraph (B) says that the "critical to the direct fulfillment" prong "does not include a system that is to be used for routine administrative and business applications (including payroll, finance, logistics, and personnel management applications)." The other four prongs have no such exclusion.

Read the list closely and the test is narrower than the phrase "national security" suggests. Two words carry most of the weight: integral, in the weapon system prong, and direct, in the mission prong.

The determination people get wrong

Modeling and simulation is where I see this go wrong most often, and it goes wrong in the expensive direction.

A program has M&S data and processing that supports a weapon system. The data is plainly sensitive. The reasoning runs: this supports a military mission, so it is critical to a military mission, so it is a national security system, so we need IL5.

Usually it is not, and the statute is why. An M&S environment that analyzes a weapon system is not equipment that is an integral part of that weapon system — it sits beside the program, not inside the NSS platform. And informing an engineering or acquisition decision is support to a mission, not direct fulfillment of one. The data may well be controlled unclassified, and it may well be export-controlled. Both are real obligations. Neither one makes the system an NSS.

What that mistake costs, in the direction people think is the safe one: roughly 170 additional controls; a much narrower market, because the SRG makes "only federal government community or DOD private clouds" eligible for IL5 and requires physical separation from non-government tenants; and a longer road to authorization — all to satisfy a requirement that was never there. Caution is not free here, and at IL5 it is expensive.

The clearer cases on the other side are worth knowing too. A system sitting in the command and control path of military forces is an NSS. A processing chain embedded in a weapon system is an NSS. A system supporting intelligence activities is an NSS under the first prong. And anything holding classified information qualifies automatically under the final clause, without needing any of the first five to apply — which is why an IL6 system never has to argue about this.

A practical note on who decides, because "ask the government" is not specific enough to be useful. The SRG names three roles.

The mission owner does the categorization. "DOD Mission Owners must categorize mission information systems in accordance with DODI 8510.01 and CNSSI 1253 and then identify the Cloud Information Impact Level that most closely aligns with the defined categorization and information sensitivity."

An authorizing official is accountable for it. The IL5 section puts the determination with "the AO responsible for categorizing the information and choosing the Cloud Impact Level." That sentence sits in the same paragraph as the stale CUI sentence above, so read it for who it names rather than for what it says belongs at IL5.

The information owner sets the requirement upstream. In NIST's definition, that is the official with statutory or operational authority for the specified information, and responsibility for establishing the controls for its generation, classification, collection, processing, dissemination and disposal. The SRG names the information owner, alongside public law and government regulation, as a source of the need for protection above IL4.

So the sequence is: the information owner establishes what the information requires; the mission owner categorizes the system under DoDI 8510.01 and CNSSI 1253; an AO is accountable for that categorization and the impact level chosen from it.

The failure mode is not a wrong answer. It is a remark standing in for that sequence. A vendor asks whether the system is a national security system, a program manager or an engineer says yes — this is national security work, so IL5 — everyone proceeds on it, and no documented categorization ever happened. That assumption then moves your control count by roughly 40%.

So do not assert it in either direction, and do not accept it as a remark. Ask for the categorization: who performed it, on which prong, on whose information, and which AO accepted it — in writing.

When the data has more than one owner

The advice above assumes there is one information owner to ask. Often there is not, and this is where it gets genuinely hard — particularly for the M&S case, and for any platform that exists precisely to bring data together.

Two rules govern what happens, and they pull in the same direction.

There is no such thing as a partly-NSS system. The statutory test asks about the function, operation or use of the system. If any part of it meets a prong, the system is a national security system. The determination does not apportion, and it does not average. So a single contributing information owner whose data pulls the system into a prong takes the entire system with it, along with every other owner's data and every tenant on it.

Impact follows the same logic. FIPS 199 states that the impact values assigned "shall be the highest values (i.e., high water mark) from among those security categories that have been determined for each type of information resident on the information system." Highest wins, per objective. National security systems categorize under CNSSI 1253, which is precise about how far it follows that. It "does not adopt the high-water mark (HWM) concept from FIPS 200" — the step that collapses a system to one overall rating — but it does take the high water mark for each objective, which "results in three distinct high water marks, one for each security objective," written as a trigraph such as M-M-H. So for an NSS the principle holds one objective at a time: the most restrictive contributor sets the floor for everyone.

A warning about vocabulary, because two meanings collide right here. FIPS 199 and CNSSI 1253 use impact level for the Low, Moderate or High value on each objective — CNSSI 1253's own step is titled "Determine Impact Levels for the System." That is not the IL2 to IL6 scale this post is about, and the SRG is blunt about the difference: "Impact Levels are a DOD construct only." An M-M-H system is not "IL-anything." When someone says impact level, find out which one they mean.

There is a third problem with no clean rule at all. Nobody owns the aggregate. Each information owner holds authority over their own information. No one holds authority over the combination — and combinations can be more sensitive than their parts, which is the whole reason co-mingling rules exist. Until someone convenes the owners and a decision gets recorded, that question is authority-less, and it will surface at the worst moment.

Which qualifies the M&S conclusion above rather than overturning it. A single-program M&S environment is often IL4, correctly. A multi-program environment that aggregates across programs may genuinely be IL5 — not because the analysis changed, but because one contributor's data made it so. This is the same dynamic that leaves enterprise data platforms unused: the aggregate carries the strictest requirement any contributor brings, and the cost of connecting rises to meet it.

So for a multi-owner system, the artifact to build first is a list: every information type, its owner, and that owner's determination. Then find out who is empowered to rule on the combination. Both are cheaper now than after a categorization has been briefed.

The level belongs to the cloud service, not to your application

Here is the claim in "we're IL5" that is most consistently wrong, and it matters because it hides the question that actually determines your workload.

An impact level is carried by a Provisional Authorization, and the DoD cloud authorization process is explicit about who gets one: the PA "is issued by the DISA Authorizing Official (AO) for a CSO" — a Cloud Service Offering — "based on FedRAMP and additional DoD security requirements (Impact Levels 4/5/6)." It is granted to a cloud service provider for their product, sponsored by a DoD mission owner, and it is issued with an expiration date to be leveraged by mission owners.

You are a mission owner. You do not receive a PA. You receive an authorization for your own system, and you inherit from the cloud service offering's PA.

So the accurate version of "we're IL5" is: our software runs on a cloud service offering that holds an IL5 provisional authorization, and we inherit its controls. That sentence is longer, and it immediately raises the question the short version conceals — which controls do you inherit, and which remain yours? That is the subject of the next and final post in this series, and it is where the cost is.

Maintaining a PA is also ongoing work for the provider, not a one-time event: continuous monitoring with 30, 90 and 180-day vulnerability resolution requirements, monthly scan reporting, and annual assessments. A PA can be revoked, and if the offering you depend on loses its authorization, that is your problem too.

FedRAMP gets you further than you think, and less far than you hope

The relationship between FedRAMP and DoD impact levels is asymmetric, which trips up commercial teams who have already done the FedRAMP work.

At IL2, reciprocity is close to automatic. The SRG says that "any CSP/CSO compliant at the FedRAMP Moderate or High level may be used at DOD Impact Level 2 without a written DOD PA," and calls that compliance "equivalent/essentially an automatic DOD Impact Level 2 PA."

At IL4 and above, it does not. DoD reuses the FedRAMP documentation and artifacts, but the additional FedRAMP+ requirements are assessed by an accredited third-party assessor, DISA's assessors prepare a risk determination, and the DISA AO issues a separate PA. IL4's baseline can be FedRAMP Moderate or High, so the problem with "we have FedRAMP Moderate, so we're IL4" is not the baseline — it is everything DoD adds on top, and the PA that does not yet exist.

There is also an infrastructure cost nobody mentions in briefings: IL4 and IL5 cloud service offerings must obtain, sustain and fund a connection between the provider's enclave and DISA's Boundary Cloud Access Points. Those are physical facilities in a handful of locations. It is a recurring line item, and it exists whether or not anyone scoped it.

What to ask

1. Which cloud service offering, and what PA does it hold? Name the offering and the impact level it is authorized at. "We're IL5" is not an answer to this.
2. Is that PA current, and when does it expire? PAs expire and can be revoked. Your authorization depends on it.
3. Where is the categorization that says this is a national security system, and on which prong? Since July 2025 this is what separates IL4 from IL5. "Someone told us it was" is not a categorization — ask who performed it and which AO accepted it.
4. What do we inherit, and is it attached to controls? Inheritance is a mechanism with mechanics. Ask for the list.
5. If this is Top Secret or compartmented, stop using impact levels. They do not extend there. Different framework, different authorities, and the classification and compartmentation questions from earlier in this series are the ones that apply.

The pattern across all three vocabularies so far is the same: the short label everyone uses names a property of somebody else's system, and the work you are actually signing up for lives in the gap between that label and your own boundary. The first time a commercial application meets a hardened platform is when that gap becomes visible, and it is much cheaper to see it early.

Next, and last in this series: what actually gets signed, by whom, and in what order.

Robert Burckner is the founder of Millabs Corporation, a Service-Disabled Veteran-Owned Small Business. He has served as ISSM and ISSE for legacy weapon systems at the Air Force Lifecycle Management Center and as Division Chief at the Space Warfighting Analysis Center (USSF/NRO). Millabs has deployed commercial software to IL-4 and TOP SECRET environments operational on JWICS.

If you have government demand and are working out what deploying into a classified environment actually requires, an enclave fit study answers the hosting, inheritance and authorization questions before you commit to a schedule. Contact Millabs.