Is MagicSchool AI COPPA Compliant?

MagicSchool AI states, on its own privacy and trust pages, that its platform is built to align with COPPA, FERPA, and SOC 2 Type II standards, and it points to a Common Sense Privacy rating and an iKeepSafe Product Profile as supporting evidence. No vendor can hold an official government "COPPA certification," because that program does not exist, so districts still need to verify these claims themselves.

Quick Answer: MagicSchool AI publicly claims COPPA, FERPA, and SOC 2 Type II alignment, backed by a 95% Common Sense Privacy score and an iKeepSafe-published Product Profile. These are vendor-stated and third-party-reviewed signals, not a formal legal "COPPA compliance" certificate, since the FTC does not issue one to individual ed-tech products.

That distinction matters more than it sounds. A teacher scanning a trust page sees checkmarks and badges and reasonably assumes someone official signed off. In reality, COPPA compliance is a legal standard a company either meets or doesn't in practice, and the badges are evidence toward that judgment, not a substitute for it. This guide walks through what MagicSchool AI actually says, what independent reviewers have found, and how to confirm the claims before your district signs anything.

Understanding COPPA Before You Evaluate Any Vendor

What COPPA Actually Regulates

The Children's Online Privacy Protection Act is a federal law enforced by the Federal Trade Commission that requires operators of services directed at children under 13, or that knowingly collect data from them, to get verifiable parental consent before collecting personal information. It applies to the company operating the service, not to the school using it.

"Personal information" under COPPA is broader than most educators expect. It covers:

• Name, email address, and physical address
• Persistent identifiers like a device ID or cookie that can track a child across sites
• Geolocation data precise enough to identify a street or neighborhood
• Photos, videos, or voice recordings of the child
• Any other data linked to one of the above

Crucially, the FTC does not run a certification program that stamps a specific product "COPPA compliant." Enforcement happens through investigations, consent decrees, and civil penalties after the fact, plus a handful of FTC-approved Safe Harbor programs that companies can voluntarily join for self-regulatory oversight.

The School-Consent Exception Districts Rely On

In K-12 settings, a school can consent on behalf of parents for tools used solely for the school's educational purposes, under FTC guidance dating to 2014. This is the mechanism that lets a teacher assign an AI tool to a class of 10-year-olds without collecting individual parental sign-offs for every app.

That exception has conditions attached:

1. The vendor uses student data only for the authorized educational purpose.
2. Data is not used for behavioral advertising or resold to third parties.
3. The district, not the vendor, decides the tool is appropriate and notifies families as required by its own policy.
4. The district retains the practical ability to review the vendor's data practices on an ongoing basis.

If any of those four break down, the school-consent shortcut stops applying, and the vendor is back to needing direct parental consent it almost certainly doesn't have.

How COPPA Enforcement Actually Works

COPPA has no pre-approval step; a company doesn't submit its product to the FTC for a green light before launch. Instead, the FTC investigates after a complaint, an audit, or its own monitoring surfaces a potential violation, and penalties are civil fines calculated per violation, which is why a mishandled data practice affecting many children can scale into a large settlement quickly.

This after-the-fact structure is exactly why a vendor's own compliance claims matter so much to a district's risk exposure. If a company's practices turn out not to match what its privacy policy promised, the FTC's enforcement target is the company, but the district that deployed the tool still has to manage the fallout with its own families and school board.

What MagicSchool AI Says About Its Own Compliance

Privacy Policy and Student Data Policy Claims

MagicSchool AI's published privacy policy and student data policy state that the company aligns with FERPA, COPPA, GDPR, and SOC 2 Type II standards (MagicSchool AI, 2026). The company says personally identifiable student information is never sold and never used to train AI models, and that student data is stored in the United States.

MagicSchool AI also states that its subprocessors, including the large language model providers it routes requests through, are contractually barred from retaining or training on educator or student data, and are required to delete it after processing. The company describes itself as acting as a "school official" under FERPA's legitimate-educational-interest exception, meaning it processes education records on the district's behalf rather than as an independent data owner.

What a SOC 2 Type II Report Actually Tests

