DoD SRG’s Silent Earthquake:

IL5 Moved to NSS-Land. Most of You Are Actually IL4 (and that’s okay).

The Defense Information Systems Agency (DISA) has been pushing out a number of Cloud Security Requirements Guide (SRG) updates in recent months. Since July 2025, we’ve seen:

• SRG V1R3 – dated July 02, 2025
• SRG V1R4 – dated August 13, 2025
• SRG V1R5 – dated September 03, 2025

Hey DISA, friendly request here—maybe gather everyone together to think about a roadmap of quarterly releases or even an industry town hall?

While there’s been many updates, in my opinion V1R3 had the largest impact by far. The version number whispers “minor,” but the blast radius is atomic. Every CSP needs to understand the following:

Impact Level (IL) 5 is now explicitly a National Security System (NSS) neighborhood, and that’s not a place most CSPs want to find themselves in.

The part hardly anyone is saying out loud

Open the SRG, from version V1R3 through to the latest V1R5, where it actually explains IL levels, and it’s unambiguous: IL5 is for unclassified NSS / National Security Information (NSI). That’s IL5. Full stop.

Meanwhile, IL4 is still where most Controlled Unclassified Information (CUI) and nonpublic unclassified mission data like For Official Use Only (FOUO), Personally Identifiable Information (PII) and Protected Health Information (PHI) belong. The FedRAMP Moderate or High baselines can be used as a CSP starting point, with DoD FedRAMP+ control adjustments and CNSSI 1253 overlays based on the data/mission. That’s the default home for most DoD workloads that are not NSS.

Table 3-1 quietly redraws the map

SRG v1R3 Table 3-1: Minimum DoD PA Assessment Controls sets the baselines and overlays per impact level. The important bits:

• IL4: FedRAMP Moderate or High baseline + CNSSI 1253 overlays (data/mission-driven) + DoD FedRAMP + tweaks.
• IL5: FedRAMP High + CNSSI 1253 Appendix D (NSS) overlays. IL5 is clearly linked to NSS scope and is no longer just an IL4 on steroids.

To land the point a little bit more clearly, let’s look at the same Table from V1R2 of the SRG, that existed prior to July 2^nd:

The removal of row 3 (highlighted) is why I felt the need for this blog. This seemingly subtle removal of a single line may cause many confusing, roundabout conversations between DISA, CSPs and their mission owners—for years to come.

As a CSP, if you’ve been saying “we’re IL5” as shorthand for “we’re super secure,” you really need to rewrite your script. IL5 means NSS. If you’re not NSS (and your Authorizing Official didn’t explicitly require IL5), you are almost certainly IL4, potentially High IL4 (and that’s okay). If you are in the middle of preparing for IL5 or competing on a contract that requires that classification, you may want to prepare for the additional effort and requirements.

Why that matters: control math and separation reality

IL5 isn’t a marketing tool. IL5 is NSS. IL5 is a control baseline that’s bigger, meaner, and frankly not really achievable for a lot of CSPs without significant resource expenditure and sleepless nights.

The New IL5 Baseline

IL5’s baseline is FedRAMP High plus NSS Appendix D overlays and DoD FedRAMP+ parameter adjustments. That’s a hefty uplift over plain FedRAMP High. The SRG points you to Appendix D for mandatory parameter values, and to CNSSI 1253 for the NSS extra controls. When you compile all of these requirements, you’ll need to implement an additional ~175 controls.

Figure 1 – New Control Baselines Showing Significant IL5 Uplift over High IL4

Let that sink in.

From roughly 419 controls in an IL4 High system to roughly 593 controls (depending on PII requirements and other variables).

Having examined the additional controls myself, these aren’t cute, cuddly little enhancements. Some of them are “stalker in the night” family annihilators. Highlights include the requirement to implement things like:

• System for managing security and privacy attributes
• Data mining
• End user behavior analytics
• Threat Modeling and Hunting

For most systems, these are controls that will require entirely new technologies and services to achieve control readiness. And those are just some of the  highlights.

Separation: IL4 vs IL5 changes how you architect

This isn’t just rooted in additional controls. For CSPs, your multitenancy and hosting model options change.

• IL4 (section 5.2.2.2): You can run on public, private, community, or hybrid models. Strong virtual separation (encryption and/or access control) and monitoring make “search & seizure” of non-DoD tenant data possible without leaking DoD data, while preventing cross-tenant bleed on shared hardware. Monitoring must detect and support incident response.
• IL5 (section 5.2.2.3): Only federal government community or DoD private clouds are eligible. Virtual/logical separation between DoD and other federal tenants is okay, but physical separation from non-DoD/non-federal tenants (public, state/local) is required. All IL5/NSS data must remain under U.S. jurisdiction or in U.S. territories/locations with U.S. jurisdiction (note: this subsection is flagged for CNSSP-32 alignment, but the jurisdictional requirement still stands).

I encourage everyone to read that again and understand the vast differences in those requirements. IL4 tolerates virtual separation done right. IL5 narrows the party to DoD/federal tenants and raises both physical separation and jurisdiction bars.

“But our Mission Owner said ‘IL5’…”

Cool story, but you’re probably going to have to educate your mission owner.

The SRG directs Mission Owners to categorize per DODI 8510.01/CNSSI 1253 first, then pick the Cloud Impact Level that aligns. FedRAMP gives reciprocity, but Impact Levels are a DoD construct, they’re not FedRAMP impact levels. NSS belongs in IL5 or higher. If your system is not NSS, IL4 is the right fit, with the right overlays and parameters.

Why baking this into a “minor” version is a big deal

Calling V1R3 “minor” while shifting IL5 to explicitly NSS-land is like calling a hurricane “breezy.” It creates three practical consequences:

