FCI Compliance: What the 15 Requirements Demand
Table of Contents
- TL;DR
- What FCI Compliance Actually Obligates You to Do
- Basic Safeguarding of Covered Contractor Information Systems
- The 15 Basic Safeguarding Requirements, Grouped by What You Do
- 15 Requirements or 17 Practices? Why You Still See Both
- Cybersecurity Maturity Model Certification and FCI Compliance
- FCI and CUI: The Boundary That Decides Your Requirements
- How FCI Compliance Reaches Subcontractors
- Federal Data Protection: FCI Compliance and Related Compliance Frameworks
- How MotherBear Keeps FCI Compliance Provable
- FAQs About FCI Compliance
Federal Contract Information (FCI) compliance has a reputation for being the easy one. Fifteen requirements and no outside assessor equal basic hygiene, not security engineering.
That reputation is mostly earned and slightly dangerous. The requirements are foundational and shouldn't be unnecessarily complex.
But where Cybersecurity Maturity Model Certification (CMMC) Level 1 applies, the assessment behind them is pass or fail, remediation plans aren't allowed, and a single unmet requirement blocks your status.
They also aren't optional. The federal government treats these safeguards as the price of holding government contracts that involve non-public information.
The bigger risk sits elsewhere. Plenty of contractors who believe they hold only FCI haven't tested that assumption, and being wrong puts them into a far heavier set of requirements.
This guide covers what FCI compliance actually demands: the 15 requirements and what each one means operationally, how the self-assessment works, why the count is sometimes 17, and how to confirm you're really in scope for the easy tier.
TL;DR
- FCI compliance rests on Federal Acquisition Regulation (FAR) clause 52.204-21, which requires 15 basic safeguarding requirements on any covered contractor information system that processes, stores, or transmits FCI.
- Contracting officers insert the clause wherever FCI may reside in or transit a contractor's system, with commercially available off-the-shelf acquisitions excluded. It predates the CMMC program entirely.
- CMMC Level 1 adds verification, not new requirements: an annual self-assessment of the same 15 items plus an annual affirmation. It's pass or fail, with no Plans of Action and Milestones (POA&Ms) permitted.
- The count confusion is real. The current CMMC rule incorporates 15 requirements verbatim, while earlier CMMC 2.0 material described 17 practices by splitting one requirement into three.
- MotherBear keeps requirement status, evidence, and documentation in one workspace, so a Level 1 self-assessment is a readout rather than a scramble.
What FCI Compliance Actually Obligates You to Do
Federal Contract Information compliance is two obligations that people tend to merge.
The first is contractual and independent of CMMC: implement the 15 safeguards wherever FAR 52.204-21 appears in your contract. The second is procedural: where a CMMC Level 1 requirement applies, assess yourself against those same safeguards and affirm the result.
The first exists with or without CMMC. Federal regulations have required contractors to safeguard FCI since 2016, and the clause reaches most companies handling FCI under a federal contract.
The second is newer and narrower. It applies where a Department of Defense (DoD) solicitation or contract carries the CMMC clause, and it converts an unverified duty into an assessed, submitted, and formally affirmed status.
Confusing the two produces a specific failure: contractors who assume no CMMC clause means no obligation. The safeguards are contractual either way.
Basic Safeguarding of Covered Contractor Information Systems
The clause title tells you the scope. Your obligation attaches to covered contractor information systems (CCIS), meaning any information system owned or operated by you that processes, stores, or transmits FCI.
That phrasing does real work. It's system-based rather than company-based, so the requirements follow the data rather than blanketing your whole environment.
Scoping is the first compliance decision, not an afterthought. Map your data flows to find every place you store, process, or transmit FCI, and you've defined what has to comply.
Everything after that is deciding how to protect FCI inside that boundary.
Two practical notes. Information intended for public release isn't FCI, so your marketing site and public websites generally sit outside scope, and neither is simple transactional information such as what's needed to process payments.
Acquisitions solely for commercially available off-the-shelf items are also excluded.
The 15 Basic Safeguarding Requirements, Grouped by What You Do
The security controls come from FAR 52.204-21(b)(1), and the CMMC rule incorporates them verbatim. Protecting Federal Contract Information is their single purpose, so each one limits exposure rather than building broad security capability.
Here they are organized by the kind of work each demands.
Access Control: Limiting Who Reaches FCI
Access control holds one of the two largest groups, and the common thread is limitation.
- Decide who gets in: Limit access to authorized users, processes acting on their behalf, and approved devices. An up-to-date account inventory is how you prove it.
- Decide what they can do once inside: System access should reach only the transactions and functions that role is permitted to run. This supports a least-privilege approach, though the clause doesn't impose the full NIST least-privilege requirement, and blanket administrative rights are hard to defend against it.
- Govern connections outward: Where your environment touches external systems, including cloud platforms and partner networks, those connections need verification and limits rather than assumptions.
- Watch what lands on public platforms: Anything you post or process on publicly accessible information systems needs control, because FCI has no business on a public-facing page.
Identification and Authentication
Two requirements establish who's acting.
- Know the actor: Users, processes acting on behalf of users, and devices all need to be identifiable on in-scope systems. Shared generic accounts make this harder to satisfy and prove, since individual people still need to be distinguishable.
- Prove the identity first: Verification comes before allowing access, not after. Multi-factor authentication isn't demanded at this level, though it's the practical way to satisfy the requirement well.
Media and Physical Protection
Three requirements cover the physical world, which is where paper-heavy contractors usually slip.
- Retire media properly: Before hardware leaves or gets reused, sanitize or destroy information system media holding FCI. Reformatting a drive isn't destruction, and neither is deleting files.
- Lock the room, not just the login: Physical access to systems, equipment, and the environments housing them stays with authorized individuals.
- Handle visitors and keys deliberately: Visitors get escorted and their activity watched, entries get recorded in audit logs, and someone owns the job to control and manage physical access devices such as badges, keys, and fobs.
System and Communications Protection
Two requirements handle the network boundary.
- Watch the edges and the seams: You have to monitor and protect organizational communications, meaning whatever your organizational information systems send or receive, where they cross external boundaries and at key internal boundaries.
- Fence off anything public-facing: Publicly accessible system components belong on their own subnetworks, separated physically or logically from internal networks. A flat network where the public web server sits beside FCI systems fails this.
System and Information Integrity
Four requirements keep the systems themselves sound.
- Fix flaws before they age: Finding, reporting, and correcting system flaws has to happen in a timely manner. The clause doesn't define a window, so define one yourself and hold to it.
- Block malicious code: Protection against malicious code belongs at the points in your organizational information systems where it can actually intercept something.
- Keep that protection current: Update the mechanisms when new releases ship. Expired or unpatched endpoint protection fails this on its own, regardless of what's installed.
- Scan on a schedule and in real time: Perform periodic scans of the information system, and scan files arriving from external sources as soon as they're downloaded, opened, or run.
15 Requirements or 17 Practices? Why You Still See Both
You'll see both counts in circulation, and the discrepancy has a specific origin rather than being sloppy writing.
FAR 52.204-21(b)(1) lists 15 requirements, and 32 CFR 170.14(c)(2) incorporates those 15 verbatim into the CMMC rule. That's the authoritative count today.
Earlier CMMC 2.0 material described 17 practices by splitting one requirement, the visitor and physical access item, into three separate practices for assessment purposes.
Fifteen is the authoritative count today. Nothing substantive differs between the two presentations, so if a consultant or a tool says 17, they're still covering the same set of obligations.
Cybersecurity Maturity Model Certification and FCI Compliance
Where a DoD contract carries a CMMC Level 1 requirement, the safeguards you already owe become something you have to demonstrate. CMMC compliance at this level adds verification rather than new controls.
The mechanics are light compared with Level 2. Conduct an annual Level 1 self-assessment covering the applicable in-scope systems against all 15 requirements, enter the result in the Supplier Performance Risk System (SPRS), and have a senior official affirm it.
Three details make it stricter than it sounds. Level 1 is pass or fail rather than scored, and remediation plans aren't permitted, so every requirement must be fully met at the time of assessment.
The affirmation is a representation to the government, which is why the self-assessment and the related CMMC self-attestation deserve a careful look before submission.
One piece of current context. On July 13, 2026, the Department suspended CMMC Phase 2 pending a program review, but Phase 1 obligations continue, and Level 1 was never subject to third-party assessment anyway.
FCI and CUI: The Boundary That Decides Your Requirements
This is the section that matters most, because the key differences between the two tiers amount to 15 requirements versus 110.
FCI covers government information that isn't for public release, whether it reached you from the government or you created it while performing the contract. Non-public delivery schedules, performance reports, process documentation, and other contract-specific material can all qualify.
Simple payment-processing data is explicitly excluded, as is anything intended for public release.
When Controlled Unclassified Information (CUI) Enters the Picture
Controlled Unclassified Information is a narrower category of sensitive data: information the government creates or possesses, or that an entity creates on its behalf, that a law, regulation, or government-wide policy requires safeguarding or dissemination controls for.
The National Archives and Records Administration maintains the registry of categories, which range from technical data to critical infrastructure information.
The obligations arrive through your contract rather than automatically. For DoD contracts subject to DFARS 252.204-7012, handling CUI brings the 110 requirements from the National Institute of Standards and Technology (NIST) standard 800-171, Revision 2 under the current program, into scope.
It generally points to CMMC Level 2 where CMMC applies.
Contractors misjudge this boundary in one direction far more often than the other. Government technical data, controlled drawings, specifications, or export-controlled technical information received or created for the government may well be CUI rather than ordinary FCI.
The reverse isn't true: export-controlled material your company owns doesn't become CUI just because it's sensitive.
The practical test isn't your own judgment. Check what your contract designates, ask the contracting officer where it's ambiguous, and treat unmarked-but-sensitive government data as a question rather than an answer.
Crossing that line changes the whole picture, from the control count to the CUI compliance requirements that govern your systems.
How FCI Compliance Reaches Subcontractors
FAR 52.204-21 flows down. Its substance has to appear in subcontracts where FCI will reside in or pass through a subcontractor's system, which is how the requirement reaches most small suppliers.
Under the clause itself, primes pass down the substance of the requirement, excluding subcontracts for commercially available off-the-shelf items. If you're a subcontractor, the obligation often arrives through your prime rather than directly from federal agencies.
Where the CMMC flow-down clause applies, the prime additionally has to make sure the subcontractor holds the required current CMMC status before subcontract award. That turns your compliance posture into a commercial asset rather than a back-office cost.
Federal Data Protection: FCI Compliance and Related Compliance Frameworks
FCI compliance is the floor of federal data protection, not a standalone destination. It's worth seeing the tiers in order.
|
Framework |
Information covered |
Requirements |
Verification |
|
FAR 52.204-21 |
FCI |
15 basic safeguarding requirements |
Contractual, with no assessment mechanism in the clause |
|
CMMC Level 1 |
FCI |
The same 15 requirements |
Annual self-assessment and affirmation |
|
CMMC Level 2 |
CUI |
110 requirements from NIST 800-171 |
Self-assessment under Phase 1; third-party assessment suspended since July 2026 |
|
CMMC Level 3 |
CUI in the most sensitive programs |
Level 2 plus selected requirements from NIST 800-172 |
Government-led assessment in the full model, outside current Phase 1 implementation |
Level 3 applies only to programs where the information carries national security consequences, and most contractors never encounter it.
The progression matters for planning. FCI safeguards give you a foundation for Level 2, so some of the work carries forward if you later handle CUI, though Level 2 introduces a much larger program of its own.
Compliance efforts should anticipate that. Level 2 adds a System Security Plan (SSP), audit and configuration requirements, and far more documentation, and contractors who plan for it avoid starting over.
How MotherBear Keeps FCI Compliance Provable
Level 1 is simple enough that many contractors track it in a spreadsheet, right up until someone asks for proof.
That's the gap. Fifteen requirements are easy to implement and surprisingly easy to lose track of, because the evidence lives in screenshots, ticket systems, and one person's memory of how the network was configured.

