DoD Cloud Computing Security Requirements: SRG Impact Levels

The Department of Defense Cloud Computing Security Requirements Guide is the Defense Information Systems Agency’s rulebook for any commercial cloud provider that wants to host military data. Published by DISA, the current version (Version 1, Release 2, January 2025) sorts DoD information into sensitivity tiers, sets the security controls each tier demands, and defines how a provider gets authorized and stays authorized.¹ The guide sits on top of the civilian FedRAMP framework and adds controls specific to defense networks.²

The Four Information Impact Levels

Everything in the guide flows from how the data is classified. There are four active impact levels: IL2, IL4, IL5, and IL6. Earlier versions included IL1 and IL3, but those have been removed. These are a DoD-specific construct and are not the same as FedRAMP’s own impact categories.³

IL2 — Public and Non-Critical Information

IL2 covers public or non-critical mission information with no controlled handling requirements. Any cloud offering that already holds a FedRAMP Moderate authorization gets IL2 designation through reciprocity, so DISA does not put the provider through a separate DoD assessment at this tier.⁴ For most commercial providers, IL2 is the entry point into the defense market.

IL4 — Controlled Unclassified Information

IL4 handles Controlled Unclassified Information for non-critical missions and non-national security systems.⁴ That includes export-controlled technical data, protected health information, and law enforcement sensitive records.

Providers must meet the full FedRAMP Moderate baseline plus a CUI-specific overlay of extra DoD controls, often called “FedRAMP+.” The January 2025 SRG’s IL4 overlay added 22 controls and removed 38 compared to the baseline. This is where many providers first hit the gap between civilian federal security and what the DoD actually demands.

IL5 — Higher-Sensitivity CUI and National Security Systems

IL5 is reserved for higher-sensitivity CUI, mission-critical information, and National Security Systems, and it is the ceiling for unclassified data.⁴ The floor jumps from FedRAMP Moderate to FedRAMP High, with IL5-specific FedRAMP+ controls added. For National Security Systems workloads, the overlay grows to 178 additional controls beyond the FedRAMP High baseline.

IL5 environments often host unclassified tactical data and sensitive medical records that need higher integrity. In some deployment scenarios, providers must physically separate IL5 tenants from lower-impact ones and demonstrate resilience and real-time monitoring.

IL6 — Classified Information Up to Secret

IL6 covers classified information up to the Secret level. A standard commercial cloud environment cannot host IL6. The infrastructure must sit in a dedicated cloud, physically and logically isolated from public internet traffic, housed in facilities rated for classified processing.³

Personnel requirements alone are a serious barrier. The provider needs a facility clearance, staff managing the environment must hold at minimum a Tier 3 (Secret) investigation, and at least five personnel must hold Tier 5 investigations for higher-level government coordination. Connectivity runs through SIPRNet, creating a closed environment for processing, storage, and management.³

One practical wrinkle: a provider cannot obtain an IL6 provisional authorization before a contract is in place, because the contract triggers the DD-254 form that starts the facility clearance process. Early coordination between the provider, the sponsoring mission owner, and DISA is essential.³

How the SRG Stacks on FedRAMP

FedRAMP is the foundation. A 2014 DoD CIO memorandum set it as the absolute minimum security baseline for all DoD cloud services, and the SRG never replaces it. The guide extends FedRAMP by layering defense-specific controls on top, producing what DISA calls “FedRAMP+.”²

A provider cannot enter the defense market without either a FedRAMP authorization or proven equivalency. IL2 needs FedRAMP Moderate. IL4 needs FedRAMP Moderate plus the IL4 overlay. IL5 and IL6 need FedRAMP High plus their heavier overlays. The layered design lets the DoD reuse the civilian federal assessment instead of duplicating it, while still enforcing the extra controls military data requires.

FedRAMP Equivalency

Not every provider holds a formal FedRAMP authorization. A December 2023 DoD memo laid out the criteria for a provider to claim “FedRAMP Moderate equivalent” status instead. The bar is high: 100 percent compliance with all FedRAMP Moderate controls, validated by a FedRAMP-recognized Third Party Assessment Organization (3PAO). The provider must also comply with DFARS 252.204-7012 paragraphs (c) through (g), which cover cyber incident reporting, malicious software handling, media preservation, and forensic analysis access. This path matters most for defense contractors storing CUI in commercial clouds under the Cybersecurity Maturity Model Certification framework.

The SCCA Piece You Can’t Ignore

