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.

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.