DoD SRG impact levels: IL2 to IL6, explained

What the DoD SRG is

DISA, the Defense Information Systems Agency, publishes and maintains the SRG, the document that translates 'this cloud can host DoD workloads' into a specific, testable set of controls, connection requirements, and personnel and facility expectations. Rather than inventing a parallel control catalog from nothing, the SRG builds on the FedRAMP baselines that already exist for a comparable impact level and adds what the Department of Defense needs on top: additional technical controls, more specific boundary and connection requirements, and at the highest levels, restrictions on shared tenancy with commercial customers entirely.

Four impact levels cover the practical range of DoD cloud use today.

IL2 sits at the bottom of the sensitivity range, but the Department of Defense still requires a FedRAMP Moderate authorization as the floor, higher than the data's own sensitivity would suggest in isolation, because the department applies a consistent minimum bar regardless of how low-risk an individual IL2 workload looks. IL4 is where most CUI-handling DoD workloads land. IL5 adds both higher-sensitivity CUI and National Security Systems to the picture and expects infrastructure that is more clearly separated from general commercial tenancy, not merely logically partitioned. IL6 leaves the FedRAMP structure behind entirely: classified information up to Secret requires dedicated infrastructure with no commercial tenancy at all, typically connected through a classified network rather than the public internet.

Who needs the DoD SRG

Three groups run into the DoD SRG in practice, each from a different angle.

• Cloud service providers building an offering meant to host Department of Defense workloads, who need DISA to review and issue a Provisional Authorization at the target impact level before any DoD component can use it.
• DoD program offices and mission owners selecting a cloud environment for a system, who need to confirm the impact level their data actually requires and then verify an available offering already carries, or can obtain, a Provisional Authorization at that level.
• System integrators and software vendors building a product that plugs into a DoD-facing cloud environment, who need to understand which impact level their own component must inherit, particularly where their product touches controlled unclassified information governed by NIST 800-171 or connects across a boundary access point.

Which impact level applies is a data question, not a preference: a system handling only public releasable information stays at IL2, a system handling CUI generally lands at IL4, a system handling higher-sensitivity CUI or touching a National Security System needs IL5, and a system handling classified information needs IL6, a different authorization track entirely from the FedRAMP-based levels below it.

DoD SRG requirements, by impact level

Each impact level's requirements are additive: IL4 does not replace the FedRAMP Moderate baseline it is built on, it adds to it, and IL5 adds further on top of a FedRAMP High baseline rather than starting over.

The additions that matter most in practice are connection architecture and tenancy. IL4 and IL5 workloads generally have to route DoD-bound traffic through a boundary Cloud Access Point that DISA operates, rather than connecting directly over the general internet, and IL5 environments are expected to demonstrate infrastructure separation from commercial tenants that goes beyond standard logical isolation. IL6 abandons the FedRAMP-based structure entirely: dedicated infrastructure, no commercial tenancy, and connectivity typically over a classified network rather than any commercial connection.

The SRG also folds in DISA's own hardening expectations for the underlying technical stack, including STIG requirements for operating systems and container images, mapped to controls with their own CCI identifiers, work that shows up again later in how ACTA reports against this framework specifically.

The DoD SRG authorization process, step by step

The path below assumes a cloud provider or mission owner working toward authorization at a specific impact level, since the SRG process looks different depending on whether an already-authorized offering exists at the level a system needs.

1. Determine the required impact level: Classify the workload's data against the impact level definitions, public or non-CUI through classified, since everything downstream depends on getting this right; typically two to four weeks with a data-sensitivity review.
2. Identify or pursue a cloud offering with a Provisional Authorization at that level: Check whether an existing cloud service offering already carries a DISA Provisional Authorization at the required level, since building one from scratch for a level that already exists elsewhere rarely makes sense; days if an offering already exists, well over a year if DISA has to review one from scratch.
3. Confirm the underlying FedRAMP baseline: Verify the FedRAMP Moderate or High authorization the offering rests on for IL2, IL4, or IL5 respectively is current, since a lapsed underlying FedRAMP authorization undermines the DoD-level Provisional Authorization built on top of it.
4. Build the required connection architecture: Stand up boundary Cloud Access Point routing, or confirm the offering already routes through one, and for IL6 build the dedicated, fully separated infrastructure the level requires instead; four to twelve weeks depending on what already exists.
5. DISA reviews and issues the Provisional Authorization: DISA's review of the DoD-specific control additions and connection architecture, on top of the existing FedRAMP package, commonly runs several months for a first-time offering at a given level.
6. The DoD component issues its own authority to operate: The mission owner's authorizing official reviews the system built on the Provisional Authorization and issues an authority to operate tailored to that specific system, since a Provisional Authorization on the underlying cloud is not itself a system-level authorization.
7. Maintain continuous monitoring and reauthorization: Ongoing monitoring follows the cadence of the underlying FedRAMP continuous monitoring program plus any DoD-specific requirements layered on top, and both the Provisional Authorization and the component-level authorization are revisited on their own review cycles rather than treated as permanent.

