Demystifying DoD Cloud Security: SRGs, STIGs, and CMMC Alignment

Eric Marquette

Welcome back to CMMC Unlocked! Today we’re going deep on DoD cloud security—SRGs, STIGs, and how it all connects with CMMC. Actually, I was just thinking about this classic pain point we see everywhere: Last month, I had a Mission Owner absolutely swamped by all the acronyms. She asked, "Eric, what’s the difference between an SRG, a STIG, and all these Impact Levels—are they just government word salad or do they matter?" And you know, it’s fair, because for anyone entering this space, it feels like learning a new language.

Ruby Sturt

Totally! And it’s not just alphabet soup, it’s, like—if you don’t know how they all fit, you’re not even sure what security you’re responsible for. At the end of the day, everyone—including DoD folks—is just trying not to blow a contract over a missed baseline or a misconfigured cloud.

Paul Netopski

Right. This happens all the time. The big thing is understanding that cloud and cybersecurity compliance have evolved because they have to—threats, data types, and technology keep moving. The DoD and the rest of the federal government realized you can’t secure a massive, hybrid, cloud-based enterprise with 1990s checklists. So, now we have this pretty complex ecosystem: you’ve got Security Requirements Guides (SRGs), which set out what needs to be done at a high level, Security Technical Implementation Guides (STIGs) that tell you exactly how to do it, and all that layered with cloud Impact Levels based on the sensitivity of what you’re running. All interlinked, but all their own thing.

Roz the Rulemaker

And let’s not forget the regulatory backdrop, right? SRGs and STIGs don’t just pop out of nowhere—they’re anchored in a bunch of statutory and executive requirements. DODI 8500.01 actually delegates a lot of the mechanics to DISA and NSA, and says: “every IT system under DoD shall comply with the applicable SRGs and STIGs.” So, this is not just best practice, it’s contractual, regulatory, and audit fodder. And that’s even before you get to how these things thread into CMMC.

Eric Marquette

Exactly, and as we set the stage today, we wanna unravel why it keeps changing, how SRGs and STIGs interact, and why compliance isn’t just a checklist—it’s about understanding your real security responsibilities. Let’s get into the building blocks themselves.

Ruby Sturt

Alright, so let’s try to keep this straight—SRG versus STIG. SRG is, like, the broad requirements for a whole class of technology, and then you’ve got the STIGs, which are super specific, right? How does that actually play out, Paul?

Paul Netopski

Yeah, let me clarify: SRGs are collections of requirements for a given technology family—think, “here are the rules for cloud computing, broadly.” They’re driven from the underlying IA controls, like NIST SP 800-53, and mapped out as CCIs, or control correlation identifiers. Now, STIGs? They get right into product-specific detail, giving you check and fix guidance that’s actionable—how you actually implement what’s in the SRG for, say, AWS or a CISCO appliance. So, SRG says “you must have X types of access controls,” and the STIG says, “configure password length in these precise fields, with these values.”

Roz the Rulemaker

I see a ton of headaches with organizations struggling when that hierarchy isn’t clear. People try to do piecemeal compliance, chasing the most recent checklist, but if you don’t map your controls all the way from the core SRG requirements—using CCIs as your connective tissue—your assessment documentation is likely going to fall short, or your STIG exceptions won’t make sense to an auditor. It’s gotta be systemic. Both for accuracy and for your own sanity at contract time.

Eric Marquette

And that’s where a lot of folks go wrong. They apply a STIG or two, think they’re set, but the SRG sets the boundary—without mapping from CCI up to your policies, you’ve just checked boxes without context. You need the whole hierarchy: CCI → SRG → STIG. And, for cloud, these don’t live alone; Impact Levels and customer responsibility matrices are built off these building blocks, so let's pivot to what’s changed in the latest SRG and why.

Paul Netopski

