What CUI Classification Means for EdTech Vendors Handling Federal Program Data

When an EdTech SaaS vendor signs a contract to support a federal education program, whether that means processing Federal Student Aid data, managing records for an NSF-funded research initiative, or administering Title IV financial aid on behalf of an institution, it often inherits a set of compliance obligations that were never explicitly discussed during procurement. CUI classification is the mechanism that activates those obligations. The category of data a vendor processes determines every downstream requirement, from which NIST SP 800-171 controls apply to what FedRAMP impact level the system must meet. Understanding which CUI categories apply to a given product is the actual starting line for any EdTech vendor doing federal education work, and vendors who skip that determination consistently discover their exposure during audits or breach response rather than during product design.

CUI as Compliance Trigger, Not a Label

CUI sits in an odd middle zone. It is not classified information, so it does not carry Top Secret or Confidential designations, but it is also not public. Before Executive Order 13556 established the CUI program, federal agencies used more than 100 overlapping labels, including "For Official Use Only" and "Sensitive But Unclassified," and none of them shared a common standard. The CUI program replaced that patchwork with a single framework governed by the NARA CUI Registry.

The Registry currently contains 126 registered categories. If a vendor's product processes, stores, or transmits data that falls into any one of those categories, that vendor is handling CUI regardless of whether the contract explicitly said so, regardless of whether the data was labeled when it arrived, and regardless of how long it has been in the system. The classification lives in the data type itself, not in the deal terms or the vendor's intent. That is the anchor point for every compliance obligation discussed in this post.

Which CUI Categories Affect EdTech Vendors

The Registry organizes its categories into Organizational Index Groupings, and a vendor's actual scope depends on which groupings its product touches. A vendor can read its master service agreement from start to finish and still miss regulated data, because the trigger is the data type, not the contract language.

Several categories recur frequently in EdTech contexts. Federal Tax Information is one of the most significant: Federal Student Aid has stated that FTI qualifies as CUI, so any vendor touching financial aid data, student loan records, or Title IV administration is already in scope. Sensitive Personally Identifiable Information covers Social Security numbers, financial account numbers, and biometric identifiers where a breach could cause demonstrable harm. Health Information covers records tied to a person's medical condition, care, or payment history. Controlled Technical Information, including engineering drawings or source code with military or space application, is relevant for higher education vendors supporting federally funded research. Export Controlled Information, governed by EAR and ITAR, appears in university research partnerships more frequently than most vendors anticipate.

A meaningful distinction exists between CUI Basic and CUI Specified. Both carry the same protection level, but CUI Specified applies when the underlying law imposes additional handling requirements beyond the baseline. CUI Specified always carries a mandatory prefix in banner markings, specifically CUI//SP-[code], and dissemination is governed by that specific statute rather than the general Lawful Government Purpose standard that applies to CUI Basic.

Only the federal government determines what information qualifies as CUI. Contractors are not authorized to self-designate data as CUI and must request a formal determination from the originating agency or their federal program counterpart when uncertainty exists. Under the FIPS 199 high-watermark principle, a single CUI data type with Moderate confidentiality impact raises the entire system's categorization to Moderate. Vendors routinely discover this detail during audits rather than during system design.

The Compliance Stack CUI Classification Activates

Once CUI is confirmed in a system, a layered set of obligations applies. These are not competing options from which a vendor selects the most convenient. They are sequential requirements that activate based on system type, contract type, and data category.

NIST SP 800-171 is the foundational control set for protecting CUI in nonfederal systems and organizations. Revision 3 was finalized by NIST in May 2024. It draws from NIST SP 800-53 and organizes 110 controls across 14 families including access control, awareness and training, auditing, configuration management, and communications protection. The legal basis for treating CUI Basic at no less than Moderate confidentiality impact is codified in 32 CFR Part 2002, which incorporates NIST standards by reference.

For cloud-based systems, FedRAMP applies. A SaaS product that handles PII on behalf of a federal agency is almost always classified at FedRAMP Moderate. The authorization level is determined by the agency's requirements and the FIPS 199 categorization, not by vendor preference. Traditional FedRAMP authorization has historically required significant time and cost. FedRAMP 20x, announced in March 2025, is an effort to automate compliance through machine-readable processes, incorporate existing industry standards such as SOC 2 and ISO 27001, and replace periodic audits with continuous monitoring. That program is still evolving and should not be treated as a finalized alternative pathway yet.

GovRAMP, rebranded from StateRAMP in February 2025, covers state, local, tribal, and educational buyers. Vendors with existing FedRAMP authorization can use GovRAMP's Fast Track process to reuse their security package. A GovRAMP-only authorization does not satisfy FedRAMP requirements, and federal agencies will still require independent federal certification.

CMMC 2.0 applies to defense-adjacent EdTech. Level 2 certification applies to CUI environments within DoD contracts and is relevant for higher education vendors supporting federally funded defense research or Controlled Technical Information environments. Under DFARS 252.204-7012, prime contractors must flow compliance clauses down to subcontractors whose work involves covered defense information. An EdTech vendor operating as a sub-tier supplier to a systems integrator on a DoD education contract is in scope regardless of how the data was labeled when it arrived.

