An impact level is a property of the information, not of the model
The question we get asked is "what impact level is our model?" The governing document does not answer it, because a model is not the thing that gets a level. Information gets a level. The model — along with the training corpus, the retrieval index, the checkpoints, the evaluation set, the prompts and the logs around it — inherits whatever that information requires. Settling that one sentence resolves most of the architecture argument before it starts.
The document is the DoD Cloud Computing Security Requirements Guide (CC SRG), developed by the Defense Information Systems Agency and published on the DoD Cyber Exchange. It defines the baseline security requirements DoD uses to assess a cloud service offering, and it supersedes the earlier DoD Cloud Security Model. It sorts information into four levels — IL2, IL4, IL5 and IL6. There is no IL1 or IL3: the earlier model defined six levels, levels 1 and 3 were folded into 2 and 4, and the numbering was left alone rather than renumbered.
The SRG is not FedRAMP, and the two get conflated constantly. A DoD CIO memorandum of 15 December 2014, Updated Guidance on the Acquisition and Use of Commercial Cloud Computing Services, established that "FedRAMP will serve as the minimum security baseline for all DoD cloud services." The SRG builds on that floor — FedRAMP Moderate at the lower levels, FedRAMP High plus DoD-specific "FedRAMP+" controls and control enhancements at the higher ones — and then layers on DoD requirements for separation, location, connectivity and personnel. Impact levels are a DoD construct. A phrase like "FedRAMP IL5" names nothing.
One caution before the details. DISA re-issued the CC SRG in 2024. It now comes as two documents, one addressed to cloud service providers and one to mission owners, and the control baseline moved from NIST SP 800-53 Rev. 4 to Rev. 5, with CNSSP-32 applied to national security systems. Section numbers moved with it. Where this article gives a section number it is the pre-2024 numbering, which is what most published summaries still quote. Pull the current release from the Cyber Exchange before designing against any citation, including ours.
What each level admits
The table compresses the impact-level definitions and the location-and-separation requirements attached to each. Treat it as a starting map rather than a substitute for the source — the SRG's own wording is more precise than any summary of it.
| Level | Information it covers | Hosting and separation | How it is reached |
|---|---|---|---|
| IL2 | Publicly releasable information, plus unclassified information that is not designated CUI and carries low confidentiality impact. | Commercial cloud on a FedRAMP Moderate baseline. Virtual separation between tenants. | Reached over the public internet. |
| IL4 | Controlled unclassified information and other non-public mission data, including data used in direct support of military or contingency operations. | FedRAMP Moderate plus DoD FedRAMP+ controls. Strong virtual separation, which the provider has to be able to demonstrate and monitor. | NIPRNet, through a DoD-approved cloud access point rather than the open internet. |
| IL5 | CUI needing more protection than IL4 affords, and unclassified national security system data. Categorized up to moderate confidentiality and moderate integrity under CNSSI 1253. | FedRAMP High plus DoD FedRAMP+ controls. Virtual separation between DoD and federal tenants is sufficient; physical separation from non-DoD, non-federal tenants is required. | The same NIPRNet and cloud-access-point path as IL4. |
| IL6 | Classified national security information up to SECRET, and no higher. | Dedicated infrastructure in a facility cleared for processing classified information, assessed against FedRAMP High, DoD parameters and the CNSSI 1253 classified information overlay. | A closed enclave connected only to SIPRNet by private connection. |
Sources: DoD Cloud Computing SRG (DISA) — impact-level definitions, and the location and separation requirements attached to each; the IL5 separation language sits at §5.2.2.3 and the FedRAMP baseline mapping at §5.1.1 in the pre-2024 numbering. CNSSI 1253, Security Categorization and Control Selection for National Security Systems.
Three requirements that decide most of the architecture
Location. The SRG keeps DoD data in facilities under exclusive U.S. legal jurisdiction, and keeps government data that is not on DoD premises inside the 50 states, the District of Columbia and the outlying areas of the United States as defined at FAR 2.101, absent authorization from the responsible authorizing official. For an AI system, "data" is much broader than the production database. It takes in the training corpus, the checkpoints, the evaluation set, the retrieval index and the run artifacts.
Separation. This is where cloud shopping usually breaks. An offering marketed as a "government cloud" does not automatically clear IL5. The requirement is that virtual separation between DoD and federal tenants is sufficient, but physical separation from non-DoD, non-federal tenants — commercial, state and local — is required. If the service, or the infrastructure beneath it, carries any such tenant, that is an IL4 conversation rather than an IL5 one, and the answer belongs to the provider rather than to the marketing page.
Connectivity. IL6 infrastructure is a closed, self-contained environment connected only to SIPRNet. For an AI workload this is the whole game. No package index. No model-hub download. No license callback. No vendor telemetry. No hosted inference endpoint. Every one of those is an ordinary line in a Dockerfile, and every one of them is a design defect at IL6.
What changes, component by component
Mapping the levels onto the parts of a real system is more useful than memorizing definitions. The pattern that repeats: things that behave like plumbing in a commercial deployment become accredited artifacts here.
- Model weights — a file at rest inside the boundary, carrying the level of the environment. Fine-tuned on CUI, they are CUI-derived and travel with those handling rules.
- Inference egress — a call to a hosted model API leaves the boundary. At IL5 that reopens the tenancy and separation question; at IL6 it is simply unavailable.
- Dependency supply — public package indexes and model hubs are not reachable from a closed enclave. Mirroring, pinning and provenance move onto the critical path.
- Retrieval corpus and index — a vector store holds the same information as the documents it was built from, so it carries the same level. An index over CUI is not a derived artifact of lower sensitivity.
- Logs, prompts and traces — observability output contains the information the system handled, which puts it inside the boundary rather than beside it.
- Keys and evaluation data — checkpoints, index shards and held-out test sets are all data at rest, and key management is a control in its own right, not a platform detail.
Two things that get read wrong
A platform's IL5 PA is not your authorization
There are two steps, and they belong to different people. DISA assesses a cloud service offering and, when it qualifies, issues a DoD Provisional Authorization for the levels that offering supports. The mission owner's authorizing official then leverages that PA and its supporting documentation to grant an ATO for the system running inside it. Choosing a platform with an IL5 PA does not authorize the model deployed on top of it. It hands your assessor a large body of inherited evidence and leaves your system's own controls squarely yours.
The second is that classification and categorization are different axes. IL5 accommodates CUI and national security system data categorized up to moderate confidentiality and moderate integrity under CNSSI 1253 — a moderate categorization, not a high one. IL6 is defined by the classification of the information it holds, up to SECRET, which is a separate question from where CNSSI 1253 puts that system for confidentiality, integrity and availability. Teams that assume SECRET automatically means a high baseline, or that a moderate categorization means an undemanding environment, size the effort wrong in both directions.
The personnel rules, read carefully
The SRG limits which cloud service provider personnel may have access to the systems processing or storing DoD information. At IL2 there is no such restriction. At IL4 and IL5, provider personnel with that access must be U.S. citizens, U.S. nationals or U.S. persons, and no foreign persons may have it. At IL6 the requirement narrows to U.S. citizens holding the clearance the environment requires. In the pre-2024 numbering this is §5.6.2, CSP Personnel Requirements.
"U.S. person" is a legal-status term with a published definition, and it is regularly misread as "citizens only," which is narrower than what the rule says at IL4 and IL5. The current definition sits at 22 CFR 120.62, and it covers, among others, a lawful permanent resident as defined at 8 U.S.C. 1101(a)(20) and a protected individual as defined at 8 U.S.C. 1324b(a)(3).
Two things follow. These are requirements on the cloud service provider's staffing and facilities — they belong in a contract discussion and a system security plan, and the provider answers them, not you. And they are not a screening heuristic for the engineers on your own team. Turning a legal-status rule about provider staffing into a general filter on who may work on a project is both a legal exposure and a poor way to build one.
Design for the highest level the system will ever hold
Because a higher level can process information from a lower one, the honest design question is not "what is the lowest level we can get away with" but "what is the highest level this system will ever be asked to hold." The levels do not scale smoothly. IL2 to IL4 is largely controls and documentation. IL4 to IL5 changes tenancy — which offering, which region, which co-tenants — and that is not a configuration change. Moving to IL6 changes the network model itself, and every dependency on the open internet has to be designed out rather than firewalled off.
Six questions worth answering before the first design review rather than after it:
- What is the most sensitive information this system will ever touch — counting the training corpus and the evaluation set, not only production input?
- Does anything reach the public internet at runtime — package installs, model downloads, license checks, telemetry, hosted inference?
- Where do the index, the checkpoints and the run artifacts physically live, and under whose jurisdiction?
- Who else is a tenant of the offering, and of the infrastructure beneath it?
- Who holds the keys for data at rest, and which side of the boundary does key management sit on?
- Which components genuinely need to sit high, and which can live lower without breaking the workflow?
The practical response is to split the system honestly. Keep the components that must sit high as small and self-contained as possible, and let everything that does not need to be there — dashboards, corpora already cleared for release, developer tooling — live lower. A model that has to run headless inside someone else's accredited enclave should assume no outbound network, no runtime license check and no ability to phone home for an update. If it also runs on modest hardware, the number of environments that can accept it rises sharply. That constraint is one reason we build small, purpose-scoped models that read through a body of data and produce a written conclusion with every statement traced back to the exact record it came from: the artifact an assessor needs to see is the same artifact the reader needs to see.
Where our scope ends
Stated boundaries are more useful than claimed breadth, so here is ours.
We do not issue authorizations, and we cannot shorten someone else's
Authorizing officials grant ATOs and DISA issues provisional authorizations. We build to the control set, produce the evidence, and write the system security plan sections that describe what we built. Any firm quoting a guaranteed accreditation date for a decision that belongs to a government official is selling something it does not control.
We are not a cloud service provider and we hold no DoD Provisional Authorization
We build mission-owner systems that run inside a cloud service offering someone else has had assessed. When we say a design "targets IL5," we mean it is built to deploy into an offering carrying an IL5 PA and to satisfy the mission-owner-side requirements — not that we carry an authorization of our own. That distinction is easy to blur in marketing and expensive to blur in a proposal.
We will not put a hosted commercial model API on the critical path of an IL5 or IL6 design
It is a fine tool for drafting, for exploration, and for work at IL2. It is not a component of a system that has to run inside a closed enclave, and building one that quietly depends on it produces a prototype that cannot be fielded. We would rather say so in the first conversation than in the third month.
We do not handle classified material
We can design and build to IL6 constraints — no outbound network, mirrored dependencies, offline evaluation, deterministic packaging — and hand over something that installs and runs inside an enclave. The classified-side integration, the accredited facility and the cleared personnel are not ours, and we will say so rather than imply otherwise.
If you are working the same problem from a different angle: handling CUI in a federal AI system, deploying language models in air-gapped environments, and what actually shortens an ATO for an AI system.
Frequently asked questions
In the DoD Cloud Computing Security Requirements Guide (CC SRG), developed by DISA and published on the DoD Cyber Exchange. It defines the levels and the location, separation, connectivity and personnel requirements attached to each. DISA re-issued it in 2024 as two documents — one for cloud service providers, one for mission owners — aligned to NIST SP 800-53 Rev. 5, with CNSSP-32 applied to national security systems.
An earlier DoD cloud security model defined six levels. The CC SRG reduced them to four by folding level 1 into level 2 and level 3 into level 4, and left the numbering as 2, 4, 5 and 6 rather than renumbering the survivors.
No. Impact levels are a DoD construct; FedRAMP is the minimum baseline underneath them, established by the DoD CIO's December 2014 cloud guidance. A FedRAMP High authorization is an input to the DoD assessment that produces a provisional authorization, and the SRG adds DoD requirements — separation, location, connectivity and personnel among them — on top of it.
No. IL6 infrastructure is a closed, self-contained environment connected only to SIPRNet. Anything that assumes outbound internet access — package installs, model downloads, license checks, telemetry, hosted inference — has to be designed out rather than blocked at a firewall.
No. DISA assesses the cloud service offering and issues a DoD Provisional Authorization; the mission owner's authorizing official then grants the ATO for the system running inside it. A platform PA gives you inherited evidence, not an authorization for what you deploy on top of it.