A cloud service that holds US Department of Defense data needs more than a FedRAMP authorisation: it needs a DoD Impact Level, and the gap between IL2, IL4, IL5 and IL6 decides where data may live, who may administer it, how users sign in and who holds the keys. DISA sets these rules in its cloud Security Requirements Guides. The January 2025 releases split them into a Cloud Service Provider (CSP) SRG, for the provider, and a Cloud Computing Mission Owner SRG, for the DoD component that uses the service; the 2016 Cloud Computing SRG Version 1 Release 2 was the earlier combined document. This guide explains what each Impact Level means, what changes between them, the identity and key management requirements, and how a provisional authorisation and a mission owner's ATO fit together. It is written for cloud providers seeking DoD authorisation, defence contractors choosing a cloud, and DoD mission owners. It builds on the FedRAMP Guide, which it does not repeat. Requirements were checked against the CSP SRG V1R2 and Mission Owner SRG dated 30 January 2025, as checked on 13 November 2026; confirm against DISA's current releases. This guide is not legal advice.
Key takeaways
- Four levels are in use. IL2 is non-controlled unclassified information, IL4 is CUI and mission data, IL5 is higher-sensitivity CUI and unclassified National Security Systems, and IL6 is classified up to SECRET. IL1 and IL3 were merged into IL2 and IL4.
- FedRAMP is the floor, not the ceiling. IL2 accepts FedRAMP Moderate or High; IL4 starts from FedRAMP Moderate plus CNSSI 1253 and DoD FedRAMP+ controls; IL5 and IL6 start from FedRAMP High plus CNSSI 1253 controls and overlays.
- Separation and location tighten with each level. IL4 needs strong virtual separation between tenants, IL5 is limited to federal government community or DoD private clouds physically separated from non-federal tenants, and IL6 needs dedicated infrastructure.
- Identity is CAC and PKI for people. DoD users authenticate with CAC or an approved alternate token and DoD PKI certificates; CSP privileged users need hardware-backed MFA, with stricter rules at IL5 and SIPRNet tokens at IL6.
- A PA is not an ATO. DISA issues a provisional authorisation for the cloud offering; each mission owner still needs its own authorisation to operate, a cybersecurity service provider and the required boundary stack.
What it is and who it applies to
The SRGs define the security requirements for commercial and non-DoD cloud services that host DoD information, and for DoD components that build on them. A DISA Authorizing Official approves DoD Provisional Authorizations (PAs) for a specific cloud service offering (CSO), not for a provider as a whole, and approved CSOs are listed in the DoD Cloud Service Catalog.
- Cloud service providers: meet the CSP SRG for the Impact Level they seek, with a FedRAMP-accredited third party assessment organisation assessing the FedRAMP+ requirements.
- Mission owners: the DoD component that runs a system in the cloud follows the Mission Owner SRG, obtains its own ATO through the Risk Management Framework, and configures its workloads to the applicable STIGs. See the NIST Risk Management Framework (SP 800-37) Guide and the DISA STIG Guide.
- Defence contractors: contractors handling CUI in their own systems are governed mainly by contract clauses and NIST SP 800-171 rather than by Impact Levels. See the DFARS 252.204-7012 Guide and the CUI Guide.
Structure and key requirements
| Impact Level | Information | Baseline | Separation and access |
|---|---|---|---|
| IL2 | Non-controlled unclassified information, including data cleared for public release | Moderate confidentiality, integrity and availability; reciprocity for FedRAMP Moderate or High | User access over the internet |
| IL4 | CUI and other mission data | FedRAMP Moderate plus CNSSI 1253 Table D1 controls at moderate confidentiality and integrity, and overlays; FedRAMP High with FedRAMP+ is also accepted | Strong virtual separation between tenants; connection to DoD networks through a cloud access point |
| IL5 | CUI needing more protection, and unclassified National Security Systems | FedRAMP High plus CNSSI 1253 Table D1 controls and overlays at high confidentiality and integrity | Federal government community or DoD private cloud only; physical separation from non-DoD and non-federal tenants |
| IL6 | Classified information up to SECRET | FedRAMP High plus CNSSI 1253 controls, the classified information overlay and NSS controls | Dedicated infrastructure separate from other CSP offerings; access over SIPRNet or approved CNSSP-11 circuits |
The baseline is built on NIST SP 800-53 Rev 5, with CNSSI 1253 defining the controls for DoD systems and FedRAMP+ adding DoD controls, parameter values and enhancements. See CNSSI 1253 and the NIST Control Overlays Guide.
| Requirement area | IL2 | IL4 | IL5 | IL6 |
|---|---|---|---|---|
| Data location | Facilities under exclusive US legal jurisdiction; off DoD premises, within the 50 States, the District of Columbia and US outlying areas unless the contracting officer or AO authorises otherwise. IL5 data must remain under US jurisdiction. | |||
| CSP personnel with data access | National affiliation limits start above IL2 | US citizens, nationals or US persons | US citizens, nationals or US persons; Tier 4 investigation for customer data access, Tier 2 for moderate-risk roles without it | US citizens |
| CSP privileged MFA | MFA at minimum; hardware token with PKI certificate or one-time password preferred | Strong MFA dedicated to the DoD infrastructure, minimally a hardware token with one-time password or PKI | SIPRNet token and PKI | |
| Connectivity | Commercial internet | Through a Boundary Cloud Access Point (BCAP) or Internal CAP; all off-premises management traffic enters or leaves NIPRNet through a BCAP | SIPRNet or approved circuits | |
- Encryption: mission systems at all levels must support encrypting data at rest with exclusive DoD control of encryption keys and key management. Cryptographic modules must be FIPS 140-2 or FIPS 140-3 validated, Level 1 at minimum and operated in FIPS mode; cloud key management HSMs must be Level 3. A provider key management service that keeps keys from the provider can be used if NSA evaluates and approves it. See the FIPS 140-3 and Cryptographic Module Validation Guide.
- Incident reporting: CSPs submit initial incident reports within one hour of the internal security team completing initial triage and judging the incident reportable. IL2, IL4 and IL5 providers use the DIB Cyber Incident Collection Format, with DC3 as fallback; dedicated IL4 to IL6 offerings coordinate through USCYBERCOM and JFHQ-DODIN.
- Continuous monitoring: CSPs share vulnerability reports and POA&Ms with DISA; High and Critical findings must be mitigated within 30 days and Moderate findings within 90 days.
Identity and NHI requirements
The SRGs are explicit about human identities and keys, and largely silent on service accounts and API credentials. That gap has to be filled from the underlying NIST SP 800-53 controls and the mission owner's own policy.
| Identity | What the SRGs say | What to add |
|---|---|---|
| DoD users | CAC or approved alternate token with DoD PKI certificates; for IL4 and IL5 this applies to privileged and non-privileged users; revocation checked against DoD OCSP or CRL resources | Federate the CSO to DoD PKI rather than local passwords. See the Smart Card and PIV/CAC Authentication Guide. |
| Mission owner administrators | US citizens, nationals or US persons; three unsuccessful privileged logon attempts, then an administrator unlocks the account; management plane traffic registered in the PPSM registry | Route admin access through a PAM tier and record sessions. See the Privileged Access Management Guide. |
| CSP privileged users | Hardware-backed MFA, dedicated to DoD infrastructure at IL5; just-in-time and just-enough access allowed with a Tier 4 supervising administrator | Ask the CSP for evidence of how JIT approvals are logged and reviewed. |
| Encryption keys | Exclusive DoD (mission owner) control from creation through storage and use to destruction | Use customer-managed keys in a FIPS Level 3 HSM. See the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide. |
| Service accounts, workload identities, API keys | Not addressed directly | Apply AC-2 account management, IA-5 authenticator management and IA-5(2) public key-based authentication: inventory, owners, short-lived credentials, workload identity federation instead of static keys, and rotation. |
The leak of administrative keys for AWS GovCloud accounts from a contractor's public repository shows why the gap matters: a high Impact Level does not protect a static key held outside the boundary. See the CISA Private-CISA GitHub Leak 2026 and the Workload Identity Federation Guide.
Choosing between IL4 and IL5
- Choose IL4 when: the data is CUI that the information owner, law and regulation do not mark for extra protection, and the workload is not a National Security System. Multi-tenant commercial regions with strong virtual separation are acceptable, which widens the choice of services.
- Choose IL5 when: the information owner or a regulation requires more protection than IL4, or the system is an unclassified NSS, which must be hosted at IL5 or higher. Expect fewer services in scope, a federal community or DoD private cloud region, and stricter CSP personnel and MFA rules.
- Mixed workloads: host each system at the level its most sensitive data needs, and do not let an IL4 system pull IL5 data through a shared identity, pipeline or key. Shared service accounts across levels are a common way that boundary is crossed.
Implementation steps
- Categorise the data: work with the information owner to decide whether the data is non-controlled, CUI, higher-sensitivity CUI or NSS, or classified. Over-classifying raises cost; under-classifying fails assessment.
- Choose a CSO at that level: confirm in the DoD Cloud Service Catalog that the specific offering, not just the provider, holds a PA at the required Impact Level, and check which services are inside the authorisation boundary.
- Design the boundary: for IL4 and IL5, plan BCAP connectivity, the Virtual Datacenter Security Stack (firewall, IDS/IPS, WAF with feeds to a DoD CSSP) and, mainly for IaaS, the Virtual Datacenter Managed Service for management connectivity and CAC authentication.
- Register and assign defence: register the application, CSO and connection method in SNAP and designate a certified cybersecurity service provider.
- Build identity first: CAC and DoD PKI for users, PAM for administrators, customer-managed keys, and an inventory of every workload identity and key before migration.
- Harden to STIGs: configure guest operating systems, platform services and applications to the applicable STIGs, and scan before assessment.
- Obtain the ATO: complete RMF steps with the component AO, inheriting controls from the PA and documenting the customer responsibilities.
- Pilot and roll back: migrate a low-risk workload first, keep the on-premises service available until monitoring feeds and incident reporting are proven, and test failover.
A small contractor team supporting one programme will usually consume an IL4 or IL5 offering from a large provider and focus on identity, keys and STIG configuration. A large component running many systems should build a shared landing zone with reusable boundary, logging and identity patterns so each ATO inherits as much as possible.
Evidence and assessment
| Evidence | Owner | Used for |
|---|---|---|
| FedRAMP package and FedRAMP+ assessment by a 3PAO | CSP | DoD PA |
| Personnel investigation and citizenship records for staff with data access | CSP | PA and continuous monitoring |
| Monthly vulnerability reports and POA&Ms | CSP | Continuous monitoring by DISA |
| SNAP registration, CSSP designation and VDSS feed confirmation | Mission owner | Connection approval and ATO |
| STIG checklists and scan results for workloads | Mission owner | ATO |
| Key ownership records, HSM validation certificates and key rotation logs | Mission owner | ATO and audit |
| Inventory of service accounts, workload identities and API keys with owners | Mission owner | AC-2 and IA-5 evidence |
Metrics:
- Percentage of user and administrator sign-ins using CAC or DoD PKI.
- Open High and Critical POA&M items past 30 days (target zero).
- Percentage of workload identities using short-lived or federated credentials instead of static keys.
- Time from incident triage to initial report, against the one hour requirement.
- Percentage of workloads with a current STIG scan.
Mapping to other frameworks
| SRG area | NIST SP 800-53 Rev 5 | NIST CSF 2.0 | Related regime |
|---|---|---|---|
| Authorisation (PA and ATO) | CA-6, CA-7 | GV.SC-05 | FedRAMP; NIST RMF |
| CAC, PKI and privileged MFA | IA-2, IA-2(12), IA-5(2) | PR.AA-01 | DoD Zero Trust Strategy |
| Account management and least privilege | AC-2, AC-6, AC-7 | PR.AA-05 | NIST SP 800-171 |
| Tenant separation and boundary | SC-4, SC-7 | DE.CM-01 | CNSSI 1253 overlays |
| Keys and encryption | SC-12, SC-13, SC-28 | PR.AA-01 | FIPS 140-3 |
| Personnel screening | PS-3 | PR.AA-05 | DoD personnel security |
| Incident reporting | IR-6 | RS.CO-02 | DFARS 252.204-7012 |
See the DoD Zero Trust Strategy and Reference Architecture Guide and NIST 800-53 vs 800-171.
Common pitfalls
- Assuming FedRAMP High equals IL5: IL5 also needs CNSSI 1253 controls, physical separation from non-federal tenants, personnel rules and DoD key control.
- Using a service outside the boundary: a provider can hold an IL5 PA while some of its services are not in scope; check each service.
- Treating the PA as the ATO: the mission owner still needs its own authorisation, CSSP and boundary stack.
- Provider-held keys: default provider-managed encryption does not meet the exclusive DoD key control requirement.
- Static keys for automation: long-lived access keys for pipelines and contractors sit outside CAC controls and outside most SRG evidence.
- Missing the one hour clock: incident plans written around 72 hours miss DoD's initial reporting window.
Practitioner checklist
- Record the data categorisation decision and the Impact Level it requires.
- Confirm the specific CSO and each service used hold a PA at that level in the DoD Cloud Service Catalog.
- Plan BCAP connectivity, VDSS and VDMS for IL4 and IL5 workloads.
- Register in SNAP and designate a certified CSSP.
- Enforce CAC and DoD PKI for all users and route administrators through PAM.
- Hold encryption keys under mission owner control in a FIPS 140 Level 3 HSM.
- Inventory service accounts, workload identities and API keys, and replace static keys with federated credentials.
- Apply STIGs to every workload and keep scans current.
- Rehearse the one hour initial incident report.
Standards and references
- DISA: Cloud Service Provider Security Requirements Guide V1R2
- DISA: Cloud Computing Mission Owner Security Requirements Guide
- DISA: Department of Defense Cloud Computing Security Requirements Guide V1R2 (2016)
- NIST: FIPS 140-3 Security Requirements for Cryptographic Modules
- NIST: SP 800-171 Rev. 3
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: FedRAMP Guide · CNSSI 1253 · Azure Government and Sovereign Cloud Guide · Defence Industrial Base Cyber Rules