The Proposed FAR CUI Rule and Civilian Contractors

A proposed rule was published in the Federal Register on January 15, 2025 (90 FR 4278). The comment period closed March 17, 2025, and as of the most recent research, no final rule has been issued. This is a proposal, and its requirements should be understood in that context.

The proposal would extend NIST SP 800-171 compliance obligations to all non-defense federal contractors handling CUI, not only those operating under DoD contracts. It would also add cybersecurity training and incident reporting requirements across the full federal contractor base. The stated intent is to establish a government-wide standard for protecting CUI across all federal agencies and contracts by amending the FAR to cover contractors and subcontractors at every civilian agency.

For EdTech vendors specifically, this would close a gap that many companies have been operating within. Vendors serving the Department of Education, NSF-funded programs, or other civilian agencies have been outside DFARS scope and have faced less formal CUI compliance pressure than their DoD counterparts. This rule would bring civilian agency contractors into the same baseline. Even before a final rule is published, civilian agency contracts are already trending toward NIST SP 800-171 alignment in practice. Vendors designing or rebuilding systems now should build to that standard regardless of what current contract language technically requires, because the regulatory direction is established even if the final text is not.

Where FERPA, COPPA, and State Law Intersect

A single EdTech vendor serving K-12 districts can simultaneously be a FERPA school official, a COPPA operator, and a CUI-handling federal contractor. These categories do not cancel each other out, and one breach can trigger enforcement under all three regimes, each with its own investigators and its own documentation requirements.

FERPA regulates institutions that receive federal funding, not vendors directly. Vendors achieve FERPA compliance indirectly through the School Official Exception, which is formalized in a Data Processing Agreement that binds the vendor to the school's data obligations. The Department of Education was targeting a FERPA NPRM for January 2026 to update PII disclosure provisions. Full compliance with a FERPA DPA creates no safe harbor from CUI obligations.

COPPA adds its own requirements. The 2026 amendments, enforced as of April 22, 2026, require separate parental consent before sharing a child's data with third parties, written retention policies with defined time limits, and classify biometric identifiers as personal information. Civil penalties reach $53,088 per violation under the FTC's 2025 inflation adjustment, and each affected child can constitute a separate violation. A platform with a large under-13 user base faces penalties that multiply by user count, not by incident. FTC leadership has identified children's privacy as a top enforcement priority through 2026.

State law applies in addition to both federal frameworks. Nearly 400 student privacy bills have been introduced across 49 states since 2014, and more than 130 state student data privacy laws are currently in effect. California's AB 1584 requires specific contract clauses covering data ownership, advertising prohibitions, deletion rights, and breach notification. CCPA/CPRA requires annual cybersecurity audits for qualifying companies, with fines up to $7,500 per intentional violation. New York's Education Law §2-d requires NIST Cybersecurity Framework adoption and a dedicated data protection officer. Vendors operating across multiple states typically maintain state-specific DPA versions, often anchored to the Student Data Privacy Consortium baseline.

FERPA and COPPA establish baseline obligations for student data. State law imposes additional requirements that vary by jurisdiction. CUI classification operates as a parallel federal compliance track with its own separate controls. Satisfying any one of these frameworks does not satisfy the others.

What Enforcement Actually Looks Like

In December 2021, a hacker used login credentials belonging to a former Illuminate Education employee to access the company's cloud environment. That access produced a breach affecting student data across multiple states.

On November 6, 2025, the Attorneys General of California, Connecticut, and New York announced a $5.1 million settlement with Illuminate Education, Inc. The action marked the first enforcement under California's SOPIPA law and Connecticut's Student Data Privacy Law, and the second major enforcement under New York's Education Law §2-d. Less than a month later, on December 1, 2025, the FTC announced a proposed settlement alleging that the breach had exposed personal information belonging to more than 10 million students. The FTC finalized that order on June 5, 2026, requiring Illuminate to overhaul its data security program, restrict unnecessary data collection and retention, and delete excess consumer data.

Illuminate had stored student data in plain text until at least January 2022. The enforcement actions were simultaneous and independent: satisfying the multi-state AG settlement resolved nothing with the FTC, and vice versa. The FTC's final order imposed long-duration injunctive requirements including a written security program, mandatory data minimization and deletion schedules, published retention policies, independent security assessments, and breach-reporting obligations enforceable for an extended period with per-violation penalties for any lapse.

The Illuminate case illustrates the risk profile that results when the compliance obligations described in the previous sections go unmet. A vendor that certifies NIST SP 800-171 compliance in a federal contract while its actual security posture does not match that certification is not only risking an audit finding. False certification on a federal contract carries potential liability under the False Claims Act, where qui tam whistleblowers can bring suit on the government's behalf and share in any recovery. The compliance gaps that produce enforcement actions are typically gaps that were present and addressable long before the breach occurred.