Reading the Student Data Privacy Agreement

Every data privacy officer develops a reflex for a particular kind of sentence — the reassuring one that turns out, on a second reading, to have moved the responsibility rather than removed it. "Student data ultimately belongs to and remains under the control of the School" is exactly that kind of sentence. It is genuinely good news. It is also, read carefully, a statement about where the obligations live, and the answer is partly with you. This piece is about reading the privacy terms the way the person accountable for them has to read them: taking the favorable commitments at face value, and then asking the questions the favorable commitments don't answer.

I'll be precise about what's publicly documented and what isn't, because the honest boundary between the two is the whole value of this exercise. Inventing detail about incident-response timelines or retention windows would be worse than useless to a privacy officer — it would be a liability. So where the public record stops, I'll say so.

What the "School Official" designation actually does

Start with the load-bearing term. OpenAI designates itself a "School Official" with a "legitimate educational interest" under FERPA, per analysis from Sonomos. This is not marketing language; it's a specific legal construct. FERPA generally bars a school from disclosing personally identifiable information from education records without parental consent — but it carves out an exception for "school officials with a legitimate educational interest," which is the mechanism schools use to share records with vendors who perform a service the school would otherwise do itself.

By slotting into that exception, OpenAI is saying: treat us the way FERPA lets you treat an in-house service provider. That's what makes it permissible, under the regulation, for a school to route education-record data through the tool without collecting individual parental consent for each use. It's a real and useful designation.

The School Official exception is a door FERPA opens for schools — but the school is the one that has to decide the vendor is genuinely acting like a school official, and the school retains "direct control" over the vendor's use of the data. The designation doesn't transfer accountability. It shares a service while keeping accountability at the district.

That's the first thing to internalize. The designation makes the arrangement lawful; it does not make it someone else's problem. Under FERPA's own conditions for this exception, the school must retain direct control over the vendor's maintenance and use of the information. So "under the control of the School" isn't just OpenAI being generous — it's a condition the exception requires. The control is yours because it has to be.

The commitments that are actually on the record

Three commitments are publicly documented and worth stating plainly, because they're the ones you can rely on:

• Data ownership stays with the school. Student data "ultimately belongs to and remains under the control of the School," per Sonomos. You are not signing your records over to a vendor.
• No training on your data by default. Workspace content is not used to train OpenAI's models unless you change that setting — reinforced across the coverage, including Skoobuzz's summary. The phrase "by default" is doing work: confirm the setting, don't assume it.
• Enterprise-grade security controls exist. The managed workspace offers encryption, SSO, MFA, and role-based access, which are the technical controls a privacy officer expects to see before student data goes anywhere near a system.

These are strong terms — stronger than the free consumer product, and comparable to what districts negotiate with paid EdTech vendors. If your evaluation stopped at "are the commitments good?", the answer is yes. But a privacy officer's job isn't to confirm the good commitments. It's to find the questions they don't cover.

The questions the public documentation doesn't answer

Here is where I'll be deliberately honest about the limits of what a blog can tell you. Several questions that matter enormously to a privacy officer are not reliably answerable from public documentation, and you should treat anyone who claims otherwise with suspicion. Get these in writing, from OpenAI or from the actual agreement your district executes — not from a summary:

• Data retention specifics. How long is workspace content retained? What's the deletion process when a district offboards, and is deletion verifiable? "Under your control" implies you can delete it; confirm the mechanism and the timeline.
• Incident-response commitments. What are the breach-notification timelines? What are the specific SLAs? These are exactly the kind of operational detail that public write-ups don't contain and that your district's data-sharing standards may require in writing.
• Subprocessors and data location. Where is the data processed and stored, and which subprocessors touch it? This matters for districts with state-law data-residency requirements.
• State-law overlay. FERPA is the floor, not the ceiling. Many states have their own student-privacy statutes — and some require a signed Data Privacy Agreement on a specific template (the NDPA / SDPC framework is common). Does your state require one here? A federal designation does not automatically satisfy a state DPA requirement.

None of these being publicly spelled out is a red flag on its own — most are the kind of thing that lives in the executed agreement rather than a help article. The red flag would be rolling out without answers. The action item is to convert each of these from an open question into a documented term before student data enters the workspace.

How to actually run the review

For a privacy officer, the practical procedure is short. First, obtain and read the actual agreement your district would execute — not a blog, not a help page, the document. Second, map its terms against your existing data-governance standard and your state's student-privacy law, and flag every gap where the agreement is silent on something your standard requires. Third, get the silent items answered in writing. Fourth, decide your data-minimization posture independently of what the agreement permits.

That last point deserves weight. The agreement may lawfully permit routing education records through the tool under the School Official exception — but "permitted" and "advisable" are different questions, and they're yours to separate. Many districts will conclude that the safe operating posture, at least initially, is no personally identifiable student information in the workspace at all, using the tool for lesson design, planning, and content generation rather than anything tied to a named student. That posture sidesteps most of the hardest questions above while still capturing most of the value, and it pairs naturally with the acceptable-use guidance from the procurement checklist. You can always widen the posture later, once retention and incident-response terms are documented. It's much harder to walk one back after data is already flowing.

The through-line

The privacy story here is better than the free-tool cynic expects and less finished than the marketing implies, and both of those things are true at once. OpenAI's School Official designation and data-ownership terms are real, favorable, and legally meaningful. They also leave the operational specifics — retention, incident response, subprocessors, state-law fit — for your district to pin down, precisely because FERPA's own exception keeps control at the district. That's not a flaw in the offer; it's how the regulation works. The privacy officer's task is to read the good terms as good, read the silences as homework, and refuse to let the absence of an invoice substitute for the absence of a signed, complete agreement.

The technical controls that enforce whatever posture you choose — who can see what inside the workspace — are the next thing to get right, which is where role-based access control for school workspaces picks up.

---

Part 89 of 100 in the ChatGPT for Teachers series. Previously: SSO, MFA, and the District IT Rollout Plan. Next: Role-Based Access Control for School Workspaces. Browse more builder insights or explore AI skills for education at aiskill.market.