Is Brisk Teaching COPPA Compliant?
Brisk Teaching is not, and cannot be, "COPPA certified," because COPPA has no certification program for any vendor; what it has instead is a data-access design where most of its tools are triggered by a teacher acting on content already in hand, not by a child interacting with the operator directly, and that distinction changes the COPPA analysis for most of the product before a signed agreement even enters the picture. One feature, Brisk Boost, breaks that pattern entirely, and it is the one place a district's consent paperwork needs to say something specific rather than something general.
Quick Answer: COPPA requires verifiable parental consent when an operator has "actual knowledge" it is collecting personal information directly from a child under 13, a requirement schools can typically satisfy by consenting on a family's behalf for a strictly educational, non-commercial purpose. For most of the product's tools, feedback, grading, quiz generation, Inspect Writing, a teacher submits already-collected student work rather than a child interacting with it directly, which fits cleanly inside that school-consent framework. Brisk Boost is different: a student converses with it directly, which is the exact scenario COPPA's consent requirement was written for, making it the one feature a district's signed agreement needs to name explicitly. No public evidence shows Brisk Teaching belongs to an FTC-approved COPPA Safe Harbor program.
This is a narrow legal question, deliberately. Founding details, funding history, and the independently reviewed 93% Common Sense Privacy score are covered in the companion data-privacy guide, and the content-appropriateness of the Boost chatbot activities is covered in the companion safety guide. This guide stays on one question: what does COPPA's verifiable-parental-consent requirement actually demand here, given how differently each tool collects data.
The Real Question Isn't "Certified," It's "Who Triggers the Data Interaction"
No AI vendor, this one included, can point to a government-issued COPPA certificate, because COPPA regulates operators directly through a consent requirement, not through a certification a company applies for and receives. The pillar guide on this topic covers that distinction in full; the short version is that a compliance claim on a vendor's own page is a self-description, not independent verification, unless it is backed by a specific, named mechanism.
The company states it operates under COPPA by relying on schools to provide consent on behalf of families, alongside a Student Data Privacy Pledge signature and a National Data Privacy Agreement exhibit executed in roughly two dozen states. None of those three is a government certification. The question worth actually answering, rather than treating "compliant" as a single yes-or-no label, is where COPPA's consent requirement legally attaches inside a product with several structurally different features.
How COPPA's Consent Requirement Actually Works
COPPA requires an operator to obtain verifiable parental consent only once it has "actual knowledge" that it is collecting personal information directly from a child under 13, according to the FTC's own compliance guidance (FTC, Complying with COPPA: Frequently Asked Questions). That "actual knowledge" standard, and who is doing the providing, matters more than it sounds for a classroom tool.
On a general-audience website, an operator with no information suggesting a visitor is a child generally has no COPPA obligation, since it lacks the actual knowledge the rule requires to trigger. A K-9 classroom deployment flips that default entirely. A school that rosters a class of demonstrably under-13 students into a vendor's product is, by the act of doing so, giving that vendor exactly the actual knowledge the "we didn't know" position depends on not having. That is precisely why the affirmative school-consent pathway exists: once a school knowingly brings a vendor into a classroom of young children, the default "no actual knowledge" position is no longer available, and consent has to come from somewhere.
The School-as-Agent Pathway, and Its Actual Legal Limits
Longstanding FTC guidance allows a school to consent on a family's behalf, standing in as the parent's agent, but only for a strictly educational purpose the school has authorized, not for a commercial one, and only for what the school was actually told about and agreed to (FTC, Complying with COPPA: Frequently Asked Questions). That scope limitation is the detail worth sitting with. A school's consent covers what it consented to, not automatically every feature a vendor later ships under the same product name.
For an operator to actually rely on that pathway, current FTC guidance states it must give the school the same notices COPPA requires for a parent, and, on request, let the school review, delete, or stop further collection of a specific child's data. A district's signed agreement is where that obligation becomes enforceable and specific, not a vendor's general privacy page.
"Verifiable" in a typical consumer COPPA scenario usually points to a specific mechanism: a signed form, a credit-card check, a government ID, confirming an actual parent gave consent. In the school-as-agent pathway, a school's own enrollment and authorization records substitute for that individual verification step, which is precisely why the pathway depends on the school having specifically authorized the tool and feature in question, not merely having a general technology-use policy on file somewhere.
Why the Teacher-Triggered Design Changes the Analysis for Most Features
Most of the product's tools never put a child in direct contact with the operator at all, and that structural fact is doing real legal work, not just a marketing distinction. A student writes an essay in Google Docs; a teacher, not the student, opens the extension and runs a feedback tool against it. The child is not "providing personal information" to the operator in the sense COPPA's core scenario describes; a school employee, acting under the school's own authorization, is.
| Feature | Who actually provides data | How that fits the COPPA consent question |
|---|---|---|
| Targeted Feedback (Google Docs) | The teacher selects and submits the document | Teacher-mediated; a strong fit for the school-consent framework, since no child-operator interface exists for this feature |
| Quiz Maker | The teacher provides a webpage, transcript, or document | Same teacher-mediated pattern; no student ever interacts with the tool directly to generate a quiz |
| Brisk Grader | The teacher runs a rubric against student submissions already inside Google Classroom | Teacher-initiated even though the underlying content is student work |
| Inspect Writing | The teacher reviews a replay of a student's own edit history | No new data collection from the child in the moment; it processes history already stored inside Google Docs |
| Brisk Boost | The student types directly into a chatbot interface | Direct child-operator interaction; the paradigm scenario COPPA's consent requirement was written for |
That table is the center of this article's answer. Four of the five core features are a strong structural fit for school-consent coverage, arguably a cleaner fit than a typical rostered product where a child logs in and interacts with a vendor's interface directly. One feature is not, and it deserves to be treated as its own, separate question.
Brisk Boost Is a Different Legal Case Entirely
Brisk Boost is the one feature where a student converses with the operator directly, in real time, typing responses the system receives and processes as they happen. That is exactly the collection-from-a-child scenario COPPA's verifiable-parental-consent requirement was built around, and it is worth treating that way rather than assuming it inherits the same coverage as the teacher-mediated tools automatically.
A district's National Data Privacy Agreement exhibit, or its Student Data Privacy Pledge signature, was very likely negotiated with the teacher-facing product in mind first, since that was the core of the offering before Boost's later addition. Whether that existing paperwork specifically names and covers a live, student-facing chatbot is not something to assume; it is something to confirm directly, in writing.
The companion safety guide already flags this exact gap from a different angle, recommending that a school "ask your technology office whether Boost specifically, not just Brisk's teacher-side tools, is covered under your district's signed agreement." That recommendation is the practical output of the legal analysis above: the direct child-operator interaction model behind Boost is the reason that specific confirmation matters more here than it would for a purely teacher-mediated feature.
What a Signed Agreement Actually Needs to Cover
A district's real protection is not the existence of an agreement, but whether that agreement's scope matches what a specific feature actually does. A generic reference to feedback and grading tools generally, without naming Boost, in a signed exhibit does not automatically extend to a feature with a completely different data-collection model.
| Agreement element | Why it matters specifically for the Boost question |
|---|---|
| Does the agreement name Brisk Boost explicitly, not just the product generally? | A scope limited to feedback and grading tools may not extend to a live, student-facing chatbot added later |
| Does it specify whether Boost requires a signed-in student account or allows code-based join? | A signed-in account creates a persistent record tied to a specific child; a code-join session does not, a materially different data footprint |
| Does it describe what happens to a Boost conversation transcript after the activity ends? | Consent scope should cover retention, not just collection, for a feature where the child is the one generating the content |
| Does it confirm the notice requirements COPPA's school-consent pathway requires were actually given to the school? | The pathway only functions if the operator gave the school what COPPA requires it to give a parent in the first place |
None of these questions has a single universal answer, since the specifics depend on what a given district actually negotiated. They are the concrete items worth routing to a technology office or student-data-privacy officer before Boost gets enabled tenant-wide, rather than assuming a general agreement already covers it.
An Option That Avoids This Question Entirely for a Given Activity
A teacher who wants a vocabulary or comprehension activity without opening the Boost-specific consent-scope question at all has another option worth knowing about. EduGenius can generate a differentiated worksheet or flashcard set directly from a class profile set to a specific grade and subject, with no student-facing chat interface and no individual account, sidestepping the direct child-operator interaction question this section is about entirely.
Where the Real Privacy Signals Fit Into This Analysis
The independently reviewed 93% Common Sense Privacy score is real evidence, not marketing, but it is worth reading for what it actually measures rather than treating the headline number as a COPPA determination. The category most relevant to this article's question, Parental Consent, scored 100%, while Data Collection scored 83%, the two sub-scores worth weighing directly against the Boost question above.
| Signal | What it is | Does it satisfy COPPA's Safe Harbor mechanism? |
|---|---|---|
| Common Sense Privacy score (93% overall; Parental Consent 100%) | Independent, rubric-based third-party evaluation | No; a private evaluation, not an FTC-approved Safe Harbor review |
| Student Data Privacy Pledge | Voluntary industry commitment | No; signals intent, not independently audited |
| National Data Privacy Agreement exhibit | A pre-negotiated, signable contract | No, but this is the enforceable mechanism a district actually relies on |
| FTC-approved Safe Harbor program (iKeepSafe, PRIVO, kidSAFE) | Independent review under 16 CFR § 312.11 | Yes, this is COPPA's own recognized mechanism; no public evidence of participation was found for this article |
A 100% Parental Consent sub-score reflects Common Sense Media's own rubric for consent-related practices; it is a strong signal, but it is a private organization's evaluation framework, not the FTC-approved Safe Harbor review COPPA specifically recognizes. A strong third-party privacy score and a pledge signature are both real, positive signals; neither one is the specific mechanism that would let a district treat the Boost question above as already settled.
None of this means the product is poorly governed. A 93% score with every category above 75% is a genuinely strong result relative to the broader AI-tool market. It means a strong privacy score and a settled COPPA question are two different findings, and a district review should ask for both rather than treating one as proof of the other.
A Grade 4 Rollout Scenario, Walked Through
Say your district's technology office has already signed a National Data Privacy Agreement exhibit covering the core feedback and grading tools, and a Grade 4 team now wants to pilot Boost for a vocabulary-practice activity.
- Route the specific question to whoever signed the original agreement, rather than assuming the existing paperwork automatically extends to a feature added after the fact.
- Ask directly whether Boost requires a separate consent exhibit or falls under the existing one, since the answer depends on how the original agreement's scope was written, not on how the two features feel similar from a teacher's seat.
- Default to the code-join option, no signed-in account, for the pilot itself while that confirmation is pending, since it keeps the data footprint smaller regardless of how the paperwork question resolves.
- Document the answer once you have it, so the next grade-level team asking the same question about Boost does not have to start the inquiry over from scratch.
- Share the outcome with your student-data-privacy officer, not just the requesting grade-level team, so the same Boost-coverage question does not need to be re-litigated the next time a different grade wants to pilot it.
Pro Tips for Getting a Straight Answer on This
- Ask for the specific exhibit or contract language, not a verbal confirmation, since "yes, we're covered" from a colleague is not the same as language naming Boost in a signed document.
- Separate the Common Sense Privacy score from the COPPA question in your own head before asking anyone else to. A high score is a real, useful signal; it answers a different question than "does our consent paperwork name this specific feature."
- Revisit the agreement annually, not just at initial signing. Boost's activity types have expanded since launch, and a scope negotiated for one configuration may not automatically cover a newer one.
- When in doubt, default to the lower-exposure configuration, code-join over signed-in accounts, teacher-mediated tools over Boost, while a specific answer is pending.
What to Avoid
- Assuming a signed National Data Privacy Agreement exhibit automatically covers every feature, including ones added after the agreement was signed. Scope, not existence, is what actually matters.
- Treating the 93% Common Sense Privacy score as equivalent to an FTC-approved Safe Harbor review. They are both real, but they are not the same mechanism, and only the latter is what COPPA itself formally recognizes.
- Enabling Brisk Boost tenant-wide before confirming whether the existing consent paperwork names it specifically. The teacher-mediated tools and Boost are different legal scenarios under COPPA's actual-knowledge and consent framework.
- Confusing a Student Data Privacy Pledge signature with a legal requirement. It is a voluntary industry commitment that signals intent, not a substitute for a district's own signed, scoped agreement.
Key Takeaways
- COPPA's verifiable-parental-consent requirement is triggered by an operator's "actual knowledge" of collecting data directly from a child under 13, and a school knowingly rostering under-13 students into a vendor's product supplies exactly that knowledge (FTC, Complying with COPPA: Frequently Asked Questions).
- Most of the product's tools, Targeted Feedback, Quiz Maker, Brisk Grader, and Inspect Writing, are teacher-triggered, with no direct child-operator interaction, which fits cleanly inside the school-as-agent consent pathway.
- Brisk Boost is structurally different: a student converses with it directly, which is the exact scenario COPPA's consent requirement addresses, making it the one feature a signed agreement needs to name explicitly.
- A district's existing agreement covering the teacher-side tools should not be assumed to automatically extend to Boost, since consent scope is defined by what was actually negotiated, not by the product's brand name.
- The 93% Common Sense Privacy score, including a 100% Parental Consent sub-score, is a real, independently reviewed signal, but it is a different mechanism than COPPA's own FTC-approved Safe Harbor program.
- No public evidence shows Brisk Teaching belongs to an FTC-approved Safe Harbor organization (iKeepSafe, PRIVO, or kidSAFE), leaving a district's signed, scoped agreement as the actual enforceable protection.
Frequently Asked Questions
Does Brisk Teaching need parental consent for every feature it offers?
Not in the same way for every feature. Most of its tools are triggered by a teacher submitting content already in hand, which fits the school-as-agent consent pathway cleanly, while Brisk Boost involves a student interacting directly with the product, the scenario COPPA's consent requirement was specifically written to address.
Is Brisk Boost legally different from the grading and feedback tools under COPPA?
Yes. Boost is the only feature where a student provides information directly to the operator in real time, matching COPPA's core "collection from a child" scenario, while the teacher-mediated tools involve a school employee submitting already-collected content instead.
Does a district's signed agreement automatically cover Brisk Boost?
Not necessarily. An agreement's consent scope covers what was actually negotiated and disclosed to the school, so a district should confirm directly whether Boost is named explicitly rather than assuming a general agreement extends to a feature added after the original signing.
Does the 93% Common Sense Privacy score mean Brisk Teaching is COPPA certified?
No. That score is a real, independently reviewed evaluation against Common Sense Media's own rubric, and its Parental Consent category scored 100%, but it is a separate mechanism from COPPA's own FTC-approved Safe Harbor program, which remains the only government-recognized vendor certification COPPA has.
Has Brisk Teaching been reviewed by an FTC-approved COPPA Safe Harbor organization?
No public evidence found for this article shows it belongs to a Safe Harbor program approved under 16 CFR § 312.11, such as iKeepSafe, PRIVO, or kidSAFE. That absence does not indicate wrongdoing, since participation is voluntary, but it does mean a district cannot point to that specific form of independent review.
Does a general district technology-use policy count as COPPA consent for Brisk Teaching?
Not on its own. The school-as-agent pathway requires a school to have specifically authorized the tool for an educational purpose and to have received the notices COPPA requires an operator to give, not just a broad acceptable-use policy signed at the start of the year. A named agreement or exhibit is what actually documents that specific authorization.
Related Reading
- AI, FERPA & COPPA: The Complete School Data-Privacy Guide (2026)
- Brisk Teaching and Student Data Privacy: What Teachers Should Know
- Is Brisk Teaching Safe for Students?
- Diffit and Student Data Privacy: What Teachers Should Know
- Google Gemini and Student Data Privacy: What Teachers Should Know
- Is EduGenius Safe for Students?
- Is Grammarly Safe for Students?
- SchoolAI vs Khanmigo: Which Is Better for Teachers?