DoD Impact Levels Explained: IL-2 Through IL-6

The Department of Defense (DoD) uses a commercial cloud. But getting DoD data onto your platform requires clearing a specific bar: the impact level assigned to that data. A Software as a Service (SaaS) vendor that satisfies the Federal Risk and Authorization Management Program (FedRAMP) but has never mapped its architecture to a DoD impact level will often discover, mid-procurement, that authorization doesn't carry over as expected.

DoD impact levels determine which data you can legally host and what operating model supports it. The gap between IL-2 and IL-5 comes from structural differences in where your platform runs and who administers it. For SaaS technical and compliance teams assembling federal proposals, understanding these levels early is the difference between a bid that clears review and one that gets flagged.

For SaaS teams, the required DoD impact level shapes the authorization path before a proposal is priced. It determines the infrastructure and personnel model, including whether the platform can inherit controls from an existing boundary.

Key Takeaways

• Impact Levels Govern Hosting. DoD impact levels tie data sensitivity to security controls. The Defense Information Systems Agency (DISA) defines IL-2 through IL-6 based on the sensitivity of information and the harm that would result from its compromise, a system distinct from FedRAMP's Low, Moderate, and High tiers.  
• IL-5 Changes Architecture. IL-5 introduces physical infrastructure separation and U.S.-citizen-only administrator access. It also requires a FedRAMP High floor, which can't be satisfied through documentation alone.  
• Inheritance Requires Authorization. Organizations either build the required controls themselves, which extends timelines, or inherit them from a pre-existing FedRAMP authorization.  
• Pre-authorization Changes the Math. Pairing the correct impact level with a pre-authorized FedRAMP boundary shifts authorization from a full-stack build to application-layer evidence. Neither piece works alone: the workload must be scoped to the level its data requires, and the underlying platform must already have the authorization that level demands.

DoD Impact Levels Set the Bar for Sensitive Data Protection

DoD impact levels are classifications the Department of Defense assigns to data and cloud workloads based on how sensitive the information is and how much harm its compromise would cause. Each level maps to a defined set of security, infrastructure, and personnel requirements that a cloud service must meet before it can host that data.

DISA maintains the DoD Cloud Computing Security Requirements Guide (SRG) V1R6 (December 2025), which defines baseline security requirements for cloud service offerings used across the department. Within that guide, Cloud Information Impact Levels classify systems by two factors: the sensitivity of the information being stored and processed, and the potential harm from a loss of confidentiality, integrity, or availability. The current model applies to active DoD impact levels, including IL-2, IL-4, IL-5, and IL-6, applied on top of FedRAMP baselines to address DoD-specific data sensitivity and mission requirements.

These impact levels are separate from FedRAMP's Low, Moderate, and High tiers, though they build on them. The FedRAMP security baseline is the mandatory security floor for DoD cloud services, and the SRG then layers defense-specific controls plus infrastructure and personnel requirements on top of that FedRAMP foundation.

DoD Impact Levels Define Which Workloads Each Cloud Environment Can Host

Each active impact level maps to a specific data scope and set of operating conditions. The bullets below summarize what each level supports and where the authorization floor sits.

• IL-2 applies to DoD information approved for public release, as well as certain low-sensitivity non-public information where compromise would have limited mission impact.  
• IL-4 hosts Controlled Unclassified Information (CUI), non-CUI non-critical mission data, and mission data supporting military or contingency operations. The CUI baseline requires a FedRAMP Moderate foundation plus DoD-specific controls.  
• IL-5 hosts unclassified National Security System data and CUI needing protection beyond IL-4. It requires a FedRAMP High foundation, physical infrastructure separation, and U.S.-citizen-only administrator access.  
• IL-6 hosts classified national security information up to the Secret level. It requires dedicated infrastructure in classified processing facilities, Secret-network access, and eligibility for DoD or federal contracting status.

For proposal teams, the practical distinction can be summarized by the authorization implication each level creates:

The jumps between rows aren't incremental. Moving from IL-4 to IL-5, or from IL-5 to IL-6, changes the underlying infrastructure, the personnel who can operate it, and the authorization floor the environment must already hold. Assigning the wrong level to a workload produces a mismatch between what the data requires and what the platform can legally support.

Impact Level Selection Depends on Data Type and Mission Consequence

Mission Owners determine the required impact level by categorizing their systems and identifying the level that most closely aligns with the data's sensitivity and the consequence of its compromise. For higher-sensitivity CUI, the Authorizing Official makes the final call on whether the workload requires IL-5, and the SRG prohibits hosting higher-level data on a lower-level cloud, such as placing IL-5 data on an IL-2 environment.

That translation matters during proposal planning because the impact level becomes an infrastructure requirement, an administrator access requirement, and an authorization floor requirement. A proposal that assumes IL-4 inheritance but later receives an IL-5 determination doesn't just face a paperwork adjustment, but a different operating model.

Higher Impact Levels Require Additional Infrastructure and Personnel Controls

The escalation from IL-4 to IL-5 to IL-6 adds stricter infrastructure and staffing requirements that reshape how a platform is built and operated. The three requirements below capture the biggest jumps.

