Listen

All Episodes

Eliminating the Line: Rethinking Basic and Derived Security Requirements in NIST SP 800-171 Revision 3

This episode unpacks the elimination of the basic and derived security requirement distinction in NIST SP 800-171 revision 3, the assessment methodologies surrounding them, and the practical effects on DoD contractors, especially primes managing supplier risk. Our hosts dive into how the structure of NIST SP 800-171 assessments has evolved, the rationale for the new approach, and what subcontractors and primes alike can expect under the updated rules.

This show was created with Jellypod, the AI Podcast Studio. Create your own podcast with Jellypod today.

Get Started

Is this your podcast and want to remove this banner? Click here.


Chapter 1

Breaking Down Basic vs. Derived Requirements

Paul Netopski

Alright—let's get into it. So, before Revision 3, NIST SP 800-171 had this split between Basic and Derived security requirements. The Basic ones were really the fundamental building blocks for securing CUI—stuff like "limit system access to authorized users" or "sanitize system media before disposal." They actually map directly back to FIPS 200’s high-level security requirements, which come straight from federal law. I always tell clients—if you miss a Basic requirement, you’re usually undermining your whole compliance program. That’s not just me waving my hands in the air either; the DoD weighted scoring methodology gives more points to those requirements. If you forget something like 3.1.1, the one about limiting system access, that’s a five-point deduction. That’s significant, and it’s there for a reason. Everything else kind of falls apart if you get the basics wrong.

Eric Marquette

Yeah, Paul, and from the media side—back when Rev. 2 was the norm, I’d get these vendor security questionnaires from the big primes almost every quarter. Like clockwork—"Please confirm you’ve implemented 3.1.1, 3.3.1, 3.8.3..." I mean, the set always focused on the Basic requirements in particular. And if you couldn’t prove you had those nailed, you could just forget about being considered for a contract—especially as a small supplier. It really drove this whole compliance culture where everybody, even the Tiniest Mom n’ Pop IT shop, was scrambling to fill out spreadsheets to prove they had just the Basic requirements covered. Sometimes it felt less like security and more like risk paperwork, honestly.

Roz the Rulemaker

Eric, that’s such a classic downstream effect of how the regulations and assessments were structured. The primes get this directive from the top: minimize supplier risk. And what’s easiest to check? The Basics. It didn’t matter if you had some fancy endpoint security if you couldn’t prove you were meeting the foundational stuff the federal language cared about. And Paul, your point about weighting is important. Derived requirements—those are layered in to cover specific scenarios, and they’re important, but the assessment methodology literally made the Basics the backbone. You fail those? There’s no trust left for anything else in the stack.

Paul Netopski

Exactly, Roz. It’s why, for years, this distinction between Basic and Derived just dominated every conversation about supplier risk—even internally. And primes have been laser-focused on not having a weak link in their supply chain. No one wanted to be the headline for "Prime loses CUI due to sub failing 3.1.1." I mean, maybe I’m exaggerating a bit, but you get the drift.

Eric Marquette

Nope, you’re spot on. Primes cared about Basics because the system’s only as strong as its weakest supplier—and those assessments landed right back on that point. I’d say, half my email inbox from primes was some flavor of "Hey, can you show you’re doing these specific handful of controls?"

Roz the Rulemaker

It's a funny artifact of the rule structure. Once you create a two-tier system—Basic versus Derived—you encourage everyone in the chain to focus on what counts most for the scorecard, even if that’s not always optimal security in real life. But it sure was the reality for years.

Chapter 2

Assessment Methodologies and Scoring: From Self-Assessment to SPRS

Eric Marquette

Let’s shift gears a little—because we talked about scoring and requirements, but the assessment methodology itself is worth a closer look. Paul, you want to break down those three assessment levels under the DoD’s methodology?

Paul Netopski

Sure thing. So, in the official DoD method, you’ve got three assessment levels: Basic, Medium, and High. The Basic one’s just a self-assessment. You, as the contractor, review your System Security Plan and declare—based on evidence—how many requirements you've actually implemented. Confidence there is low, because nobody’s double-checking your work yet. Then there’s the Medium level—that’s when DoD folks who’ve been officially trained actually look at your SSP. They dig into how you claim to meet each requirement, and they might ask tough questions if things don’t add up. That gives the DoD medium confidence in your score. Finally, the High level is either an on-site or a virtual assessment. It’s thorough—lots of document reviews, interviews, actual validation. The High assessment is a big deal in terms of scrutiny. Naturally, this brings the highest level of confidence in the results, but also the most stress for the organization being assessed.

Roz the Rulemaker

What’s fascinating, Paul, is how the scoring template doesn’t treat all requirements equally. I mean, not at all. Requirements like multi-factor authentication or FIPS-validated encryption—those get more weight. Like, if you haven’t done MFA for all the accounts you’re supposed to, you’re not just losing a trivial point or two—that’s minus five, or minus three if you’ve only partially implemented. The same for those foundational Basics. I always say—it’s the blueprint for a "first-things-first" compliance mindset. You can’t just cherry-pick easier controls and call it a day; you have to get the critical stuff right or your score just tanks.

