If you’ve been preparing for CMMC for what seems like forever, you might then ask yourself, “What’s next? Is continuous monitoring and GRC maintenance all I need to worry about?” The answer is (like most other things in this industry) “it depends”. If your organization does business with the General Services Administration (GSA) and not just the Department of Defense (DoD), the answer might be a pretty emphatic NO.
On January 5, 2026, GSA’s Office of the Chief Information Security Officer dropped Revision 1 of CIO-IT Security-21-112, their procedural guide for protecting Controlled Unclassified Information (CUI) in nonfederal systems and organizations. And while there haven’t been a lot of content and deep dives about it the way there has been for CMMC, it has real, tangible compliance implications for a large chunk of the federal contractor community.
In this post, I want to walk through four questions that I think every compliance professional and IT/GRC manager needs to be able to answer after reading this update. So, let’s take a gander, shall we?
Question 1: What Even Is GSA, and Why Do They Have a Say in My GRC Program?
The GSA is an independent federal agency created in 1949. At its core, GSA exists to serve the rest of the federal government. It manages federal buildings, handles property, and, most relevant to this conversation, serves as the government’s central buyer. We’re talking approximately $66 billion in procurement annually, overseeing contracts for everything from office supplies to complex IT services. If you’ve ever sold something to the federal government through a schedule contract or a Government-wide Acquisition Contract (GWAC), you’ve gone through GSA.
Here’s the part that surprises people: GSA doesn’t just buy things. It also helps write the rules for how everyone buys things. Along with the Department of Defense and NASA, GSA jointly holds statutory authority under Title 40 of the U.S. Code to issue and maintain the Federal Acquisition Regulation (FAR), which is the foundational procurement rulebook for all federal executive agencies. So, when GSA makes a policy decision, its reach extends well beyond its own contracts.
Side note: GSA also has an Acquisition Regulation of its own (the GSAR), which supplements the FAR specifically for GSA contracts; kinda like how the DoD has the DFARS.
Regarding cybersecurity specifically: GSA is both a contracting agency and a data-handling agency. When GSA vendors process, store, or transmit CUI on their own systems (not on government-owned systems), they are expected to complete a fairly involved security approval process before they can receive an award. That process is what this guide governs.
It’s worth being clear about something important here: GSA’s CUI process is internal GSA policy, not law. It doesn’t bind DoD contractors who never hold a GSA contract. It gets into a contract only when a GSA Contracting Officer deliberately includes it, after the GSA CISO approves its use in a specific solicitation. But for organizations on GSA contracts where CUI is involved, this process is very much in effect. And, as of January 5, 2026, it’s been updated in ways that matter.
Question 2: What Changed in the latest Update, and Why Should I Care?
OK here’s the compliance meat of the post. Listen up, pal.
The original guide was released in May 2022 and was built on NIST SP 800-171 Revision 2, the same version that CMMC is based on today. This update aligns GSA’s process to NIST SP 800-171 Revision 3, which was finalized in May 2024. Some additional structural changes were also made including how references got moved to a dedicated appendix, and Appendix C was revised to contain only the “showstopper” requirements (i.e., the ones that will flat-out stop your authorization in its tracks if they aren’t fully implemented.)
The requirement count went from 110 to 97,but don’t celebrate yet.
At first glance, it sounds like a gift. Thirteen fewer requirements! But here’s the catch: NIST didn’t really remove requirements. They folded them into larger, multi-part requirements that are actually more demanding to document and assess. The number of individual assessment objectives increased from 320 to over 509 when you include the requirement to define the new Organization-Defined Parameters associated with the requirements. That’s a significant increase in implementation and assessment burden!
Three brand new control families were added.
Revision 2 had 14 control families. Revision 3 has 17. The three new ones are: Planning (PL), System and Services Acquisition (SA), and Supply Chain Risk Management (SR). These were added specifically to bring 800-171 into closer alignment with NIST SP 800-53 Revision 5. If your current security documentation doesn’t address formal planning processes, acquisition security, and supply chain risk management practices (and many 800-171 System Security Plans (SSPs) don’t), then you’ve got new material to write.
Side note: The Supply Chain Risk Management addition is directly reflected in the January 2026 guide, which now explicitly requires a Supply Chain Risk Management (SCRM) Plan as a mandatory attachment to the System Security and Privacy Plan (SSPP). It must be consistent with NIST SP 800-161. Don’t forget to look into this as this is probably very new territory for many contractors who’ve not had to deal with Supply Chain Risk Management in a formal way thus far!
The showstoppers remain, but some requirements are now sharper.
The nine showstopper categories, the non-negotiable requirements that will result in denial of authorization if not fully implemented, are listed in Appendix C of the guide. They cover Access Enforcement, Remote Access, Multi-Factor Authentication, Vulnerability Scanning, Boundary Protection, Encryption in Transit and at Rest, Cryptographic Protection, Flaw Remediation, and Unsupported System Components. These ought to be pretty familiar concepts but several now include ODPs, meaning vendors must define and document specific frequencies, timeframes, or cryptographic types within their SSPP so there’s probably more work to do now to ensure they’re in place if all you’ve had to focus on up to this point was NIST SP 800-171 Rev 2 and CMMC. Keep an eye out for any guidance provided by GSA for what must be defined for such ODPs. Regarding encryption, GSA says FIPS-validation is required to be used “wherever possible”, an interesting caveat codified in official documentation that we’ve not had the luxury of in the CMMC world thus far.
Two brand-new showstopper conditions were effectively added via the technical tables.
The guide introduced something I think is significant in its Key Technical Security Considerations table: CISA Known Exploited Vulnerabilities (KEV) that cannot be corrected are now explicitly a showstopper condition. The CISA KEV catalog is a living list of actively exploited vulnerabilities. If you have them in your environment and can’t remediate them, you will not be approved. Full stop.
Similarly, residual End-of-Life software vulnerabilities that cannot be corrected are also a showstopper condition. If your environment is running unsupported software with open vulnerabilities and you can’t fix it, that’s a blocker for your authorization, not just a finding to add to your POA&M.
These two additions are significant because many organizations carry legacy technical debt. Now that debt can directly prevent authorization rather than just being flagged for remediation, people in decision-making roles will have a lot to think about.
Vulnerability remediation now has explicit timelines.
The Architecture Critical Security Capabilities table in the guide now codifies specific remediation windows: Critical (Internet-facing) vulnerabilities must be remediated within 15 days; Critical/High within 30 days; Moderate within 90 days; Low within 180 days. These aren’t suggested best practices; they’re the lens through which GSA’s security team will evaluate your Vulnerability Management capability during the Architecture review phase.
Configuration scanning has a minimum pass rate.
Configuration/compliance scans must meet an 85% compliance threshold, meaning each scanned component must pass at least 85% of the applicable configuration checks in its applicable CIS benchmark or NIST guideline. So, if you’re like many of the organizations that have been building out your own baselines for your 3.4.1 and 3.4.2 requirements and haven’t been using benchmarks or guidelines from DISA or CIS, then this might be an entirely new world you’re about to enter. Below 85%? You’ve got a documented finding, and the guide is explicit that vague justifications like “configuration setting not applicable” will not be accepted.
If you’re reading all of this and thinking, “but how does this compare to what I’m already doing for CMMC?”, good. That’s exactly where we’re headed! In Part 2, we’ll break down how GSA’s process differs from CMMC, what it looks like if you’re managing both, and what you should do about all of this.
References