If you've been focused on CMMC as your primary federal cybersecurity obligation, the General Services Administration (GSA) just complicated the picture.

On January 5, 2026, GSA released a new procedural guide requiring contractors to protect Controlled Unclassified Information (CUI) under a framework that differs from CMMC in ways that matter: it's based on a newer version of NIST 800-171, it requires independent assessment across the board, and it's already in effect. No transition period, no phase-in, no advance notice.

Here's what the framework requires, where it diverges from CMMC, and what you should be doing about it now.

What to do if you're already working towards CMMC

If your organization is already deep into the CMMC compliance process, that effort is still valuable. But it doesn't map over cleanly.

Here is where the gaps show most often:

• CMMC is currently built around NIST SP 800-171 Rev. 2, while GSA’s process uses NIST SP 800-171 Rev. 3 requirements and assessment procedures. Rev. 3 adds new controls, reorganizes existing ones, and introduces Organization-Defined Parameters that require you to explicitly document how each control is implemented and demonstrate it's being followed. Controls you already have in place under Rev. 2 may need more rigorous documentation and evidence to satisfy Rev. 3 assessment procedures.
• CMMC Level 1 and certain Level 2 contracts allow for a self-assessment, while GSA’s guide centers Phase 3 and the recurring SAR on assessment by a 3PAO or independent security assessor.
• DFARS and CMMC incident reporting generally allow 72 hours, while GSA now requires reporting within one hour of identification by the vendor’s top-level CSIRT.

The good news is that your CMMC work isn't wasted, and many control themes still carry over. But you should assume you need a fresh gap assessment against Rev. 3 and GSA’s process rather than assuming your current program is enough.

*Based on current guidance as of March 2026. Interpretation and enforcement practices may evolve.

What GSA’s CUI requirements include

GSA's new requirements draw from three well-known NIST standards: 800-171, 800-172, and 800-53.

NIST 800-171 Rev. 3 provides the foundation, organizing requirements into 17 control families covering areas like access control, configuration management, incident response, supply chain risk management, and system and communications protection. If you've been working against the 14 domains in Rev. 2, that reorganization alone means your existing control mapping will need to be revisited before you can claim GSA compliance.

Where contracts involve high-value assets or critical programs, GSA layers in additional requirements from NIST 800-172. And if your work involves personally identifiable information alongside CUI, selected privacy controls from NIST 800-53 Rev. 5 apply as well.

The bigger operational shift, though, is how Rev. 3 expects you to document and prove compliance. A substantial number of controls across those 17 families contain what the standard calls Organization-Defined Parameters — essentially placeholders that your organization has to convert into specific, enforceable commitments in your System Security Plan. GSA won't fill these in for you, and an assessor will be looking for them.

Here's what that looks like in practice: if a control requires you to define a review frequency, you can't just say you review it "regularly." You have to commit to a specific value (every 14 days, for example), document it in your SSP, implement it consistently, and be prepared to show evidence that it's actually happening. That's the pattern Rev. 3 introduces across the board: a shift from general intent to explicit, testable implementation detail.

For contractors coming from Rev. 2 or CMMC, the practical implication is this: controls you already believe you've satisfied may not hold up under Rev. 3 assessment procedures. It's not just that there are more controls, it's that the evidentiary bar is much higher.

The 5-Phase GSA CUI compliance process

One thing that sets GSA's framework apart is that it doesn't just tell you what to implement, it also tells you how to get there.

Rather than handing contractors a control list and leaving the rest open to interpretation, GSA defines a specific five-phase process derived from the NIST Risk Management Framework (NIST RMF). Each phase has defined deliverables, owners, and timelines so you're not left guessing about what "compliant" looks like at each stage.

Phase 1: Prepare

Phase 1 includes foundational scoping and readiness work. GSA expects contractors to define the system boundary, represent the solution architecture, identify external and leveraged services, and document whether the environment uses FedRAMP-authorized services or other external services that will require risk review.

This is also where the cloud and integration picture starts to matter. If the system is built on a FedRAMP-authorized IaaS provider, the services in use must also be FedRAMP authorized. If non-FedRAMP-authorized IaaS is involved, GSA says it will evaluate those services case by case.

Phase 2: Document

In Phase 2, the contractor develops the System Security and Privacy Plan (SSPP) and related attachments. Where privacy is implicated, the process also includes a Privacy Threshold Assessment (PTA) and, if triggered, a Privacy Impact Assessment (PIA) reviewed by GSA’s privacy office.

