FAR 52.204-21: What it Actually Requires

If you’ve been reading about CMMC Level 1 and keep seeing the phrase “FAR 52.204-21” without a clear explanation of what it is or what it means for your business, this is the article you need.

FAR 52.204-21 is the regulation that defines the baseline cybersecurity requirements for federal contractors. It’s been in effect since 2016, it applies to a much broader range of companies than most people realize, and it’s the direct foundation for CMMC Level 1. Understanding what it actually requires, not just that it exists, is the first step toward getting compliant.

What FAR 52.204-21 is and where it came from

FAR stands for Federal Acquisition Regulation. It’s the government-wide set of rules that governs how federal contracts work, covering everything from how bids are submitted to what obligations contractors take on when they sign a contract. Clause 52.204-21 is one specific provision within that larger framework.

The clause became effective June 15, 2016. It was created partly in response to the 2014 breach of Office of Personnel Management systems, which exposed personnel records on more than 20 million current and former federal employees and contractors. Congress passed the Federal Information Security Modernization Act the same year, and the FAR Council used that authority to push baseline security requirements down to contractors across the board.

The full title is “Basic Safeguarding of Covered Contractor Information Systems.” That title tells you a lot: it covers specific systems (not your whole company), it sets a baseline (not a complete security program), and it focuses on safeguarding (what you do, not just what you have).

Who it applies to

This is where a lot of small contractors get tripped up. Many assume FAR 52.204-21 is a defense contractor thing, or that it only applies to large companies. Neither is true.

The clause applies to any contractor whose systems process, store, or transmit Federal Contract Information. The contract doesn’t have to be with the Department of Defense. It applies across civilian agencies too.

Federal Contract Information, which the regulation calls FCI, is defined as information that is not intended for public release, provided by or generated for the government under a contract to develop or deliver a product or service. That definition is broad on purpose.

FCI includes things like:

• Proposal responses and the technical documents you submitted to win the contract
• Project status reports and performance data you generate during execution
• Invoices and delivery orders tied to contract performance
• Organizational charts, staffing plans, and work schedules created for the contract
• Correspondence with your contracting officer about contract requirements

What it does not include: information the government publishes publicly (like what you’d find on a government website), and simple transactional information needed only to process payments, like bank routing data on an invoice.

The practical test is pretty simple. If the government gave you information to help you do the work, or if you created information as part of doing the work, and it’s not something the government has made public, it’s probably FCI.

What a “covered contractor information system” actually means

The clause doesn’t apply to every computer your company owns. It applies specifically to systems that process, store, or transmit FCI.

A covered contractor information system is an information system owned or operated by a contractor that handles FCI. In practice, that usually includes your email server or business email service, your file storage (whether local servers, cloud storage, or both), your project management tools if they contain contract-related data, and your endpoints: the laptops, desktops, and mobile devices your employees use to access any of the above.

Systems that never touch FCI are not in scope. If your accounting software talks only to your bank and has no contract-related content flowing through it, it’s not a covered system. But if your team is sharing contract deliverables by email or storing them in a shared drive, those platforms are in scope regardless of how “basic” they seem.

This scoping question matters because it determines what you actually have to secure. Getting the scope wrong in either direction creates problems: too narrow and you’re out of compliance without knowing it, too broad and you’re spending time and money on systems that don’t need it.

The 15 security controls, explained in plain English

This is the core of the clause. Section (b)(1) lists 15 specific security controls that contractors must implement on any covered information system. The regulation text is written in the language of federal rule-making, so here’s what each one actually means for a typical small business.

Control 1: Limit system access to authorized users, processes, and devices
 Only people who are supposed to have access to your systems should have it. This means no shared logins, no letting a vendor use an employee account, and no accounts that stay active after someone leaves the company.

Control 2: Limit access to the types of transactions authorized users are permitted to execute
 Access should be scoped to what someone needs to do their job. Your receptionist probably doesn’t need access to contract deliverable files. Your field crew probably shouldn’t have admin rights on shared systems. This is often called least-privilege access.

Control 3: Verify and control connections to external information systems
 When your systems connect to outside systems, including cloud tools, vendor portals, and third-party software, you need to know those connections exist and have them under control. Unmanaged integrations and unauthorized tools (often called shadow IT) are a real gap here.

Control 4: Control information posted or processed on publicly accessible systems
 FCI cannot live on public-facing systems. Don’t post contract-related content on your website, a public-facing cloud folder, or social media. This sounds obvious, but the compliance gap shows up in unexpected places: a shared Google Drive folder set to “anyone with the link,” a public Slack workspace, a Dropbox link sent to a client.

Control 5: Identify users, processes, and devices
 Every account on your systems should be traceable to a specific person or function. No generic accounts named “admin” or “staff” that multiple people share. If something goes wrong and you need to trace activity back to a specific user, the logs need to be able to tell you who did what.

Control 6: Authenticate users, processes, and devices before granting access
 This is the login requirement. Systems need to verify who is accessing them, not just ask for a username. Strong, unique passwords are the minimum. Multi-factor authentication is the practical way to actually meet this requirement with any confidence.

Control 7: Sanitize or destroy media containing FCI before disposal or reuse
 When a hard drive, laptop, USB drive, or other storage device leaves your control, the data on it needs to be gone first. That means proper data wiping, not just deleting files. And it applies to reuse within your company too: if you’re repurposing an old laptop for a new employee, the previous user’s data should be wiped before the handoff.

Control 8: Limit physical access to systems, equipment, and operating environments
 Who can walk into the room where your servers are? Who can sit down at a workstation that’s logged into a system with FCI? Physical access controls can mean locked server rooms, badge access for offices, locked filing cabinets, or simply having a policy about who can be in the space where work is done.