A SOC 2 Type II report is an independent auditor's assessment of a company's internal controls, evaluated over a period of months rather than a single point in time. It typically covers security, availability, and confidentiality controls, things like access management, encryption practices, and incident response, and it's a widely used enterprise security benchmark well beyond education.

It is not, however, a COPPA or FERPA audit. A company can hold a clean SOC 2 Type II report while still handling student data in a way that violates COPPA's consent requirements, because the two assessments check different things. Treat a SOC 2 report as evidence of operational security maturity, and treat the DPA as the document that actually governs student-data-specific obligations.

Third-Party Reviews: Common Sense, iKeepSafe, and SDPC

Three outside review mechanisms show up repeatedly in MagicSchool AI's own materials, and each means something slightly different:

• Common Sense Privacy Program. The nonprofit Common Sense Media scores ed-tech vendors against a published privacy rubric. MagicSchool AI (2026) reports a 95% rating and the program's "Verified" seal, up from an earlier 93%. This score is built from the vendor's policy language and disclosures, so treat it as a transparency signal, not an independent penetration test or security audit.
• iKeepSafe Product Profile. iKeepSafe is one of the handful of organizations the FTC has approved to operate a COPPA Safe Harbor program. iKeepSafe has published a Product Profile for MagicSchool summarizing the company's stated privacy and security practices. A Product Profile is a documentation and communication artifact; it is distinct from iKeepSafe's separate COPPA Safe Harbor certification badge, which is a stricter status earned through a formal privacy assessment. Districts should ask a vendor directly which of the two it actually holds, rather than assuming a profile equals a badge.
• Student Data Privacy Consortium (SDPC). MagicSchool AI states it is an SDPC member. SDPC maintains a national library of pre-negotiated data privacy agreement (DPA) templates, so a district evaluating MagicSchool AI may be able to start from an existing SDPC template instead of drafting a DPA from scratch.

For the full legal breakdown of how FERPA and COPPA fit together for schools, see AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026), which lays out the underlying framework this article applies to one vendor.

MagicSchool AI's Stated Compliance Posture at a Glance

The table below separates what MagicSchool AI claims from what kind of evidence backs each claim, so a reviewer can decide how much independent verification each line still needs.

Read across the table, the pattern is consistent: MagicSchool AI has invested in the kind of documentation and third-party review a careful district should ask for, but every row still resolves to "ask to see the underlying document," not "take the badge at face value."

How to Verify These Claims Before You Sign a Contract

Five Questions to Put to Any AI Vendor

Whether you're looking at MagicSchool AI or a competitor, the same five questions separate a real compliance posture from marketing language:

1. Can we see the actual Data Processing Agreement, not just the public-facing privacy policy?
2. Do you hold an FTC-approved Safe Harbor certification badge, or only a documentation profile from a Safe Harbor operator?
3. Can we review the SOC 2 Type II report itself, under NDA if the vendor requires it?
4. Which subprocessors touch student data, and does any language-model provider retain or train on submitted content?
5. What happens to our data when the contract ends, including deletion timeline and confirmation process?

Read the Contract, Not the Marketing Page

Marketing pages exist to reassure a visitor in thirty seconds. A signed DPA is the document that actually binds the vendor. It should name every subprocessor, state a retention and deletion timeline in days or months rather than vague language like "as needed," and commit to a breach-notification window your legal team can hold the vendor to.

If a vendor takes weeks to produce a DPA on request, or can't say clearly whether student prompts are used to improve its underlying AI model, that hesitation is itself useful information about how mature its privacy program actually is. Compare this against how a directly student-facing reading tool handles the same question in Is Newsela Safe for Students?, where the consent chain works differently because students, not just teachers, interact with the product.

Where MagicSchool AI Fits Among AI Tools for Teachers

MagicSchool AI positions itself as a broad teacher-productivity suite: 80+ tools spanning lesson planning, IEP drafting, rubric generation, and communication templates, with pricing reported around $8.33 to $12.99 per teacher per month on paid tiers plus a separate Enterprise tier for districts. Because it's teacher-facing by default (with a separate MagicStudent product for direct student use), its COPPA exposure concentrates wherever that student-facing layer is turned on.