The guide makes clear that the SSPP must describe how security and privacy requirements are implemented, partially implemented, or planned to be implemented across all in-scope assets. This is where organizations often underestimate the level of specificity required.

Phase 3: Assess

Phase 3 is where GSA’s process most clearly departs from a simple self-attestation model. The guide says that during this phase, the SAP is prepared, an independent assessment is performed, POA&Ms are developed, and a SAR is produced.

The monitoring section reinforces this by requiring a SAR every three years, or when there is a major change, based on an assessment conducted by a 3PAO or independent security assessor using NIST SP 800-171A Rev. 3 procedures.

Phase 4: Authorize

GSA’s authorization step is not a traditional ATO. The guide states that GSA will prepare a Memorandum for the Record (MFR) concerning the use of the vendor system, and that the GSA CISO will decide whether to execute the MFR if the package provides sufficient evidence that CUI is appropriately protected.

That matters because it centralizes the authorization decision and puts a premium on accurate documentation, credible assessment results, and honest treatment of residual risk.

Phase 5: Monitor

Authorization is not the end of the process. GSA requires continuing deliverables after approval.

Quarterly deliverables include the most recent web application and operating system vulnerability scan reports, POA&M updates, and a shared-drive access review. Annual deliverables include an updated SSPP and updated PTA/PIA as necessary. Every three years, or when there is a major change, the contractor must provide a new SAR based on a 3PAO or independent assessor review.

That is a much more operational compliance model than many contractors are used to.

Showstopper controls for GSA CUI compliance

Appendix C identifies specific requirements that GSA treats as showstoppers, meaning they're baseline conditions for authorization. If you have a gap in any one of them, it can block approval regardless of how strong the rest of your program is.

Here’s what each one actually requires in practice, and why GSA treats them as non-negotiable.

03.01.02: Access Control (Transaction and Function Control)

This control goes beyond restricting who can log in. It governs what users can actually do once they're inside, limiting access to specific transactions, functions, and data based on role and enforcing least privilege at a granular level.

The reason GSA treats this as a hard requirement is straightforward: excessive permissions are one of the most common causes of data exposure. A compromised account that can move freely across systems or access functions it shouldn't essentially defeats every other control you've put in place. Tight, role-based access isn't an enhancement; it's the foundation everything else rests on.

03.01.12: Remote Access

Remote access is one of the most common entry points for attackers, which is exactly why GSA won't authorize a system where it's loosely controlled. This control requires that all remote access to CUI environments, including VPNs, remote desktop, and cloud-based access paths, be explicitly authorized, encrypted, and actively monitored, with clear controls around who can connect and under what conditions.

Ad hoc or informally managed remote access arrangements won't pass. If your organization expanded remote access during the pandemic and never formally tightened it back up, this is where that shows.

03.05.03: Multi-Factor Authentication

No password policy however strict, is sufficient on its own. MFA is required for all access to systems containing CUI: hardware token, authenticator app, biometric, or equivalent. Single-factor authentication is a disqualifier regardless of how complex your password requirements are.

GSA treats MFA as a foundational control rather than an optional enhancement, and the reasoning is hard to argue. Credential compromise is one of the most prevalent attack vectors in federal contractor breaches. MFA doesn't eliminate that risk, but removing it creates an exposure that no other control adequately compensates for.

03.11.02: Vulnerability Monitoring and Scanning

This control requires an active, ongoing vulnerability management program with defined scanning cadence, documented results, and a clear remediation workflow. Occasional or ad hoc scans don't satisfy it.

Unpatched vulnerabilities are among the easiest ways for attackers to gain access to a system, and GSA's position is essentially this: if you're not continuously finding and addressing known weaknesses, the strength of your other controls becomes largely irrelevant. Identification without remediation is not a program. It's a paper trail.

03.13.01: Boundary Protection

A weak or undefined boundary means attackers don't need to break into your environment, they can simply walk into it. This control requires that the perimeter around your CUI environment be clearly defined and actively defended with firewalls, intrusion detection or prevention systems, and network segmentation that separates CUI systems from the rest of your environment.

What GSA is looking for here is evidence that your CUI environment is a controlled system, not just a section of a flat network with a label on it.

03.13.08: Network Communication by Exception (Deny-by-Default)

This is the control that catches the most organizations off guard, because it requires a fundamental shift in how your network is configured. Deny-by-default means all communication is blocked unless explicitly authorized, which is the opposite of the "allow unless blocked" posture that many environments still run on.

