What Is FCI? Federal Contract Information Guide
Table of Contents
Federal Contract Information (FCI) is non-public information provided by or generated for the federal government under a contract.
Most defense contractors handle FCI without realizing that the records sit in inboxes, shared drives, and project files long before the team connects them to anything resembling a compliance program.
Cybersecurity Maturity Model Certification (CMMC) Level 1 enforcement is now in Phase 1, and that gap matters more than it used to. The Department of Defense (DoD) rollout makes the records that count as FCI drive your CMMC scope, so identifying them early can save weeks of audit prep later.
This guide explains what FCI is, how to recognize it in your system, how it differs from Controlled Unclassified Information (CUI), how to handle and protect it, and how CMMC Level 1 ties everything together.
TL;DR
- FCI is the non-public records you create or share, delivering federal work, including pricing, schedules, project emails, invoices, and progress notes. Most teams handle more than they realize.
- An FCI-only environment can self-attest to CMMC Level 1 through 15 FAR safeguards and be affirmed annually through SPRS. The moment CUI enters, the scope jumps to Level 2’s 110 NIST 800-171 controls and, often, a third-party assessment.
- Identifying FCI starts with reviewing each contract for the FAR 52.204-21 clause and auditing private correspondence with agency contacts, primes, and suppliers.
- MotherBear gives CMMC consultants and defense contractors one place to build and store their entire CMMC program, from the Level 1 baseline that FCI triggers to the 110-control Level 2 program most contractors eventually need once CUI enters the scope.
What Is FCI?
FCI refers to non-public information that is supplied by the government or produced for the government as part of a contract. It may be created by a team during the development or delivery of a product or service.
FCI can include pricing details, delivery schedules, project communications, and similar records that aren’t intended for public release.
The rule is defined in Federal Acquisition Regulation (FAR) 52.204-21, which scopes the duty to a covered contractor information system. Any environment that processes, stores, or transmits FCI. In other words, the handling duty follows the record into whichever system holds it.
The federal government keeps the duty broad on purpose. Because FCI isn't classified and isn't automatically a higher category, teams often under-protect it while overbuilding controls for records that only need the FAR baseline.
FCI also excludes information provided by the government to the public, so public websites don't create the same duty.
Simple transactional information necessary to process payments is also excluded, since routine billing data doesn't carry the same sensitivity as private contract details.
The sensitive nature of FCI starts when private work details leave the public channel.
Examples of FCI
Most teams underestimate how ordinary FCI looks. It rarely arrives with a label, so pattern recognition beats waiting for a perfect tag.
Look for records like these:
- Award terms, delivery schedules, and pricing details will be shared after the award
- Email threads about private instructions, milestones, or issue resolution
- Progress reports, performance updates, and meeting notes
- Bid responses, proposals, and supplier files after work begins
- Invoices, payment records, and private billing notes
Federal contracts create the duty, but daily operations spread the records, so a service to the government can produce FCI through a ticket, a status note, or a billing file, and project timelines often qualify when they reveal non-public milestones.
For government contractors, the hard part isn't the definition: it's noticing FCI before it spreads across mailboxes and folders.
FCI vs. CUI: Key Differences
CUI carries stricter markings than FCI. Both sit outside public channels, but the handling burden is different.
|
Area |
FCI |
CUI |
|
Source |
FAR 52.204-21 |
32 CFR Part 2002 and the CUI Registry |
|
Sensitivity |
Lower category |
Sensitive information with formal markings |
|
Level impact |
Usually Level 1 |
Often higher |
|
Markings |
Usually unmarked |
Marked when required |
|
Safeguards |
Basic FAR controls |
NIST 800-171 expectations |
That distinction reshapes your CMMC roadmap. An FCI-only environment can self-attest to CMMC Level 1's 17 basic safeguards in weeks.
The moment CUI enters the environment, you're at CMMC Level 2: 110 NIST 800-171 controls, a third-party assessment from a Certified Third Party Assessment Organization (C3PAO), and a 6–12 month preparation cycle for most teams.
Treat every FCI record as CUI, and the team builds a larger CMMC boundary than needed. Treat CUI as ordinary FCI, and assessors find missing controls.
The clean approach is to separate both record types early, then map each one to its clause, marking, and system owner.
How to Identify FCI in Your Business
Once the definition is clear, identification becomes a review of clauses and workflows, which fits teams that need a practical starting point before a formal assessment.
Start with these checks:
- Review each agreement for FAR 52.204-21
- Search private correspondence with agency contacts, primes, and suppliers
- Inventory folders, labels, queues, and collaboration tools are tied to the work
- Compare work statements, outputs, and schedules against staff-created files
- Treat unclear records as FCI until the owner confirms a lower duty
That last step prevents a common failure pattern: teams wait for a perfect label, then miss unmarked FCI that was generated for the government.
A simple inventory is less polished than a full map, but it gets contractors moving and keeps the process tied to ownership.
When the inventory outgrows a spreadsheet, MotherBear’s requirements tracking workspace gives teams one place to tie each record to the controls and tasks it triggers, which is ideal for the FAR baseline today and essential once CUI brings NIST 800-171 controls into the picture.
Operational Boundaries for FCI
Federal contracts spread private records across finance, program work, and supplier management, and they often reach subcontractors earlier than owners expect. That spread is why FCI deserves a dedicated review before staff assumes a file is harmless.
Data and Systems
Private records can reach help desks soon after kickoff, so systems should be sorted by whether they store FCI.
Systems that only host public content usually stay out of scope, while systems that move FCI, including finance tools and archives, need named owners.
That ownership is what keeps the scope honest, so system reviews should repeat after award changes or when suppliers connect, and any change in scope should trigger a process note documenting the exception.
Data maps then make ownership visible at the record level rather than the system level. Because data movement matters more than labels, data owners should confirm where copies sit, and each record should carry a source, an owner, and a retention date.
Supplier and Agency Scope
Subcontractors need the same clarity as internal teams, because a prime contractor may add flow-down language that subcontractors should confirm before work starts. Defense contractors should not assume suppliers are out of scope.
Anyone who handles FCI, whether internal team, contractor, or subcontractor, needs a simple intake path and a change log. Government contracts and federal agency messages need the same review, and any public release decisions should be documented.
Information is provided by or generated throughout the work, not only at kickoff, which means a service to the government can create FCI outside the main team. One clause may cover a contract to develop while another may cover delivery of a product, and either path can create FCI.
US government work can include quiet operational files, and at scale, sloppy handling can escalate into a critical national security issue. Information security leaders should own the escalation path.
A covered contractor information system can be a modest file share, so security controls should match the way staff uses it. Access control is the first place to look: to safeguard FCI, you define the owner first and let media protection and access decisions follow.
How to Handle and Protect FCI
FAR 52.204-21 maps to 15 basic safeguarding requirements pulled from the NIST 800-171 families.
These controls give FCI basic protection compared to the heavier expectations on CUI work, but each safeguard still needs to be implemented, documented, and demonstrable when an assessor or buyer asks.
The clearest way to operationalize them is by three habits that the safeguards naturally cluster into. The boundary follows the records, not the org chart, so security controls should match how staff actually uses the systems that hold FCI.
Limit Who Can Reach FCI
Access control covers who reaches FCI and how their identity gets verified. Start by limiting access to authorized users, and narrow that further to the specific transactions or functions each user needs to do their job.
A contracts coordinator probably doesn't need source code access, and the engineering team probably doesn't need pricing files. From there, authenticate every user, process, and device with unique identifiers before they touch FCI.
Then extend the same discipline to physical access: lock the rooms where the systems live, escort visitors, and log who used which physical access device.
Most teams trip on the physical side first, because a server room that anyone in the office can walk into is a finding even when the digital controls are clean.
Protect How FCI Moves Through Your Systems
System protection covers how FCI moves and how the systems that hold it stay clean.
Start at the edges. Verify and control external connections so supplier portals and remote services don't quietly bypass internal boundaries. Watch what gets posted to publicly accessible systems, too, so FCI doesn't end up on a misconfigured share.
Inside that perimeter, monitor communications at the external boundary and at any key internal boundary between subnetworks. Separate publicly accessible system components from internal networks. That separation keeps a public-facing service from pivoting into the FCI environment.
The systems themselves need the same attention. Identify and correct system flaws on a regular cadence. Provide malicious code protection at gateways, endpoints, and email, and update those mechanisms when vendors release new signatures.
On top of that, run periodic scans of the environment and real-time scans of any files arriving from external sources.
Sanitize Media Before Disposal or Reuse
A wiped laptop or a returned external drive that still holds FCI is an exposure event, so wipe, degauss, or physically destroy any storage that touched FCI before recycling, reissuing to a different team, or sending it back to a vendor.
Document each disposal as you go, following consistent procedures so the same evidence supports the CMMC Level 1 affirmation later.
The same logic extends to subcontractors. A prime contractor may add flow-down language that subcontractors should confirm before work starts, including how their media gets handled at the end of an engagement. Don't assume suppliers are out of scope.
For teams preparing evidence across all 15 safeguards, MotherBear's central evidence repository helps prove proper handling without searching shared drives before an assessment.
FCI and CMMC Level 1: What You Need to Know
CMMC Level 1 is the baseline, so teams that handle FCI start there. The current DoD rollout runs Phase 1 from November 10, 2025, to November 9, 2026, and that phase focuses on Level 1 and Level 2 self-assessment activity.
That doesn't make self-assessment a paperwork shortcut. Contractors still need cybersecurity practices they can explain, repeat, and affirm through Supplier Performance Risk System (SPRS) submissions.
CMMC Level 1 remains a self-assessment path, while Level 2 changes the evidence burden, and Level 3 is rare for this audience. The DoD can add CMMC level language to solicitations, and that language should match the records your team handles.
CMMC Level 1 covers 15 security requirements, drawn directly from FAR 52.204-21. A defense industrial base supplier usually starts there when it only handles FCI, but if CUI enters the environment, the same supplier may need a higher level.
The defense industrial base needs proof, not vague evidence, which means cybersecurity practices need named owners. FCI requirements also create legal exposure, since a contractor that affirms a status it can't support can turn weak evidence into False Claims Act risk.
Manage Your Entire CMMC Program With MotherBear