Paul Netopski

Exactly, Roz. And here’s something contractors still get tripped up with: when primes ask for your "SPRS score," they’re usually laser-focusing on where you stand with those highest-impact controls—again, usually the Basics—and a couple of heavy-hitter Derived controls like MFA. The DoD’s Supplier Performance Risk System, or SPRS, is the repository for all these scores at any assessment level. So, when primes audit their supply chains, they don’t just want to know if you filled out a security self-assessment—they want to know if you flunked any of the big controls. That can have serious implications for business, especially for smaller subs who can’t afford to let key requirements slip, even if implementation is hard or expensive.

Eric Marquette

And I’ll tell you—those SPRS self-reporting requirements create ripple effects. I’ve seen some organizations fudge things to look better on paper, but that usually backfires sooner or later. Primes get spooked by low scores or missed Basics and will ask for proof or even just skip you. There’s a lot riding on understanding which controls are weighted more and making sure you have the stories and evidence to back it up.

Roz the Rulemaker

It’s also worth noting—especially for the compliance and legal folks listening—that posting those SPRS scores isn’t optional if you’re handling CUI on a DoD contract. It’s a contract requirement now, and primes can’t really skip this due diligence. So, if you’re thinking of just "being good enough," remember, the scoring itself was invented to establish a hierarchy—some controls are nonnegotiable, and there’s real accountability behind the numbers in SPRS.

Chapter 3

Revision 3: No More Basic/Derived—What It Means and What's Next

Roz the Rulemaker

Alright, now for the big one—NIST SP 800-171 Revision 3. The headline here: the distinction between Basic and Derived requirements is just gone. They cut it entirely. Instead, all requirements are now aligned directly to the SP 800-53 control language. That means every requirement has the same standing, and there’s no two-tier system anymore. This change was driven by feedback from the field—there was just a ton of confusion around what counted as Basic versus Derived, and organizations found they were overwhelmed by different frameworks. With Rev. 3, everything is recast using only SP 800-53 as the single authoritative source. It’s really a push for more specificity, less ambiguity, and way more consistency across assessments.

Paul Netopski

Yeah, Roz, and I saw it play out in real time. My team used to have two different sets of supplier questionnaires—one focused on the Basics, and another deeper dive for Derived. But as soon as Rev. 3 got released, we completely retooled the process. Now, our questionnaires just treat every requirement according to its exact control number and language. It’s a lot clearer for our subs—less "Are you good on the Basics?" and more "Show us how you’re holistically implementing all requirements, period." That shift has actually made life easier, both for us as primes and for our suppliers who used to get stuck on definitions or different scoring logic.

Eric Marquette

And for anyone confused about why this matters—think about the compliance headaches in the past. If you weren’t totally clear on which controls were Basic or Derived, you could answer all the questions right and still get dinged. Now, there’s just one catalog, one language, which aligns with SP 800-53 and the CUI overlay. Honestly, it should help smaller shops who don’t have the resources to track two different compliance tracks or read regulatory tea leaves. More clarity means fewer “gotchas.”

Roz the Rulemaker

Keep in mind, too, there are new requirement families and capabilities in Revision 3, reflecting how practice has evolved. If you haven’t looked at the new Supply Chain Risk Management family, or the Planning and System and Services Acquisition requirements—they’re direct responses to seven years of lessons learned and public feedback. It’s also about driving everyone toward a common assessment process that’s just less subjective, less open to interpretation. That means—hopefully!—less confusion when auditors come knocking and more predictability across the board.

Paul Netopski

Right, it’s all about implementation clarity now—no more confusion over what “basic” means, no getting hamstrung by score weights on just a handful of controls. Honestly, it’s a positive direction for everyone—especially primes managing dozens or hundreds of suppliers. I wouldn’t say it’s solved every challenge, but assessment conversations are definitely more grounded in specifics rather than in how you interpret one word versus another.

Eric Marquette

I guess the takeaway here is if you’ve been hanging on to the basic/derived split like it was gospel, it’s really time to move on. Rev. 3’s the new North Star, and the push is toward holistic, clear, and consistent controls—as much for the sanity of assessors as for suppliers. This is one part of compliance I’m actually looking forward to seeing in action more broadly.

Roz the Rulemaker

Absolutely. And for our listeners, next episode we’ll unpack what supply chain security really looks like under these updated rules—so stick with us for practical case studies and actionable guidance. Paul, Eric, always great having these discussions with you.

Paul Netopski

Thanks, Roz. Looking forward to digging even deeper next time.

Eric Marquette

Always a pleasure. Take care, both of you—and thanks everyone for tuning in to "CMMC Unlocked." Talk soon!