Let’s step through what’s actually new. The most recent Cloud Computing SRG revision, just released, marked a shift from NIST SP 800-53 Rev 4 to Rev 5 as the foundational framework. That’s huge for contractors. Now, if you’re supporting Impact Level 5 systems or National Security Systems (NSS), you’re facing a high baseline—no more moderate. CNSSP-32 now says: IL5/NSS mandates high, full stop. This raises the bar for controls—think more rigor in areas like supply chain, personnel assurance, and advanced monitoring.

Ruby Sturt

Right, and the SRG itself comes in two flavors—the Mission Owner doc and the CSP doc. The Mission Owner doc lays out your responsibilities for stuff like CAC/PKI, endpoint security, cloud storage, encryption, Active Directory... all that needs to be aligned with what the CSP is providing. But the CSP doc now explicitly says: for IL5 and above, you can’t skim on the baseline. It’s not "pick and choose" anymore.

Roz the Rulemaker

From a policy oversight view, this is a deliberate tightening. CNSSI 1253 overlays and the change in minimums reflect a recognition that NSS or anything above IL4 carries both legal and operational implications. As we see in the recent revision history, things like the handling of encryption keys, cross domain solutions, and remote maintenance logging are now more explicit. If you’re on the hook for a system considered NSS, the days of treating the cloud as just “remote storage” are long over—the whole approval chain expects that you’ve scoped, documented, and implemented at the high baseline.

Paul Netopski

Exactly. For contractors supporting NSS or IL5, anticipate more room for findings, longer assessment timelines, and the need for a more robust documentation package—potentially reworking entire SSPs that were built around Rev 4 moderate assumptions. Build this into both your compliance planning and contract negotiation cycles.

Eric Marquette

And building on what we talked about in Episode 7—don’t wait for a new RFP or for a required re-assessment; get your gap analysis jumpstarted now, especially around things like cryptography and personnel screening, which are very different between moderate and high baselines. Let’s bring this into the real world for cloud providers and mission owners who actually have to navigate these Impact Levels.

Ruby Sturt

I think everyone’s favorite compliance minefield is the Impact Level table. We get IL2, IL4, IL5, and IL6, right? IL2 is the "public info" bucket, but from IL4 up, you’ve got CUI and even National Security stuff. So, say I’m a Mission Owner—what’s my practical impact? Where do people usually trip up?

Paul Netopski

Biggest issue? Not mapping your data and understanding which Impact Level you really need. IL2 is for non-CUI, so it has minimal requirements—FedRAMP Moderate gets you there automatically with no need for additional DoD PA. But once you jump to IL4 or IL5, you’re in CUI or NSS territory—FedRAMP Moderate or High isn’t enough alone; now you need FedRAMP+, overlays, plus all the DoD-specifics the SRG calls out. For IL5 and above, you also need physical separation from non-federal tenants.

Roz the Rulemaker

Getting SLA boundaries right is critical. Take, for example, a SaaS versus IaaS scenario: Who’s controlling the encryption keys at rest? If the customer (Mission Owner) assumes the CSP is handling it, but the contract is vague, you might violate IL4/IL5 requirements without realizing it. The contract needs to specify details like key management, incident response roles, audit log access, and data spillage procedures. We see contracts stumble or get delayed when an SLA is ambiguous—I've reviewed cases where the contract nearly got yanked at award stage because it didn’t clearly state who was responsible for secure key management or data location jurisdiction.

Eric Marquette

And it’s not just theory. Ruby, I know you chatted with a contractor the other week where the LOE got kicked back because IL4 data ended up on IL2 infrastructure during migration. It all comes down to practical mapping—if you don’t get your data inventory right and know what bucket it fits in, you can end up noncompliant by surprise.

Ruby Sturt

Exactly! And, like, a ton of people don’t realize—if you miss the boundary, you get into this weird zone where you’re responsible for something but don’t actually have the access or visibility. That’s why those SLAs and customer responsibility matrices matter so much. You’ve gotta spell out who’s patching what, who keeps logs, who holds encryption keys, and what processes are in place for a data spill.