If your team has to think about whether your network currently operates this way, it probably doesn't. Auditing and reconfiguring network communication policies is often one of the more time-consuming remediation tasks in a compliance program, which is part of why GSA made it a gating requirement rather than a nice-to-have.

03.13.11: Cryptographic Protection

CUI must be encrypted in transit and at rest using FIPS-validated cryptographic modules wherever possible. Data in plaintext, whether moving across a network or sitting in storage, is out of compliance.

Encryption matters most precisely when other controls have failed. If an attacker gains access to properly encrypted data without the keys, the practical impact is limited. If the data isn't encrypted, access equals exposure. GSA treats this as non-negotiable because it's the last meaningful line of defense when everything else has gone wrong.

03.14.01: Flaw Remediation

Identifying vulnerabilities is necessary but not sufficient. This control requires a formal patch management process with defined remediation timeframes and the ability to demonstrate that vulnerabilities are actually being resolved on schedule, not just logged.

Known vulnerabilities that stay unpatched are effectively open doors. GSA's remediation timeframes are aggressive, with critical findings on internet-facing systems requiring resolution within 15 days. Assessors will also be looking at your patch history, not just your policy documentation.

03.16.02: Unsupported System Components

Once a vendor stops issuing patches and updates, vulnerabilities accumulate with no path to remediation. That's why GSA draws a hard line here: any system component no longer supported by its developer, vendor, or manufacturer must either be replaced or covered by a documented risk mitigation strategy or alternative support arrangement.

Running end-of-life technology in a CUI environment isn't just a risk management issue. Under this framework, it's an authorization question. Unsupported components that can't be remediated can't be made compliant, and an environment built on them won't be approved.

Why these controls are treated differently

Taken together, these controls define the minimum conditions for a defensible security baseline. They map directly to the most common failure points in real-world environments, including excessive access, weak remote entry points, lack of MFA, unpatched vulnerabilities, poor segmentation, overly permissive communication, unencrypted data, broken remediation processes, and unsupported systems.

GSA’s position is straightforward: if any of these are missing or incomplete, the system is not secure enough to handle CUI, regardless of what else is in place.

The 1-Hour incident reporting requirement

This is the requirement that will likely get the most attention.

The guide states that vendors must report all incidents, including suspected or confirmed events that could result in loss of confidentiality, integrity, or availability, to the GSA ISSO, ISSM, COR, and GSA Incident Response Team within one hour of being identified by the vendor’s top-level CSIRT.

The guide also instructs contractors not to delay reporting to collect additional details. That makes this an extremely compressed operational window compared with other frameworks.

To put that in concrete terms: it's 2 AM on a Saturday. Your monitoring tool fires an alert. You have 60 minutes to notify the GSA ISSO, ISSM, Contracting Officer's Representative, and GSA Incident Response Team. That's not 60 minutes to investigate and then decide whether to report. That's 60 minutes to report, period.

In practice, this raises immediate questions:

• Who is watching your environment after hours?
• Who makes the call that something has crossed the threshold into reportable?
• Does your incident-response team already know exactly whom to notify at GSA?
• Do you have a prebuilt reporting workflow, or are you expecting someone to draft one under pressure?

Outside legal commentary has highlighted how demanding this timeline is. Holland & Knight noted that the one-hour requirement may cause some contractors to rethink whether pursuing GSA work is worth the operational burden.

For smaller contractors especially, this requirement may push incident monitoring and response from a “business hours” function into a true 24/7 operational need.

Who's affected by GSA’s CUI requirements?

This does not just apply to IT vendors or cybersecurity firms.

GSA’s guide applies to nonfederal systems and organizations handling CUI under GSA arrangements, and the boundary of what counts as in-scope may be broader than some contractors expect.

That can include a much broader range of organizations than many contractors initially expect. Professional services firms, for example, may fall within scope if they handle CUI during consulting engagements, assessments, or operational support. Engineering and technical services firms are often included as well, particularly when their work involves controlled technical data tied to federal systems or infrastructure.

Facilities and infrastructure-related contractors can also be affected if they have access to sensitive operational information, such as building systems, layouts, or security controls. And importantly, this doesn’t stop at the prime contractor level. Subcontractors supporting GSA work are frequently brought into scope through flow-down requirements, meaning even organizations that don’t contract directly with GSA may still be required to meet these CUI protection standards.

If you are a subcontractor and CUI passes through your systems as part of contract performance, you should assume this deserves immediate review with the prime and with counsel.

Cloud service provider requirements under GSA CUI

One of the easiest mistakes to make is assuming that using a government cloud or a FedRAMP-authorized environment automatically makes you compliant. It does not.