Other AI content platforms for K-9 classrooms take a narrower approach. EduGenius, for example, is built specifically as a teacher-side content generator, producing quizzes, worksheets, flashcards, and slides from class-profile settings (grade level, subject, ability range) without requiring individual student accounts to use the generation tools themselves. That narrower data footprint is a design choice worth asking any vendor about directly: does the AI tool need student accounts and student-entered data to function, or only teacher input?

This is also where MagicSchool AI's product line matters to the compliance question. The core MagicSchool AI suite is teacher-facing: a teacher types a prompt and gets a lesson plan, rubric, or worksheet back, without a student ever logging in. MagicStudent, by contrast, is a separate product built for direct student interaction, which means it is the component that actually triggers the fuller COPPA analysis covered earlier in this article. A district piloting MagicSchool AI's teacher tools and a district enabling MagicStudent for a third-grade class are, from a compliance standpoint, evaluating two different risk profiles under the same brand name, and the DPA review should reflect which product is actually being turned on.

A district that has only ever piloted the teacher-facing suite and later turns on MagicStudent for a class of 8-year-olds should treat that as a new compliance review, not an extension of the original approval.

Tools built for direct student interaction, like AI assistants and chatbots, carry a different risk profile than one-way content generators. For that comparison, see Is SchoolAI Safe for FERPA and COPPA?, and for a head-to-head on two popular assistant-style tools, SchoolAI vs Khanmigo: Which Is Better for Teachers?. For a broader roundup of how MagicSchool AI and its peers stack up on security specifically, see The Most Secure AI Tools for K-12 Students in 2026.

Rolling Out MagicSchool AI: A Compliance Checklist for Districts

A technology director evaluating MagicSchool AI, or any similar AI tool, for district-wide rollout can work through this sequence rather than relying on the vendor's summary page alone:

1. Request the DPA and the SOC 2 Type II report together, not just the public privacy policy, and route both to your data privacy officer or legal counsel for review.
2. Confirm the subprocessor list, including which large language model provider handles requests, and get written confirmation that submitted content isn't retained for model training.
3. Map which grade levels and use cases the tool will actually be authorized for, since a teacher-facing lesson-planning tool and a student-facing chat feature may need separate sign-off.
4. Document who provided COPPA consent on the district's behalf, and keep that record alongside the signed contract for future audits.
5. Set a review date, typically tied to contract renewal, to re-check the vendor's subprocessor list and feature set for changes since the last review.
6. Notify families according to your district's existing ed-tech notification policy, even when the vendor relies on the school-consent exception rather than individual parental consent.

Treat this as a repeatable process rather than a one-time gate. The same six steps apply to the next AI tool a department wants to pilot, which is part of why documenting the process once saves time later.

Mistakes Districts Make When Evaluating AI Privacy Claims

• Treating a privacy badge as a legal certification. Common Sense ratings, iKeepSafe Product Profiles, and SOC 2 reports are all genuine signals, but none of them is the FTC stamping a product "COPPA compliant," because that stamp doesn't exist for individual products. Staff who see a badge on a landing page often stop asking questions right there, which is exactly the point where a more thorough review should start.
• Skipping the DPA because the privacy policy sounds thorough. Marketing copy and a signed Data Processing Agreement are not interchangeable; only the DPA is legally enforceable against the vendor. A privacy policy can change unilaterally with a website update, while a DPA generally can't be altered without both parties agreeing.
• Assuming a general ed-tech privacy policy covers AI-specific behavior. Ask explicitly whether student inputs train the underlying language model, since privacy policies written before generative AI existed may not address it clearly. This gap is common enough that it's worth asking even of vendors your district has used for years under a different product line.
• Not confirming who actually consented for under-13 students. Under FTC school-consent guidance, the district, not individual teachers and not the vendor, must formally authorize the tool for educational use. In practice this often falls through the cracks when a single teacher signs up for a free tier without routing it through procurement.
• Forgetting to revisit the agreement when the vendor ships new features. A new integration or a new underlying AI model between renewal cycles can change the data flow without the public privacy policy visibly changing. Set a calendar reminder tied to your renewal date rather than relying on the vendor to flag the change proactively.