I can’t stress this enough—Impact Levels are not marketing materials. If your C-Level folks are demanding IL5 ‘cause it sounds good, they need to be educated as well.

What CSPs should do this quarter

For CSPs with active or potential contracts with DoD agencies and/or those seeking DISA Provisional Authorization (P-ATO), I encourage the following:

1. Force the baseline call and get it in writing. Ask your Mission Owner for a sentence like:

• “For this workload, the baseline is IL4 (FedRAMP Moderate or High) with DoD FedRAMP+ and CNSSI 1253 overlays (data/mission-driven).”

      OR

• “For this workload, the baseline is IL5 (NSS) = FedRAMP High + CNSSI 1253 Appendix D overlays at CIA HHx, plus DoD FedRAMP+.”

This is exactly how the SRG frames the mapping. You’re just helping everyone say the quiet part out loud. I encourage you to ask your Mission Owner for a document that outlines every control they expect your system to address.

2. Confirm NSS status. If it’s not NSS (and the AO didn’t impose IL5), it’s IL4. If it is NSS, begin evaluating the IL5 control set, separation constraints, and roadmap accordingly.

3. Nail down parameter values. Parameter values come from the DoD RMF TAG (DSPAV) or CNSSI 1253 where TAG doesn’t define one. If the Mission Owner needs alternates, they negotiate them and reflect changes in the SLA/contract. This is how you avoid six months of surprise POA&Ms.

4. Re-validate hosting model eligibility.

• If you’re IL4: Prove strong virtual separation and monitoring, and show you can honor e-discovery/seizure on non-DoD tenants without exposing DoD data.
• If you’re IL5: Ensure your CSO is DoD private or federal community. Keep IL5/NSS data under U.S. jurisdiction and physically separate from non-DoD/non-federal tenants. If your current multitenancy story mixes public/state/local tenants with IL5 customers, it won’t fly.

5. Budget the delta. If, after all your conversations with your Mission Owner, your offering is determined to be IL5…You’re going to need a bigger boat. Rally the troops, break out the coffee and get to whiteboarding. More controls = more engineering, more audit prep, more ops.

According to Section 4.4 Assessment Impact of Cloud Computing SRG Updates (page 24 of the SRG v1.3), you had 30 days to make this a reality.

As Clear as Mud

I wish it was all this simple (if you can call any of this “simple”). But the SRG is not made for simplicity (some might argue that it’s purposefully been designed as the modern-day Tower of Babel…some, not me 😊).

Instead of leaving it as simple as IL5 = NSS, there’s a single paragraph in Section 5.1.3 National Security Systems (NSS) (page 29) that states:

Mark my words: that last sentence will be the source of confusion, strife, and needless complexity for the foreseeable future. That sentence opens the door for Mission Owners to call something “IL5” and create a misery-inducing mix of separation requirements, control baselines, wanton thoughts and desires, and general misunderstandings.

That’s why, as a CSP, it is critical for you to get the security requirements in writing. You need to understand the architecture requirements, control requirements, and Mission Owner expectations. This can only be done by keeping open communication channels and staying in constant contact as you work through the implementation of your system architecture and control sets.

These type of SRG changes take a long time to work their way through the DoD/DISA ecosystem, and you may find yourself repeatedly referencing the SRG to explain these complex concepts.

Conclusion: Call It What It Is, Build It Like You Mean It

SRG V1R3 didn’t just tweak a table—it rewired the decision tree. The first question is no longer “How strong do we want this?” Rather, the first question must be:

“Is this NSS?”

If the answer is no, you’re in IL4 land and you should be happy. Tell you’re marketing team and C-suite arbitrarily demanding IL5 so they can sell, sell, sell, to pound sand.

If the answer is yes, you’re in IL5 NSS territory, and may God have mercy on your soul.

That is not a vibe shift; it’s a total scope, cost, and architecture shift.

Stop treating IL5 like a prestige badge. It now signals NSS-only, with real consequences, physical/tenant separation constraints, U.S. jurisdiction requirements, and a control math expansion that will chew up engineering hours if you stumble into it by assumption. Conversely, right-sizing to IL4 isn’t settling. It’s aligning to mission and data, moving faster, and spending money where it addresses actual risk.

Getting this wrong means two bad outcomes:

• Overbuilding an IL5 (NSS) program you didn’t need (budget sink, schedule slip).

OR

• Underbuilding an IL5 you actually do need (disqualification, re-architecture under fire).

Getting it right means clear scope, clean architecture, predictable audit, and time back to ship mission value. So, here’s the tagline I encourage everyone to adopt:

If it’s not NSS, it’s IL4…and that’s okay.

About the Author:  

Johann Dettweiler is the Chief Information Security Officer at stackArmor, a Tyto Athene Company. He is a seasoned cybersecurity leader with deep expertise in FedRAMP, NIST Risk Management Framework (RMF), and Governance, Risk, and Compliance (GRC) practices. With a career spanning over 19 years in the security and compliance space, Johann has held key roles as a Lead 3PAO assessor, chief advisor, and operational leader, bringing a comprehensive understanding of both technical and organizational risk management. 

As CISO, Johann leads stackArmor’s enterprise security strategy, driving risk-based decision-making and guiding the organization in developing secure and resilient solutions. He plays a critical role in informing executive leadership on risk posture, ensuring that cybersecurity is integrated into every aspect of strategic planning and service delivery. Johann is the internal and external face of security for stackArmor, providing trusted guidance to customers navigating complex compliance landscapes 

Copyright © 2025 stackArmor, Inc., a Tyto Athene Company. All rights reserved. All other trademarks not owned by stackArmor are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by stackArmor. This document does not provide you with any legal rights to any intellectual property in any stackArmor product or solution.