Control 9: Escort visitors, log physical access, and control physical access devices
 Visitors to areas where FCI is processed or stored should be escorted by an employee. You should keep a log of who accessed controlled areas and when. If you use physical access devices like key cards or badges, you need a process for managing them, including deactivating them when someone leaves.

Control 10: Monitor and protect communications at system boundaries
 This covers your network perimeter. The traffic flowing in and out of your organization’s systems should be monitored and protected. A firewall is the baseline implementation here. This control also applies to key internal network boundaries, not just the outside edge.

Control 11: Implement separate subnetworks for publicly accessible components
 If you have systems accessible from the public internet (like a web server or a public-facing application), those should be on a separate network segment from the systems that hold FCI. This is commonly called a DMZ configuration. For most small businesses, the practical version of this is making sure public-facing services are not on the same network as internal file shares and email.

Control 12: Identify, report, and correct system flaws in a timely manner
 Software has vulnerabilities. When vendors release patches, those patches need to be applied. This control requires a process for knowing about vulnerabilities (usually through vendor notifications or security feeds) and a policy for how quickly patches get applied. Unpatched systems are one of the most common and most preventable failure points in security assessments.

Control 13: Provide protection from malicious code at appropriate locations
 Antivirus and anti-malware software on endpoints is the basic implementation. “Appropriate locations” in the regulation language means you’re thinking about where malware could enter your environment: workstations, servers, email gateways, and any other points of entry.

Control 14: Update malicious code protection when new releases are available
 Having antivirus that hasn’t updated its definitions in six months is not much better than not having it. This control specifically requires keeping protection current. Auto-update is the practical answer for most small businesses.

Control 15: Perform periodic and real-time scans
 Two types of scanning are required. Periodic scans are scheduled sweeps of your systems looking for threats. Real-time scans happen when files come in from outside: when someone downloads a file, opens an email attachment, or plugs in an external drive. Both should be running.

What the clause does not cover

A few things worth knowing about the scope of FAR 52.204-21:

It does not cover CUI. Controlled Unclassified Information has separate and more demanding requirements under DFARS 252.204-7012 and NIST SP 800-171. FAR 52.204-21 is specifically for FCI, and the clause language explicitly says it does not relieve contractors of other safeguarding obligations that may apply.

It does not apply to commercially available off-the-shelf items. If a subcontractor is providing COTS products with no FCI flowing through their systems, the flowdown requirement doesn’t apply to them.

It does not cover communication channels themselves. The final rule specifically excluded transmission of email, text messages, and voice communications from its scope. The regulation focuses on the systems, not the content in transit.

The flowdown requirement for subcontractors

Section (c) of the clause requires prime contractors to include the substance of FAR 52.204-21 in their subcontracts when a subcontractor may have FCI in their systems.

This is not optional. If you’re a prime and you’re sharing contract information with a subcontractor, you need to flow the requirement down. That means your subs need to meet the same 15 controls, and you’re responsible for including the obligation in their contract.

On the sub side: if you’re receiving FCI from your prime, the clause applies to you regardless of whether your prime has explicitly called it out. The regulation says “may have Federal contract information residing in or transiting through its information system.” If you’re getting project files, specs, or deliverables from your prime by email, you’re in that category.

Why this matters for CMMC Level 1

CMMC Level 1 is built directly on FAR 52.204-21. The 17 practices that define CMMC Level 1 are derived from these 15 controls, with two of the controls split into separate practices for assessment purposes.

If you’re pursuing CMMC Level 1 compliance, getting FAR 52.204-21 right is not a separate task. It is the task. The CMMC Level 1 self-assessment process requires you to document how you’ve implemented each practice, submit a score to the Supplier Performance Risk System (SPRS), and have a company officer attest to the accuracy of that submission.

The clause has been in contracts since 2016. Which means if you’ve been a federal contractor for any length of time, you’ve likely already agreed to these requirements. The question is whether you’ve actually implemented them.

The most common gaps we see

Based on what shows up consistently in readiness assessments, a few patterns stand out.

Shared accounts are the most frequent access control gap. Teams share a single login for convenience. It violates controls 1, 5, and 6 simultaneously and makes audit logs meaningless.

Stale user accounts are close behind. Former employees, former contractors, and former vendors whose access was never removed. Access should be deactivated on the day someone leaves, not the week after.

Uncontrolled cloud tools are a growing problem. Employees using personal Dropbox, personal Google Drive, or consumer file-sharing services to move contract-related files around creates FCI exposure on systems that aren’t under the company’s control and aren’t configured to meet any of these requirements.

Ignored patch cycles. Software updates pile up and get deferred indefinitely. Controls 12, 13, 14, and 15 all depend on a functional patching and scanning process.

No physical access controls. This one is especially common for small businesses that work out of shared office space or home offices. “Physical access” doesn’t require a secure facility, but it does require something: a locked room, a locked cabinet, a policy about who can sit at what computer.

Where to go from here

FAR 52.204-21 is the baseline. Meeting it doesn’t mean you have a comprehensive security program, but not meeting it means you’re already out of compliance on contracts you may have held for years.

The path forward isn’t complicated. Identify your covered systems, work through the 15 controls against your current environment, document what you’re doing, and fix the gaps. That process is what becomes your System Security Plan, which is also required for CMMC Level 1 self-assessment.

Pacific Cloud Cyber works with small and mid-size contractors who need to get this done without a full-time IT security team. We run readiness assessments that look at your actual environment against FAR 52.204-21’s requirements, identify the gaps, and help you close them efficiently. We’ve done this across construction, manufacturing, logistics, professional services, and technology firms.

If you’re not sure where your company stands against these 15 controls, that’s the right place to start. Contact Pacific Cloud Cyber to schedule a free consultation.