The guide says that where the system is built on a FedRAMP-authorized IaaS provider, the services in use must also be FedRAMP authorized. It also says GSA will evaluate each non-FedRAMP-authorized IaaS service on a case-by-case basis. For external non-FedRAMP cloud services and SaaS integrations, the contractor must document them within the boundary and explain how they are being used. The guide also notes a preference for SaaS solutions identified as FedRAMP authorized in the FedRAMP Marketplace, with other SaaS considered on a risk basis.

The core point is that the provider’s authorization status is only part of the picture. You still have to show that your own architecture, access controls, encryption, logging, vulnerability management, and boundary decisions meet GSA’s expectations.

No phase-in period

One of the clearest contrasts with CMMC is rollout style.

CMMC has a formal phased implementation schedule. GSA’s guide was issued through GSA’s procedural guidance process and is already posted on GSA’s procedural-guides page. External legal analysis has described the rollout as notably quiet and lacking an advance comment process or press announcement.

That does not necessarily mean every current GSA contractor will feel the impact on the same day. But it does mean contractors should not assume they have years of lead time before these expectations show up in a contract action or review.

False Claims Act risk

For many contractors, the technical requirements will not be the only concern. The legal risk may matter just as much.

Holland & Knight’s analysis specifically flags the potential for False Claims Act exposure in this context, especially where a contractor makes representations about compliance that are not supported by the actual state of controls, documentation, or remediation. The FCA can involve treble damages and significant per-claim penalties.

The practical takeaway is straightforward: do not certify compliance you do not have. If your environment still has material gaps, unsupported components, unresolved findings, or weak narratives in the SSPP, those issues should be remediated and accurately documented, not smoothed over.

What federal contractors should do now

Given that GSA’s CUI process is already in place, the priority isn’t understanding the requirements. It’s figuring out how your organization lines up against them and where the gaps are.

Here’s where to focus first.

Determine where CUI actually exists in your environment

Start by mapping your GSA-related work honestly. Identify which contracts involve CUI, where that data flows, and which systems touch it. Many organizations discover their exposure is broader than expected, especially across shared systems or subcontractor relationships.

Run a gap assessment against NIST SP 800-171 Rev. 3

If your program is aligned to Rev. 2 or based on a CMMC self-assessment, you’ll need a fresh evaluation. Pay close attention to organization-defined parameters and the level of specificity required in your SSPP, since this is where many Rev. 2-based programs fall short.

Address showstopper requirements first

Before investing effort elsewhere, make sure the Appendix C requirements are fully implemented. GSA makes clear that gaps in these areas can preclude approval, regardless of overall program maturity. This is the fastest way to reduce risk early.

Plan early for independent assessment capacity

GSA’s process depends on assessment by a 3PAO or independent assessor, both for initial evaluation and ongoing reassessment. Demand is already high, and scheduling delays are likely. Starting early gives you more control over timing and cost.

Pressure-test your incident response against the one-hour requirement

Walk through your incident response process step by step. How quickly can you detect an incident, escalate it, confirm it, and report it? If any part of that chain depends on manual coordination or business-hours availability, it’s worth addressing now.

Review your cloud dependencies and unsupported technology

Look closely at your environment for non-FedRAMP services, legacy systems, or unsupported components. These are often overlooked during early planning but can become blockers later in the process.

Involve legal counsel before making compliance representations

Given the potential for False Claims Act exposure, make sure your legal team is aligned on how compliance is being represented in proposals and during performance. Accuracy matters here in a way that goes beyond technical validation.

For many organizations, the hard part won’t be reading the GSA's guide. It will be operationalizing it across infrastructure, documentation, assessments, and ongoing monitoring. That’s where strong internal processes (and, in many cases, automation) start to make a real difference.

Meeting the new standard for handling CUI

GSA’s new CUI process signals a shift from point-in-time compliance to continuous, evidence-driven security operations. For many contractors, that’s where the real challenge begins.

It’s not just implementing controls. It’s maintaining them, documenting them, and proving they’re working, all while meeting tighter timelines and higher expectations for independent validation.

Secureframe Defense was built specifically to address this challenge. It combines automated cloud environment provisioning, continuous monitoring, and assessment-ready documentation paired with expert guidance to help organizations safeguard CUI and stay aligned with evolving federal requirements — without relying on disconnected tools or manual processes.

See how Secureframe Defense helps organizations across the Defense Industrial Base safeguard CUI and achieve compliance by scheduling a personalized demo.