What a Parent Can't Approve: 4 Weeks Inside FERPA

In September 2026, Tallo's director of product management told me it wasn't fair to ask me to become the company's expert on student privacy law. Somebody still had to understand FERPA and the data privacy agreements schools sign well enough to write the requirements, though, and I didn't see it as unfair. I'm not a lawyer. But a product manager who can't read the clause is a product manager who ships a feature legal has to pull back out, and I'd rather spend a month reading than a quarter building something we'd have to take apart.

So I spent the next four weeks reading. Every source is in the full case study. The reading ended up designing a lot of the product.

Tallo is a career platform for teens and young adults, and more and more of its students were arriving through their schools. That makes schools a new audience in the way that matters most, because a school isn't just a channel. It's a party with its own legal obligations, its own contracts, and its own say over what a product can do with a student's information. If you've ever taken a product into a regulated market – schools, healthcare, finance, anything with minors in it – you've met some version of this, where the rules end up deciding what the product is allowed to be.

The goal was to understand exactly what Tallo needed to do so a school could use it safely and legally, and then to design the screens that would let schools, families, and students manage who can see and do what. Before designing anything, I framed the problem as three jobs instead of a list of user types: a gatekeeper job ("let me be sure this is safe before I let my kid in"), a coaching job ("help me help my kid"), and a pull job, where a student brings a parent in. The gatekeeper job decides whether the other two ever get used, so that's where the work started. The design that came out of it is complete and specified but hasn't been built yet, so the findings below are decisions rather than launch results.

FERPA governs school records, not age

Most people treat FERPA as a privacy law for minors. It isn't. It governs education records, and it applies to a high-school senior who's already turned 18 the same way it applies to a freshman. What changes at 18 is who holds the rights: under the Department of Education's own definition, they move from the parent to the student when the student turns 18 or enrolls at a postsecondary school. Protecting minors is a separate job, handled by different laws like COPPA for kids under 13 and a growing set of state design codes for older teens, and it applies whether a school is involved or not.

That sounds like trivia until you look at the data model. The obvious design was a single "FERPA student" flag, and that one flag was trying to answer two different questions: whose rules govern this account's data, and how careful does the product need to be with this person because of their age? A student can need both, either, or neither, so the design split it in two. Whether an account is linked to a school became a fact the product stores, instead of something it works out after the fact whenever someone asks.

Where the data came from decides who controls it

The National Data Privacy Agreement is a standard template a lot of districts sign, and the way I read it, school-provided data stays the school's. So does anything a product infers from that data. If a school sends over a course list and the product derives a set of skills from it, those skills belong to the school too, and neither turning 18 nor graduating changes that.

Student-created work is different. A resume or a portfolio is the one kind of data a student can take with them, once it's actually been transferred into their control. There's a tempting shortcut here: show the student a prefilled screen of their school data, ask them to confirm it's right, and treat it as theirs from then on. A confirmation screen doesn't change where the data came from, though, and none of the 17 products I checked tries it. If a student wants a school fact in a personal account, they type it in themselves, and the product labels it as self-reported.

A parent can restrict, but can't authorize what the school hasn't

This was the most counterintuitive finding of the four weeks. Under a school's data privacy agreement, a parent's consent stacks on top of the school's authorization. It never replaces it. So if a product wants to make a school-linked student visible to employers, that's a disclosure the school has to authorize first, not a setting a parent can flip. A parent can turn things off for their own child. They can't turn on something the school hasn't allowed.

States add another layer, and they don't agree with each other. California allows no route to employer visibility for these students at all, even with a parent's or the student's consent. Texas allows disclosure for an employment purpose the student or a parent requests. Georgia rewrote its rule in July 2026. I kept those differences in a policy table rather than in code, took the strictest rule as the floor wherever that was cheap, and varied by state only where the strictest rule would make the product useless somewhere else.

Even where a parent's consent really is the missing piece, a parent portal is the wrong place to ask for it. In one study of 264 schools, only a quarter of families had ever logged into their parent account by the end of the school year. If a feature needs a portal login to unlock, almost no student will ever get it. Consent the school already collects at enrollment works better, and so does a one-time request the student sends a parent, for one named action.

A school sign-in proves who someone is, not what they're allowed to do

Online schools use "learning coach" for the adult who supports a student day to day. That's often a parent, but it can be another relative or an older sibling, and FERPA's definition of a parent includes a guardian, or a grandparent raising the child, but not a sibling. Signing in through the school proves who the person is. It doesn't prove what authority they have.

So the design has two lanes. Any adult a student chooses can get a read-only view of exactly what the student shares, whatever the student calls that person. Only a guardian of record, as the school records it, can restrict settings or give consent.

The rest of the access model follows the same logic, and these are the principles I'd carry to any product with layered permissions:

• Settings nest downward. A district sets on, off, or "let schools decide," a school decides what the district left open, a guardian can only turn things off for their own child, and the student chooses within all of that. Nothing loosens from below.
• Every lock says who set it. "Set by your school," "Set by your family," "Because you're under 18." A locked setting is greyed out with a reason instead of quietly disappearing and looking broken.
• Private means the profile doesn't appear to exist. To anyone who isn't authorized, a private profile looks exactly like one that was never created.
• Deny by default, enforced on the server. A switch that only hides something in the browser is worse than no switch.
• Guardian controls exist because schools need to see them. Parents mostly won't log in weekly, so measure the feature by whether schools trust the product, not by parent usage.

About 160 legal questions came down to 47

Two habits kept four weeks of reading from turning into four weeks of reading with nothing to show for it.

The first was writing for product people instead of lawyers. My first deliverable was a plain-language brief whose stated goal was to make the eventual conversation with counsel shorter and sharper, followed by working answers to the questions the product team actually needed answered. Where the law was unclear, I built on the more protective option and wrote down what would make us revisit it. Every document carried a "reading, not ruling" caveat, and when a verification pass found that some of those caveats had been sanded off somewhere between the research and the summary, they went back in.

The second was triage. About 160 questions across more than 30 documents turned out to be about 47 distinct ones, and those sorted into four tiers: ask counsel now, ask when the work starts, proceed on a working answer that only counsel can loosen, and park. Anything about something already happening went in the first tier, because not asking doesn't protect anyone. Handing a lawyer a long, unranked pile is a good way to wait a long time for answers to the wrong questions.

I used AI research agents for the breadth, with a separate fact-check pass on every claim, 1,009 of them across the main project. The judgment about what each finding meant for the product stayed mine.

The cheap yes is "legal can look at it later"

There's always a version of the plan where the team builds first and someone checks the law at the end. It feels responsible, because legal review is on the plan, and it's fast, because nobody has to stop and read anything. That's a cheap yes, and a cheap yes leads to an expensive no: the feature that gets built, demoed, maybe even announced, and then pulled because the school's agreement never allowed it.

The four weeks were cheaper, and they changed what I could do afterward. A month later, a designer asked why one of my mockups worked the way it did, and I could walk through the four different ways that one screen could go depending on FERPA, the school's data privacy agreement, the parent's consent, the student's age, and the state the student lives in. Four weeks earlier, I couldn't have told you most of that.

That's also why the work was useful before a line of it shipped. The access model answers questions every school-facing feature eventually runs into, so the next feature starts from a model instead of a meeting.

If you're weighing a move into an audience you've never served – the way Tallo did when it set out to serve career starters – the research question isn't only whether that market wants you. It's also what that market's rules will let you build, and you want that answer before the first screen, not after the launch.

The products that get this right read the clause before anyone draws the screen.

This is my product reading of public law, not legal advice. Statutes and agreements change, so check the current text before relying on any of it.