Paul Netopski

And don’t think you can plug and play—if it’s IaaS or PaaS, the mission owner keeps a lot of the risk, but if it’s SaaS, you depend on the CSP for way more. Always document the split and make it explicit—assessors will want to see it.

Roz the Rulemaker

In many cases, what’s in the contract or SLA can trump what people think they’re buying. If it isn’t written, an auditor can’t accept “trust me, the CSP does that.” Put it in writing and map it to the controls.

Paul Netopski

The so-called “shared responsibility model” sounds simple, but it can get messy—fast. Some controls move to the CSP—like physical infrastructure, underlying hypervisors, and sometimes patching of managed services. But the mission owner is still on the hook for application layer, data governance, endpoint security, user management, and even port and protocol registration with DoD.

Ruby Sturt

Here’s where people get tripped up: They assume “cloud” means CSP does all the security. Nope! Who’s responsible for continuous monitoring? Who maintains the ATO package? Who makes sure logging isn’t lost in a “black box”? You need a clear, mapped-out customer responsibility matrix—otherwise, come assessment time, you’ll find you have a giant evidence gap.

Roz the Rulemaker

Yeah, authorities see this all the time. Organizations hand in customer responsibility matrices or SLAs that are generic, or worse, incomplete. Assessors need to see exactly what you’re responsible for versus what the CSP handles, and these split responsibilities need to show up not just in your docs but in the contract language too. And if you get customer responsibility wrong, it’s not just theoretical—it shows up in real incidents. We’ve reviewed major breach post-mortems where the “I thought you were tracking that” excuse didn’t fly, and the contract owner took the regulatory hit.

Eric Marquette

It’s never just about theory, it’s about the line of accountability. And the more you clarify that—and keep it up to date as the architecture changes—the easier your CMMC and DFARS evidence will be. Otherwise, you’re left with finger pointing and audit drama, not actual compliance.

Roz the Rulemaker

Let’s get clear on the alphabet—FedRAMP, FedRAMP+, DOD PA. FedRAMP is the government’s baseline for cloud security, yes, but as we’ve seen, for DoD use, FedRAMP Moderate alone is not always enough—especially for CUI and above. FedRAMP+ means you take the FedRAMP baseline and add all the extra controls the DoD or CNSSI overlays require, like for IL4, IL5, or IL6. The DOD Provisional Authorization (PA) is what shows DoD’s acceptance that a cloud service can actually host DoD missions at that Impact Level.

Paul Netopski

And most folks mix them up. Contractors often think, "Oh we bought FedRAMP Moderate, check the box, we’re good." But not quite—especially if DFARS 252.204-7012 is in scope. The covered defense information (CDI) or CUI still requires your cloud service provider to meet the DOD PA requirements for the right Impact Level. For IL4 and above, it’s not enough to show a FedRAMP cert—you need to address DOD-unique controls, the overlays, and in some cases, even more, like the specific personnel screening, key management, and incident response procedures.

Ruby Sturt

And this isn’t hypothetical. Paul, you had a recent case where a provider had everything buttoned up—except their CRM didn’t match the DoD's required FedRAMP+ parameter values. That almost tanked the entire Provisional Authorization. People assume if it’s FedRAMP Moderate, they’re home free—but IL4 and IL5 ratchet things up. If you haven’t validated those extra controls, you’re not compliant, period.

Paul Netopski

Yep, that CRM—Customer Responsibility Matrix—must match the controls required in the PA. Any mismatched controls or unclear parameter values means you could fail the DOD PA, or get a conditional that puts your contract at risk. Make sure you’re using the actual, current parameter values—don’t work off old templates.

Eric Marquette

And building on that—if your cloud provider can’t furnish a body of evidence showing both equivalency to FedRAMP Moderate and meeting any