MotherBear gives defense contractors and their consultants one workspace for requirement status, evidence tied to the requirements it proves, documentation, and remediation work, whether the program sits at Level 1 or grows into Level 2.
For managed service providers supporting many small suppliers, separate client programs stay organized in the same place, with reporting alongside them.
FAQs About FCI Compliance
What is FCI compliance?
FCI compliance means implementing the 15 basic safeguarding requirements in FAR 52.204-21 on each covered contractor information system that processes, stores, or transmits Federal Contract Information. The obligation is contractual and applies wherever the clause appears in your contract.
Where a DoD contract also carries a CMMC Level 1 requirement, compliance additionally means self-assessing against those same 15 items annually and affirming the result in SPRS.
What does FCI stand for?
FCI stands for Federal Contract Information: government information that isn't meant for public release, which you either receive from the government or produce for it while delivering a product or service under contract.
Two things sit outside the definition. Anything the government publishes openly isn't FCI, and neither is routine transactional data of the kind needed to process payments.
What is the difference between FCI and CUI?
Sensitivity and volume of requirements. FCI is non-public contract information protected by 15 basic safeguards under FAR 52.204-21.
CUI is a formally designated category defined by law, regulation, or government-wide policy, and for DoD contracts subject to DFARS 252.204-7012 it brings the 110 NIST 800-171 Revision 2 requirements into scope.
In CMMC terms, FCI corresponds to Level 1, and CUI generally points to Level 2 or above where CMMC applies. Getting the distinction wrong is expensive in both directions, so the designation in your contract governs rather than your own assessment of how sensitive something feels.
What is FCI protection?
FCI protection is the set of controls that keep Federal Contract Information from unauthorized disclosure.
In practice, that means limiting access to authorized users, authenticating identities, monitoring and protecting communications at your boundaries, separating public-facing systems from internal networks, controlling physical access and media, and defending against malicious code.
The goal is basic safeguarding rather than a comprehensive cybersecurity program. FCI protection establishes the minimum system protections considered necessary for non-public federal contract information, which is why the requirement count jumps so sharply at Level 2.
Ready to Simplify CMMC Level 1?
Book a demo of MotherBear to see how we make managing CMMC easier.