How long DoD SRG authorization takes and what it costs

Cost and timeline depend enormously on whether a cloud offering already carries a Provisional Authorization at the needed impact level or whether one has to be built from scratch, which is the single biggest variable in this process.

For a DoD component adopting an already-authorized offering at the impact level it needs, the mission owner's own system-level authorization effort, built on top of the existing Provisional Authorization, commonly takes three to nine months depending on system complexity. For a cloud provider pursuing a first-time Provisional Authorization at IL4 or IL5, expect the underlying FedRAMP effort plus DISA's additional review, often pushing total timelines past a year, sometimes well past two, particularly for IL5 given the added National Security System and infrastructure-separation review.

Costs split across layers paid to different parties. The underlying FedRAMP assessment costs, 3PAO fees and advisory support, apply as described on the FedRAMP page, commonly in the hundreds of thousands of dollars for Moderate or High. DISA's additional review is generally absorbed by the cloud provider as part of pursuing the Provisional Authorization rather than billed as a separate line item, though the internal engineering and documentation effort to meet the connection and separation requirements can itself run well into six figures for a first-time IL5 effort. A mission owner adopting an already-authorized offering avoids most of this and mainly bears its own system-level assessment and documentation cost, commonly tens of thousands of dollars rather than hundreds of thousands.

ACTA is licensed per environment, and every engagement starts with a conversation. What ACTA automates is documentation and evidence generation for the mission owner's own system-level authorization and for the underlying control set, not DISA's independent Provisional Authorization review, which ACTA does not and cannot replace.

Common failure points

SRG-specific failures tend to come from treating impact levels as a formality rather than an architectural commitment.

• Assuming a FedRAMP Moderate or High authorization alone is sufficient for DoD use without confirming the SRG-specific overlay and an actual DISA Provisional Authorization.
• Underestimating connection and boundary requirements, routing through the wrong access point or assuming direct internet connectivity is acceptable at IL4 or IL5.
• Treating IL5 as IL4 with a bit more scrutiny instead of recognizing the added National Security System scope and dedicated-infrastructure expectations.
• Assuming an existing commercial FedRAMP listing automatically carries a DoD Provisional Authorization, when DISA reviews and issues its own separately.
• Conflating IL6 classified requirements with IL5 CUI requirements when planning infrastructure, then discovering the architecture does not hold up under IL6 scrutiny.
• Skipping STIG and CCI verification for the underlying container and image layer, which a DISA-aligned assessment tests regardless of the cloud-level authorization above it.

How ACTA automates DoD SRG compliance

ACTA's federal pack library includes the DoD Cloud Computing SRG alongside FedRAMP, CMMC, and NIST 800-171, and every pack ships with every license: a program working across multiple impact levels is not paying separately for each one.

For IL5 and IL6 environments specifically, where the whole premise is that evidence does not casually cross a boundary, ACTA's air-gapped build makes no network callback of any kind, not even the license heartbeat the standard build uses. ACTA is a single hardened Docker image under 20 MB running on roughly 100 MB of RAM, so it fits inside an isolated enclave without a large dependency footprint.

Outputs are generated in formats built for direct import rather than manual reformatting: STIG CKL XML for checklist results, an eMASS-importable POA&M CSV for the plan of action, and control mapping directly to the DISA Container Image Creation and Deployment Guide with its CCI identifiers for the container and image layer specifically, alongside the System Security Plan, Security Assessment Report, and evidence binder that support the broader authorization.

Continuous monitoring tracks credential health, evidence freshness, endpoint posture, and drift from previously passing controls between the reauthorization cycles the SRG and the underlying FedRAMP program both expect, refreshing a stale posture to current in two clicks. ACTA can also provision the environment itself as code, on AWS GovCloud, Microsoft GCC High, or bare metal among other targets, with a small environment standing up in roughly 25 minutes, though the impact-level authorization of wherever it is provisioned remains a separate question that environment's own Provisional Authorization has to answer.

DoD SRG and adjacent frameworks

Every impact level below IL6 is a FedRAMP baseline with Department of Defense-specific requirements added on top, so FedRAMP authorization is not a competing framework here, it is the floor the SRG builds on.

The SRG and CMMC answer different questions about the same defense supply chain: the SRG governs which cloud a workload is allowed to run on, while CMMC governs how a contractor protects the information inside its own environment, cloud-hosted or not. A defense contractor storing CUI in the cloud typically has to satisfy both, CMMC for how it handles the information and confirmation that the cloud itself carries the right impact level.

Whatever impact level applies, the information itself, if it is CUI, is still governed by NIST 800-171 requirements regardless of which cloud hosts it; the SRG and the control catalog operate on different layers of the same problem, infrastructure authorization on one side, information protection requirements on the other.

Because Provisional Authorizations and component-level authorizations under the SRG both run on review cycles rather than staying static, the discipline behind keeping an authorization continuously current applies here just as much as it does to a civilian agency's FedRAMP-based system. See the full compliance framework library for how the SRG relates to the rest of the federal and defense control landscape.