The SRG does not stand alone. It works alongside the DoD Secure Cloud Computing Architecture (SCCA), which defines the network security components required to connect a commercial cloud to DoD networks. Where the SRG tells a provider what controls to implement inside the cloud, the SCCA governs how traffic flows between that cloud and the Defense Information Systems Network.⁵

The SCCA has four core components: the Cloud Access Point (CAP), which acts as the boundary gateway between DoD networks and the cloud; the Virtual Datacenter Security Stack (VDSS), which secures virtual network enclaves; the Virtual Datacenter Managed Services (VDMS), which handles application host security and privileged user access; and the Trusted Cloud Credential Manager (TCCM), which enforces role-based, least-privilege access for cloud credentials.⁵ Focusing only on SRG controls and ignoring the SCCA is a common early mistake that creates expensive rework later.

The Authorization Package

Providers submit their authorization package to DISA’s Cloud Team through the Cloud eMASS system, a centralized platform for managing security documentation.⁶ The required artifacts include:

A System Security Plan (SSP) describing how each control is implemented, with architecture diagrams and data flows; DoD submissions also require a separate DoD SSP Addendum.
A Security Assessment Plan (SAP) outlining the 3PAO’s scope and methodology.
A Security Assessment Report (SAR) documenting the 3PAO’s findings and any vulnerabilities.
A Plan of Action and Milestones (POA&M) with specific remediation steps and timelines.
CSO architecture and data flow diagrams.
A Readiness Assessment Report (RAR) demonstrating the FedRAMP baseline posture.

Every artifact must be attached to its corresponding security control in eMASS so DoD mission owners can inherit it later. Uploading a document does not make it available downstream unless it is mapped.⁶ Packages treated as a file dump stall at the first review.

How the Authorization Actually Happens

The path to a Provisional Authorization is more collaborative than pass/fail, and slower than most providers expect. A DoD sponsor submits the request. DISA runs an intake meeting and then a Joint Validation Team kick-off. The JVT is led by DISA and includes analysts from the sponsoring organization.⁶

The 3PAO then runs its independent assessment and delivers the SSP, SAR, and POA&M to the JVT for validation. Reviewers check completeness, look for compelling evidence behind each implemented control, and scrutinize data flows and boundary integrity. Comments go back to the provider and 3PAO, and the remediation cycle can repeat several times.⁶

Once the JVT is satisfied, the package moves through DISA’s internal review chain to the DISA Authorizing Official. If the AO judges the risk acceptable, the provider receives a Provisional Authorization for the applicable impact level. It is “provisional” because it covers the cloud service offering itself. Individual DoD components still issue their own Authorizations to Operate for the specific systems and data they run on that offering.

The whole process is built around reuse. A provider goes through it once, and multiple DoD mission owners can leverage the resulting package. Each still evaluates whether the risk profile fits and may add conditions, but they do not repeat the assessment from scratch.⁶

Continuous Monitoring After Authorization

The PA is not the finish line. Providers must run monthly vulnerability scans, submit monthly continuous monitoring reports, and undergo annual security assessments. Vulnerabilities must be resolved or mitigated within 30, 90, or 180 days depending on severity.⁶

When DISA publishes an updated version of the SRG, providers already holding a PA must submit a POA&M within 30 days showing how they will transition to the new requirements. The transition must be complete no later than the next annual assessment, which gives providers roughly six months to a year. Non-compliance can lead to revocation of the authorization and contract termination.³

What the Mission Owner Still Owes

The SRG creates a shared responsibility model. The provider secures the infrastructure and platform. The DoD organization using that cloud carries its own obligations that no provider PA covers.

Mission owners build their own authorization package documenting how they implement controls inside their applications. That means applying all relevant Security Technical Implementation Guides (STIGs) for operating systems and applications, following DoD ports and protocols guidance, and having their implementation reviewed by their organization’s certification personnel.⁴

Scope shifts with the service model. In IaaS, the mission owner handles nearly everything above the hardware layer. In SaaS, the provider carries more of the burden, but the mission owner still owns access management, data classification, and oversight of the provider’s controls. Federal agencies remain ultimately accountable for the security of their IT systems in the cloud regardless of model.⁴ Treating the provider’s PA as covering the mission owner’s own build is a common path to a painful audit.

1
DoD Cyber Exchange. DoD Cloud Computing Security
2
WBDG Whole Building Design Guide. Department of Defense Cloud Computing Security Requirements Guide
3
Defense Information Systems Agency. Cloud Service Provider Security Requirements Guide
4
Cloud Information Center. Cloud Security
5
RMF.org. DoD Secure Cloud Computing Architecture Functional Requirements
6
DISA. DoD Cloud Authorization Process