Most defense contractors don't stay FCI-only. The first contract that pulls CUI in jumps the program from 15 FAR safeguards to 110 NIST 800-171 controls, often with a third-party assessment attached.
Teams get caught flat-footed when evidence still lives in shared drives and email threads. MotherBear gives CMMC consultants and defense contractors one workspace to build and store the entire program.
Track requirements across Level 1 and Level 2, organize evidence, draft documentation, and keep tasks moving before assessment. Consulting firms run multiple client programs from one view; contractors keep their own program tied to the records that define its scope.
FAQs About What Is FCI
What does FCI mean in federal work?
FCI stands for Federal Contract Information: non-public records contractors create or share while delivering work for the US government under a contract. Material provided after the award counts, and material your team generates during delivery counts too.
How do you identify FCI?
Identify FCI by reviewing each contract for the Federal Acquisition Regulation (FAR) 52.204-21 clause, then auditing private correspondence with agency contacts, primes, and suppliers. Inventory folders, labels, and tools tied to the work, and treat any unclear record as FCI until the owner confirms a lower duty.
Is FCI the same as CUI?
No. FCI is lower-sensitivity information covered by basic safeguards under FAR 52.204-21.
Controlled Unclassified Information (CUI) requires stronger controls and formal handling rules under 32 CFR Part 2002 and triggers CMMC Level 2 instead of Level 1, so the distinction affects scope, assessment type, and timeline.
Which CMMC level applies to FCI?
In the context of US Department of Defense (DoD) contracting, FCI requires CMMC Level 1 compliance, the 17-control self-assessment baseline.
The level rises to CMMC Level 2 when CUI enters the environment, adding 110 NIST 800-171 controls and a third-party assessment.
Need CMMC Level 1?
Book a demo of MotherBear to see how you can simplify CMMC