Buyer's guide
Student data privacy for a microschool: what to require from software vendors, and one vendor's own answers
Most vendor privacy advice is written for a district with a lawyer. A school of thirty has neither, and the question is narrower: what do we require, in writing, before student records go in? Here are the requirements, the rules that actually apply to you, and our own answers to every one.
Written by the Pearspark team · updated · about 12 minutes
In short
Require a signed agreement rather than a privacy policy the vendor can change alone. It should say the school owns the data; the vendor uses it only to run the service, with no advertising, no resale and no AI training; subprocessors are named and cannot change without notice; data is encrypted and access is logged; a breach is reported within a stated number of hours; you can export everything yourself; and the vendor deletes on request within a stated number of days.
First find out which rules actually bind you, because it is probably not the one you have heard of
Almost every article on this subject opens with FERPA. For a private microschool, FERPA is often the wrong place to start. It applies to schools that receive money from programs the U.S. Department of Education administers, and the Department says plainly that private and parochial schools at the elementary and secondary level generally do not receive that funding and are therefore not subject to FERPA.
That does not leave you unregulated. It moves the binding rule to three other places, and they are the ones worth reading first. Your funder is usually the strictest: an education savings account or a state scholarship program has its own agreement about the records you keep, how long you keep them, and who may see them, and it binds you by contract whether or not any statute does. Your state comes second, and state laws split into two kinds that land on completely different parties — some write the duty onto the school, and those usually define the covered school as a public district, charter or intermediate agency, which leaves a private microschool out; others write the duty onto the vendor. California's is the clearest example of the second kind: it binds the operator of a service designed and marketed for K-12 school purposes whether or not the operator has a contract with a school at all. If you are in a state like that, you get protection you never had to negotiate.
Third is the promise you already made. The enrollment agreement, the handbook and the privacy paragraph on your website are enforceable against you no matter which statute does or does not reach you, and they are the documents a family will actually quote back to you.
COPPA sits across all of it and lands on the vendor, not on you, whenever a service collects personal information from children under 13. The wrinkle worth knowing in 2026: the path most ed tech relies on — the school consents on parents' behalf, provided the information is collected for the use and benefit of the school and for no other commercial purpose — is Federal Trade Commission guidance, not rule text. The Commission rewrote the COPPA Rule effective June 2025, with compliance required by April 2026, and deliberately did not finalize the ed tech and school-authorization provisions it had proposed, to avoid clashing with FERPA regulations the Department of Education has on its agenda. So a vendor who answers "COPPA is covered, the school consents" is describing an enforcement posture that both agencies are still moving. Get the substance in the contract instead of relying on the label.
The ten requirements, in the order that saves you the most time
The first three predict the other seven. A vendor who handles those well is usually fine on the rest; a vendor who deflects on them will deflect on everything.
- A signed agreement, not a privacy policy. Ask for their data-processing agreement by name and read it. A privacy policy is a document one party writes and can rewrite; that is the wrong instrument for the promise you need. If the answer is a link and a reassurance, you have your answer.
- An export you run yourself, tested before you sign. Not "yes, we can export your data" — ask them to run it on sample data during the trial and look at what comes out. This is the requirement schools most often discover too late, and the only one you can verify without trusting anybody.
- Every secondary use named and closed. Not "we protect your data" but a list: no sale, no rental, no advertising, no building datasets or products from it, and no using it to train, fine-tune, evaluate or prompt an AI model. Ask for the AI clause specifically and read it for exceptions, because that is where the carve-outs of the last three years live. "We do not sell data" and "we do not train on data" are different sentences.
- A named subprocessor list, with notice before it changes. Every company your data passes through, by name, with what each one does. "Trusted partners" is not a list. Ask how much notice you get before one is added, and whether you can object.
- Deletion on request, within a stated number of days, and an answer about backups. Ask what happens on the day you cancel: what is deleted, when, whether subprocessors are told to do the same, and how long copies survive in routine backups. A vendor with no answer has not thought about the end of the relationship, which is the part you care about most.
- A breach-notification deadline in hours, with what the notice must contain. "Promptly" and "without undue delay" are not deadlines. Ask for a number, and ask that the notice describe what happened, whose data, and what they are doing about it.
- Encryption in transit and at rest — and ask separately about uploaded files. Records in the database are the easy half. Health forms, custody orders, aid paperwork and admission transcripts are usually files in object storage, and that is a different system with different rules. Ask what protects those specifically.
- Access controls you can see. Who at the vendor can look at your school? Is that access logged where you can read the log, or only where they can? Does it expire? Can you switch it off? This is the question with the widest gap between a good answer and a bad one, and almost nobody asks it.
- An audit log inside the product, for your own staff. Small schools share logins and stretch roles, and the record of who read a student's health file matters most when the school is smallest. Ask what is logged, whether views are logged and not just changes, and whether an administrator can read it without calling support.
- Evidence sized to the vendor. A SOC 2 report if they have one. If they do not — and most products at microschool prices do not — ask for the written summary of security measures, the subprocessor list, and answers to the nine items above in writing. A small vendor without a certification is not disqualified. A vendor who will not put anything in writing is.
The clauses, and what ours actually says
Our data-processing addendum is a real document we send to schools that ask. Every row below is quoted from it, or from the privacy policy, which is public and linked in the footer of this page. Where the honest answer is a gap, the gap is in the table.
| Require | What Pearspark's agreement says |
|---|---|
| Who owns the data | The school owns it. We process it only on the school's instructions, and only to provide, secure, maintain and support the service. We acquire no ownership and no rights beyond running your instance. |
| No sale, advertising or secondary use | No sale, rental, license or trade; no advertising, marketing or targeting; no other purpose at all. The product runs no third-party advertising, analytics or tracking. We never combine one school's data with another's. |
| No AI training | "Will not use School Data to train, fine-tune, evaluate, or prompt any artificial intelligence or machine-learning model, and will not transmit School Data to any third-party AI service." No exceptions clause. The product has no AI features and no model provider — a path that could have called one shipped in July 2026, never ran because the key was never set, and was deleted with its dependency in August 2026. Any future AI feature would need the school's separate, prior, opt-in written consent. |
| Named subprocessors, with notice | Six, named: Neon (database), Vercel (hosting and file storage), Clerk (sign-in), Stripe (payments — the school's billing contact only, never student or family records), Resend (email), Twilio (text delivery — a guardian's phone number and the text we send, never student records). Push notifications go through whichever push service the family's own browser uses, encrypted so that service cannot read them. 30 days' notice before we add or replace a subprocessor, and you may object. |
| Where the data lives | The United States. We will not move it outside the United States without your written consent. |
| Deletion and return | Nothing is deleted until you ask; a cancelled school's data sits untouched. When you ask, we return it and delete it within 30 days as the addendum is drafted, and direct our subprocessors to do the same, except copies in routine backups, which age out on the ordinary cycle and stay covered by the agreement until they do. One purge runs on its own without being asked: income documents for financial aid are destroyed when the decision is made. |
| Breach notification | Without undue delay and no later than 72 hours after we confirm a breach, with what happened, whose data, the likely consequences and what we are doing. Gap: many schools ask for 24 or 48, and our template's number is a bracketed placeholder — it is a term you can negotiate, and we would rather say that than pretend the number is fixed. |
| Parent and student requests | Where you cannot do it yourself with the export and correction tools, we help you answer a parent's request to see, correct or delete their information. |
| Audit rights | Once a year on written request, or after an incident, we provide what is needed to show we are keeping to the agreement: the summary of security measures and the current subprocessor list. Gap: there is no SOC 2 report and no third-party audit behind it. |
| State-specific agreements | Where your state requires its own form — a state alliance's version of the National Data Privacy Agreement, for instance — we will sign it and it controls over ours where the two disagree. Gap: we are not registered with the Student Data Privacy Consortium, whose registry holds the signed agreements most public districts work from, so there is nothing of ours to look up there today. |
| How you get it | Gap: by email, from support@pearspark.com, rather than as a link on this website. The privacy policy is public; the addendum is not, and it is still a template carrying bracketed placeholders for counsel to complete. A school should be able to read a vendor's data terms before talking to sales, and today ours cannot. |
The security answers, checked in the code rather than the brochure
"FERPA compliant" is a label, not an answer. These are the specifics to ask for, and ours.
| Ask | Pearspark's answer |
|---|---|
| Where is the data hosted? | The United States — Vercel for the application and file storage, Neon for the database. |
| Encrypted in transit and at rest? | Yes, and uploaded documents get a second layer: health, custody, aid, admission, volunteer, teacher and policy files are encrypted by us before they reach storage, stored as opaque files under a random name that carries no student information, and kept in private storage where the store supports it. If the encryption key is missing, the upload is refused rather than written in the clear. |
| Can one school's data reach another? | Every query for a school-scoped table is checked against the school it belongs to. That list of tables used to be maintained by hand and quietly fell 26 tables behind between July and September 2026; there is now a test that derives the list from the database schema itself, so a new table that forgets the check fails the build instead of shipping. |
| What is logged inside the product? | Every change, with who, when, IP address and browser — plus views of the sensitive records, which is the part most systems miss: health, custody, aid and admission documents, message oversight, and any records released. Ordinary page views are not logged. An administrator reads it without asking us. |
| Multi-factor sign-in? | Gap: not enforced. This is our weakest security answer and the one we would put first if you are ranking vendors on this page alone. |
| Independent audit or certification? | Gap: none. No SOC 2, no penetration-test report to hand you. A written summary of the measures above is available on request. |
| Backups, and recovery? | Regular backups with restore. Gap: no published recovery-time objective and no status page of our own; Vercel and Neon publish theirs. |
| Does your own team work with real school data? | No. Development and testing run against fictional sample data. |
At thirty students, the leak is not the software you paid for
A vendor checklist governs the system you signed for. It does not govern the shared spreadsheet of allergies and medications, the group text with two hundred numbers in it, the parent Facebook group, the volunteer's phone with photographs of the class on it, or the personal email account carrying a custody order as an attachment. That is where a small school's student data actually lives, and none of those will sign anything.
It is worth being blunt about the legal shape of this, because it is the opposite of intuitive. Under the school-consent path that ed tech relies on, the school is the party that authorised the collection. Point families' children at a free consumer tool and you did the authorising — for a service whose business model you did not read, that answers to no agreement with you, and that you cannot make delete anything.
We sell one of the two answers to this, so read the next sentence with that in mind. The answer is either fewer systems, so that the records sit in one place with permissions and a log, or a written rule about which tools staff may use and an annual look at whether anyone follows it. Both work. The second is free, and a school that will not do the second will not be saved by buying the first.
The email to send, before you send anyone a student record
Copy this to every vendor on your shortlist. Answers in writing, in the reply, not in a call. What comes back is usually more informative than the answers themselves.
- Please send your data processing agreement, and tell us whether you will sign our state's form if we need you to.
- List every company that will hold or touch our student data, by name, and tell us how much notice we get before that list changes.
- Confirm in writing that you will not sell our data, use it for advertising, build products or datasets from it, or use it to train, fine-tune, evaluate or prompt any AI model — and tell us about any exception.
- How many hours after confirming a breach will you notify us, and what will the notice contain?
- If we cancel, what is deleted, within how many days, and what survives in backups and for how long?
- Please run an export on sample data and send us the files, so we can see what we would actually get back.
- Who at your company can see our school's records, is that access logged where we can read it, and does it expire?
- Do you enforce multi-factor sign-in for your own staff, and can we require it for ours?
- Send your SOC 2 report if you have one. If you do not, send your written summary of security measures.
- What can your product not do that we are likely to assume it can?
The parts of Pearspark these requirements touch
Each page states what the feature does today, on the same rule of naming what it does not.
Common questions
What should a microschool require from software vendors to keep student information safe and compliant?
A signed data-processing agreement rather than a privacy policy; a statement that the school owns the data and the vendor uses it only to run the service; every secondary use closed by name, including sale, advertising and AI training; a named subprocessor list with notice before it changes; encryption in transit, at rest and over uploaded files; an audit log that records views of sensitive records and not only changes; a breach-notification deadline measured in hours; an export you have run yourself before signing; and deletion on request within a stated number of days, with an answer about backups.
Does FERPA apply to a private microschool?
Usually not. FERPA applies to schools that receive funds from programs administered by the U.S. Department of Education, and the Department states that private and parochial elementary and secondary schools generally do not receive that funding and are therefore not subject to FERPA. What binds a private microschool instead is its funder's agreement — an education savings account or scholarship program is normally the strictest — its own state's law, and the promises in its enrollment agreement and handbook. Check all three; do not assume the federal answer settles it.
Do we need a data processing agreement with our school software vendor?
Ask for one, and prefer a vendor who has one ready. A privacy policy is written by one party and can be rewritten by that party, which makes it the wrong instrument for a promise about your students' records. A written agreement is also what the U.S. Department of Education's guidance for schools using online educational services points to. If your state has an alliance using the Student Data Privacy Consortium's National Data Privacy Agreement, that standard form saves you writing one.
Can a school give consent on behalf of parents under COPPA?
The Federal Trade Commission's long-standing guidance says a school can, where the operator collects the information for the use and benefit of the school and for no other commercial purpose. It is guidance rather than rule text: when the Commission rewrote the COPPA Rule in 2025, effective June 2025 with compliance required by April 2026, it deliberately did not finalize the proposed ed tech and school-authorization provisions, to avoid conflicting with FERPA regulations the Department of Education has on its agenda. Treat "the school consents" as a reason to read the vendor's actual terms, not a substitute for reading them.
How do we check a small vendor's security if they have no SOC 2 report?
Ask for the things a small vendor can actually produce: a written summary of security measures, the subprocessor list by name, where the data is hosted, what encrypts uploaded files as distinct from database records, who inside the company can see your school and whether that access is logged and expires, and whether they enforce multi-factor sign-in on their own staff. Then test the export yourself during the trial. A vendor without a certification is not disqualified; a vendor who will not answer in writing is.
Should our vendor be allowed to use student data to train AI?
No, and it should say so in the contract with no exception attached. Ask for the clause and read it rather than the marketing page, because this is where carve-outs have appeared over the last three years: "we do not sell your data" and "we do not train on your data" are different promises, and so are "we do not train on your data" and "we do not send your data to an AI provider." Pearspark's addendum closes all three, and the product has no AI features and no model provider to send anything to.
What happens to our student records if we leave the software vendor?
Find out before you sign, not after. Ask what you can export yourself and in what format, whether attachments come with it, what the vendor deletes on request and within how many days, how long copies persist in backups, and whether there is any charge for leaving. In Pearspark nothing is deleted until you ask, the roster, gradebooks, reports and accounting export to CSV by button at any time including the trial, transcripts and records packets print to PDF, and there is no exit or export fee; the complete dump of every table is run by us on request rather than by a button, and uploaded documents come out one at a time from their records.
Is a microschool too small to be a target?
The size that matters is the vendor's, not the school's. The 2024 breach that exposed the records of more than 60 million students did not touch a single school's own systems: someone used stolen login credentials against the company that held the records for all of them. That is the reason the questions worth asking are about the vendor's internal access, its staff sign-in and its subprocessors, rather than about your own building.
Sources
Every figure on this page is read from the source linked below. Where no source could be found for a claim, the claim is not made.
- U.S. Department of Education: to which educational agencies or institutions does FERPA apply?
- Privacy Technical Assistance Center (U.S. Dept. of Education): Responsibilities of Third-Party Service Providers under FERPA
- U.S. Department of Education: Protecting Student Privacy While Using Online Educational Services — Model Terms of Service
- 34 CFR § 99.31 — the FERPA school official exception
- FTC: Complying with COPPA — frequently asked questions (schools and ed tech)
- FTC final rule amending the COPPA Rule, 90 FR 16896 (April 22, 2025) — effective and compliance dates, and the decision not to finalize the ed tech provisions
- U.S. Dept. of Education FERPA rulemaking on disclosures to third parties (RIN 1875-AA15)
- Student Data Privacy Consortium: the National Data Privacy Agreement
- California Business and Professions Code § 22584 (SOPIPA) — the duty on the operator
- Public Interest Privacy Center: state student privacy laws
- U.S. Attorney's Office, District of Massachusetts: sentencing in the school-records extortion case
- CyberScoop: the school-records hacker's sentencing
The full comparison behind each row
Each one is sourced feature by feature, last reviewed August 2026, and says plainly where the other system is the better choice.
See it before you decide
Every task is on video — one minute each — and your first 30 days are free. No sales call.