Impact Level Compliance
IL2 through IL6 classification and cloud security requirements
DoD Cloud Computing Security Requirements Guide defines impact levels from IL2 through IL6 based on data sensitivity. Thalorin supports impact level compliance with control mapping, authorization documentation, and continuous monitoring aligned with CC SRG requirements for each impact level.
An impact level is a determination the mission owner's authorizing official makes about information, not a property of the region the workload lands in. The guide says so plainly: impact levels are a DoD construct, they do not apply to FedRAMP baselines, and calling a provisional authorization a FedRAMP impact level is inaccurate. Four levels exist — IL2, IL4, IL5 and IL6. On 14 June 2024 the single Cloud Computing SRG was replaced by a package separating a Cloud Service Provider SRG from the Mission Owner SRGs; the provider document now stands at Version 1 Release 2, dated 30 January 2025.
Reaching a level means clearing gates held by different bodies. DISA assesses a cloud service offering against the SRG and awards a DoD Provisional Authorization, starting from the FedRAMP Moderate baseline at IL4 and the FedRAMP High baseline at IL5 and IL6, each supplemented with DoD FedRAMP+ controls and CNSSI 1253 overlays. That grant does not authorise what the programme runs: the mission owner's authorizing official still issues an ATO, and section 5.9.1.1 requires an off-premises commercial offering to reach the DISN at IL4 and IL5 through a Boundary Cloud Access Point.
The scope of a provisional authorization is what gets underestimated. A PA covers assessed service offerings, which is why the SRG sends mission owners to the DoD Cloud Service Catalog rather than to a provider's name; an unassessed service sits outside the authorization even when it runs beside one that was assessed. Inheritance is the other half. Table 4-2 fixes the mission owner's boundary by service model — under IaaS the virtual networks, operating systems, applications and data stores are all the programme's — and the controls on that side of the line are reliably the ones nobody staffed.
Impact level, in Thalorin, is an attribute of the information rather than a label on the environment. Each asset carries the categorisation that put it at a level, each control records whether it is inherited from a provisional authorization or implemented by the programme, and a service that moves outside PA scope raises the controls that stop being inherited — rather than leaving a system security plan asserting a boundary that has already changed.
Classified environments require extraordinary controls
The level is determined, not purchased
The authorizing official categorises the information under DoDI 8510.01 and CNSSI 1253, and the level follows from that. Providers sell regions and authorizations; neither decides whether a given workload belongs at IL4 or at IL5.
A PA is scoped to offerings, not providers
A DoD Provisional Authorization names the cloud service offerings it covers, and the catalogue is the record of what those are. Reaching for an unassessed service places the workload outside the authorization, and nothing in the provider's console says so.
Inheritance follows the service model
What a mission owner inherits from a provider is set by the service type, not by preference. Moving from SaaS to IaaS silently transfers operating systems, applications and data stores onto the programme's side of the authorization boundary.
IL5 is a tenancy decision, not a setting
Section 5.2.2.3 makes only DoD private and federal government community clouds eligible at IL5 and requires physical separation from public, state and local government tenants. No configuration change inside a general commercial region produces that.
How Thalorin helps
IL2 through IL6 control mapping
Hold one control state and read it at each level the SRG recognises, so the distance between the level a system holds and the level a contract names is a query, not a fresh assessment.
CC SRG compliance automation
Track the DoD FedRAMP+ controls, parameter values and enhancements the SRG layers over the FedRAMP baseline for a level, each bound to the component of the service offering that satisfies it.
Impact level gap analysis
Compare a system against a higher level and return the named requirements it does not meet — the baseline moving from FedRAMP Moderate to High, the CNSSI 1253 overlays arriving with it, the tenancy constraint — not a percentage.
Cloud authorization documentation
Generate the system security plan, the control implementation summary and the body of evidence a DISA assessment reads from one control state, so the package and the environment cannot drift apart.
Continuous monitoring alignment
Carry the continuous monitoring commitments attached to a provisional authorization — scan cadence, POA&M ageing, significant change reporting — against the authorization that imposed them rather than against a calendar.
Multi-tenant isolation verification
Evidence which tenants and missions actually share physical infrastructure and which share only a hypervisor, tested against the location and separation requirements the SRG sets for the level being claimed.
Impact Level Compliance: common questions
What happened to Impact Level 1 and Impact Level 3?
They were consolidated away in an early revision of the guide and no longer exist. The Cloud Computing SRG originally defined six levels; IL1 was folded into IL2 and IL3 into IL4, leaving IL2, IL4, IL5 and IL6 as the only levels the current Cloud Service Provider SRG defines. Older architecture papers, reference designs and occasionally statements of work still name IL3, usually meaning what is now IL4. Treat an IL3 reference in a requirement document as a question for the authorizing official, not a level to build toward.
Does a FedRAMP High authorization get a cloud service to IL5?
No — it is the starting point. Section 3.7.5 of the Cloud Service Provider SRG uses the FedRAMP High baseline, supplemented with DoD FedRAMP+ controls, CNSSI 1253 overlays and the SRG's own requirements, to assess a provider toward an IL5 or IL6 provisional authorization. DISA awards it, not FedRAMP. IL2 is the one case where reciprocity is direct: the SRG grants full reciprocity with FedRAMP Moderate and High P-ATOs there, so no written DoD PA is needed. Above IL2, location, separation and personnel requirements are assessed on top of the baseline.
Does the provider's DoD provisional authorization cover my system?
No. A PA covers the cloud service offering. The SRG states that the mission system ATO requirement applies at every impact level, so the programme still needs an ATO from its component's authorizing official, and it inherits only the controls the provider implements and maintains for the service model in use. This is the most common late surprise in a DoD cloud assessment: an inheritance assumption Table 4-2 never supported, surfaced when an assessor asks for evidence of a control everyone assumed the provider held.
Can a non-US person administer an IL4 or IL5 environment?
Not on the provider's side. Section 5.5.2 of the Cloud Service Provider SRG limits access by national affiliation above IL2: provider personnel with access to systems processing or storing CUI at IL4 and IL5, or to the information itself, must be US citizens, US nationals or US persons, and no foreign persons may have such access. At IL2 there is no restriction at all. Mission owner personnel requirements are set separately, and CUI categories carrying export control markings bring nationality restrictions of their own.
What separation does IL5 actually require?
Section 5.2.2.3 treats virtual and logical separation between DoD and federal government tenants and missions as sufficient, while requiring physical separation from non-DoD and non-federal tenants — public, state and local government customers. Only DoD private clouds and federal government community clouds are eligible at IL5, and the data must remain under US jurisdiction. The section carries a note that it is under review for updating against CNSSP-32 with the NSA, so expect the wording to move.
Regulatory state described as of August 2026. Requirements change; verify against the current rule before relying on any date above.
Talk to us about Impact Level Compliance.
See how one evidence artifact satisfies Impact Level Compliance requirements alongside every other framework you carry.