Every year, U.S. schools and libraries apply for E-Rate, the FCC program that subsidizes internet, broadband, and network equipment. The application form (FCC Form 486) requires the applicant to certify CIPA compliance. Most schools do. Most vendors selling into those schools never get asked to prove they support that certification.
That is starting to change. As classrooms become AI-mediated across Copilot for education, ChatGPT for teachers, generative-AI reading tutors, and adaptive-learning engines, district IT teams have realized the CIPA framework they built in 2005 does not describe what their classroom traffic actually looks like in 2026. The 2027-28 E-Rate filing window is where that reckoning starts landing on vendor procurement teams. What was a self-attested checkbox for the district becomes a specific evidence request for the vendor, and the vendors who arrive without the artifacts get sent back.
Below are the five artifacts district procurement teams are drafting into their 2027-28 vendor questionnaires right now, ranked by how often we see them cause avoidable district-side friction. Walk the list before end of October if you sell into K-12 and want your 2027-28 renewal to move quietly. If your product now includes AI features touching student data, walk it alongside the AI-in-the-classroom vendor responsibility framework. The districts asking the CIPA questions this fall are the same districts asking the AI-governance questions this fall, and the answers travel together.
For the 2027-28 filing window: what to have ready
The five items below are the ones that reliably matter in the first six weeks of a district procurement cycle. If you’re an EdTech vendor with active district customers, walk the list before the district refreshes its DPA template. If your product touches student data through an LLM or any other AI feature, walk it alongside the AI-in-the-classroom pillar. The CIPA questions and the AI-governance questions arrive together in 2027.
- Ship content-safety alignment documentation for every AI feature.One page naming which content categories your safety layer blocks, how that maps to CIPA’s obscene / harmful-to-minors / child-pornography categories, and how the district configures it if defaults don’t align. Vendors who ship “the model has built-in safety” without documentation of what that safety layer actually blocks land in the “send back for more evidence” bucket at DPA review.
- Expose turn-level logs with a district-accessible export interface.Full prompt and response logs at turn granularity, retained per district records-retention policy, exportable to the district’s SIEM or monitoring stack via webhook, district-tenant API, or S3 export. “We have logs internally, submit a support ticket to request them” is not the artifact. The interface the district uses to pull logs into its own visibility layer is the artifact.
- Publish a training-data attestation naming the model providers involved.Written attestation that student prompts and generated content are not used to train the vendor’s models, or the narrow exception under which they are, with the district-consent path. Names the specific providers (OpenAI, Anthropic, Google, Meta, self-hosted) and the contractual controls that prevent training use, because the model-provider terms are what district procurement lawyers will read against.
- Maintain a sub-processor register with per-vendor consent posture. For every AI subprocessor (the model provider, any RAG store, any moderation API), what data flows through, under what consent basis (parental, school-authorization, opt-in disclosure), and what the retention and deletion commitment is. Districts catch this at DPA review and refuse signatures without it.
- Wire a student-data-specific incident-response commitment into the AI feature. Not the generic security-incident SLA, but the specific commitment for what happens when a student prompt or model output triggers a CIPA-relevant safety event: who is notified, in what window, with what artifact. This is where the vendor either has a real incident-response process wired into the AI feature or is going to have to invent one at 2 AM on a Tuesday during the school year.
The training-data attestation, in practice
Of the five artifacts above, the training-data attestation is the one district procurement teams currently reject most often, because most vendors submit a version that reads like a marketing page. The version that clears DPA review names the specific providers, cites the specific contract clauses, and locates the artifact somewhere the district can pull it without a support ticket. For example:
“Student prompts and generated content routed through [Vendor Product] are processed by three model providers under enterprise-tier contracts: OpenAI (via the OpenAI API under enterprise terms, master agreement dated 2026-03-14, §4.2 prohibits training on submitted content); Anthropic (via the Anthropic API under a Zero Data Retention agreement, master agreement dated 2026-05-22, §5.1 prohibits training on submitted content); Google (via Vertex AI, Data Processing Addendum §3.4 prohibits training on customer content by default). No RAG store retains student content beyond the active session. The vendor does not use student content for model training, evaluation, or fine-tuning of internal models. This attestation is signed by the Chief Privacy Officer, reviewed at each subprocessor renewal, and available under the district DPA at portal.vendor.com/compliance/{district-slug}.”
The other four artifacts hold to the same rule: specific over general, dated over undated, named accountable person over “the vendor’s compliance team,” and district-accessible interface over “submit a support ticket.” That is what separates the vendors that clear a district DPA in the first review cycle from the vendors that don’t.
All five artifacts double as FERPA and COPPA evidence, and they map cleanly to the state student-privacy laws (SOPPA, SOPIPA, NY Ed Law 2-d) that overlay federal frameworks per state. Vendors that build them once evidence them across every district DPA, whether federal or state, K-12 or higher-ed.
What CIPA actually requires
The Children’s Internet Protection Act was enacted in 2000, with FCC implementing rules adopted the following year. Every school or library receiving E-Rate discounts must implement three things or lose the subsidy: a Technology Protection Measure that filters obscene, child-pornography, and harmful-to-minors content on any computer used by minors; a written Internet Safety Policy adopted after public notice and hearing; and monitoring of minors’ online activities (a schools-specific requirement; libraries are not required to monitor). Local decision on what “harmful” means; there is no federal filter list. The filter can be relaxed for adult users conducting bona fide research, but for minors it is mandatory. Certification runs annually via FCC Form 486 as part of the E-Rate application.
What CIPA does not require: a federal filter list, a specific vendor or product, content-scanning of every request in real time, blocking of educational content that includes discussion of sensitive topics, or filtering of teacher and staff traffic (though many districts do it anyway). The framework is deliberately implementation-agnostic. That was reasonable in 2001, when the assumption was “student sitting at a browser, requesting a URL, receiving HTML back.” It is less reasonable in 2026, when the student is more likely typing into an AI tutor and the response is generated content the filter has never seen.
CIPA legally binds the school, not the vendor. But districts receiving E-Rate cannot certify CIPA compliance if their vendor tools bypass or contradict their filter, monitoring, and safety posture. Vendors serving K-12 are increasingly required to prove CIPA-alignment as part of the district DPA (Data Privacy Agreement) or procurement questionnaire, especially for AI-mediated features that can generate content the district’s filter never sees. The compliance obligation is the district’s; the evidence burden lands on the vendor.
The AI-mediated classroom problem CIPA didn’t anticipate
The 2001 framework assumed URLs. The 2026 classroom traffic pattern is prompts and responses, and the URL-based mental model doesn’t translate. Three questions districts are now asking vendors (and that vendors selling AI-mediated products into K-12 need to have answers for) did not exist in the CIPA questionnaire five years ago.
The first is content-safety alignment. A district can filter youtube.com; it cannot filter the paragraph an AI model generates about a topic that maps to the district’s blocked-category list. The vendor either applies its own content-safety layer that aligns with district categories, or it exposes controls that let the district configure what the model can produce. The specific ask that separates cleared-at-DPA from held-for-review is a one-page mapping between the vendor’s safety categories and the district’s CIPA categories, with the configuration mechanism named. Not a marketing brochure claiming “safe for education.” A mapping.
The second is turn-level monitoring. Districts monitor URL requests. AI conversations are semantically richer and, by default, not surfaced to the same monitoring stack. Vendors need to either log turn-level content for district review or provide monitoring hooks the district’s existing tools can consume. A vendor whose tool routes student prompts through an LLM and returns responses without logging the full turn to a district-accessible interface is invisible to district CIPA monitoring, even when the tool itself is doing safety-checking internally. The specific ask is a defined interface (SIEM webhook, S3 export, district-tenant API) rather than “we have logs, submit a support ticket to request them.”
The third is personal-information handling. CIPA specifically calls out unauthorized disclosure of personal information about minors. LLM prompts contain far more than URL requests: student names, essay drafts, personal reflections, medical questions. Vendors need to prove that this data isn’t retained, isn’t used for training, and isn’t disclosed inside model outputs to other users. The specific ask is a written training-data attestation naming the model providers involved (OpenAI, Anthropic, Google, Meta, self-hosted) and the specific contractual controls that prevent training use, because the model-provider terms are what district procurement lawyers will read against.
What the FCC E-Rate cybersecurity pilot changed
In 2024, the FCC established a three-year, $200 million E-Rate cybersecurity pilot program. It funds advanced firewalls, endpoint protection, identity management, and monitoring for K-12 schools and libraries. Procedurally it is separate from CIPA compliance. But it lands on the same district IT teams during the same filing window, and it materially raises the bar on what “monitoring minors’ online activities” is expected to look like in practice.
A district participating in the pilot has invested in infrastructure that gives it far more visibility into student traffic than the CIPA baseline required. That visibility becomes the reference point for what CIPA-adequate monitoring looks like at that district. Vendors whose products can’t feed the infrastructure (no logs, no webhooks, no observability) start looking non-compliant by comparison, even when their contractual CIPA-alignment language hasn’t changed. The statute didn’t move. The district’s expectation of what compliant looks like did.
The bottom line
CIPA hasn’t changed on paper. What changed is that districts now have both the FCC pilot funding and the visibility to enforce it against AI-mediated tools. The vendors that arrive at the 2027-28 filing window with the content-safety documentation, the monitoring interfaces, and the training-data attestations already in place will move through district procurement smoothly. The vendors that don’t will get sent back for evidence they didn’t build the mechanisms to produce, and the district will move on to the vendor that came prepared.
The good news is the discipline generalizes. Everything on the five-artifact list also serves FERPA and COPPA, and it maps to the state student-privacy laws (SOPPA, SOPIPA, NY Ed Law 2-d) that overlay federal frameworks per state. The buyer who assembles the packet during the 2026-27 school year lands the 2027-28 renewals cleanly. The buyer who waits for a district to ask spends the next filing window explaining why the artifact isn’t ready.
Put the playbook to work
The five-artifact vendor packet builds on the same six-dimension foundation the AI-in-the-classroom vendor responsibility framework walks through: data flows, consent posture, training-data attestation, human decision authority, auditability, and incident response. vCISO Lite ships the compliance surface that assembles those artifacts (multi-framework tracking across FERPA + COPPA + CIPA + state student-privacy laws, sub-processor register with per-vendor consent posture, district-ready security-questionnaire responses, and the cryptographic hash-per-artifact structure procurement teams now prefer). See how the packet gets assembled at vcisolite.com.