• IL-4 permits shared infrastructure with strong logical separation from non-DoD tenants. IL-5 requires physical separation from non-federal tenants, and IL-6 requires dedicated infrastructure in classified-processing facilities.  
• IL-4 and IL-5 traffic must traverse a Cloud Access Point, with IL-5 adding stricter connectivity constraints. Multi-factor authentication also escalates, moving from virtual or soft tokens to stricter patterns at higher levels.  
• IL-5 requires U.S.-citizen-only administrator access. IL-6 extends the structural shift by tying the environment to classified facilities and Secret-network access patterns.

None of these requirements can be met with documentation alone. They demand physical facilities, cleared staff, and a pre-existing authorization floor, all of which take time and capital to stand up. So the question a SaaS vendor has to answer is whether it's realistic to build that stack in-house, or whether inheriting it from an already-authorized boundary makes more sense?

Inheriting a Pre-Authorized Boundary Compresses the Higher-Impact-Level Path

At IL-5 and IL-6, the required infrastructure and staffing model usually has to be built directly or inherited from an authorized boundary. When a SaaS product runs on infrastructure that lacks FedRAMP authorization, the vendor must bring the infrastructure and platform inside its own authorization boundary and document the whole stack in its System Security Plan.

At IL-5, that means constructing physically separate infrastructure, standing up a U.S.-citizen-only operations team, and implementing the additional national security controls the level requires. Each FedRAMP control has to be implemented as part of the architecture, and the physical and personnel components sit entirely outside anything a documentation exercise can accelerate.

Inheriting controls from a pre-authorized boundary reshapes that work. FedRAMP authorization guidance is explicit that controls can only be inherited from a pre-existing FedRAMP authorization, so the benefit depends on the boundary underneath already holding the right floor. When it does, the payoff is substantial:

• Smaller control scope. The vendor's obligation shrinks to addressing customer responsibilities defined in the underlying service's Customer Responsibility Matrix, rather than implementing every control across the full stack.  
• Reused security packages. DoD authorization promotes the reuse of security packages from FedRAMP and federal agency authorizations, so a cloud offering is authorized once and reused across missions.  
• Inherited infrastructure and personnel. Physical separation, Cloud Access Point connectivity, and U.S.-citizen administrator staffing come with the boundary, rather than being stood up per vendor.  
• Compressed timelines. SaaS vendors can inherit a significant share of controls from a pre-authorized infrastructure boundary, moving the authorization work from years of build-out to weeks of application-layer evidence.

Inheritance only works, however, when the underlying boundary matches the impact level the workload actually requires.

The Right Impact Level Plus an Inherited Boundary Changes the Authorization Math

Neither piece works in isolation. Choosing the correct impact level without an inheritable boundary still requires the vendor to build the full stack. Sitting on an inheritable boundary that doesn't match the required level still leaves a gap that the vendor has to close. The math only changes when both are true at once: the workload is scoped to the impact level its data actually requires, and the platform underneath already holds the FedRAMP authorization that level demands.

The contract or Mission Owner usually answers which impact level applies. The infrastructure decision then determines whether the vendor inherits the controls that level requires or builds them from scratch.

Inheritance is binary. It exists because the underlying platform holds a FedRAMP authorization at the appropriate level. Without that authorization, no System Security Plan revision creates the relationship after the fact, and IL-5's physical separation requirement, IL-6's classified-facility model, and the citizenship mandates at both levels remain structural facts the infrastructure must satisfy.

That combination is what turns the infrastructure provider into a revenue decision, not just a compliance one.

Knox Maps DoD Impact Levels to Authorization Paths for SaaS Vendors

Knox Systems is a FedRAMP-as-a-Service platform that operates a pre-authorized FedRAMP boundary spanning multiple cloud providers, meaning SaaS vendors can inherit most required controls rather than build them.

Knox currently supports FedRAMP Moderate, FedRAMP High, and DISA IL-4. IL-5 authorization is in process, with an estimated completion date of December 2026. The Knox FedRAMP boundary, paired with continuous monitoring capabilities, lets vendors reach a government cloud platform in approximately 90 days at 90% less cost than the traditional path, which can take 12 to 36 months and cost upwards of $3.5 million.

Book a meeting to evaluate whether your DoD impact level can be inherited through the Knox FedRAMP boundary.

FAQs About DoD Impact Levels

Who Decides the Impact Level for a Given Workload?

The Mission Owner categorizes the system, and the Authorizing Official makes the final determination when the workload sits near a threshold, particularly the IL-4 to IL-5 boundary for higher-sensitivity CUI.

What Happens if the Impact Level Changes Mid-Procurement?

An upward change is not a documentation update. Moving from IL-4 to IL-5 typically requires a new authorization floor, different physical infrastructure, and a revised administrator-access model, all of which reshape the operating model rather than the paperwork.

Can a SaaS Vendor Move From IL-4 to IL-5 by Adding Documentation?

No. The System Security Plan describes the boundary, but it does not create the physical separation or personnel controls IL-5 requires.

‍