Module 02G — COPPA, FERPA, and Student Data Privacy Law for Security Researchers

Non-Lawyers Summary

Two federal statutes govern the data of children and students: COPPA locks down personal information collected from kids under 13 online, and FERPA controls who can access education records. Neither statute was written with security researchers in mind, but both create landmines for anyone who finds vulnerabilities in apps, platforms, or school systems. If you pop a children's app and the data you're looking at includes birthdates, device IDs, or photos of kids under 13, COPPA is in the room. If you're inside a student information system or an ed-tech platform used by a school, FERPA is in the room. This module maps both statutes, their enforcement mechanisms, the worst breach disasters in the K-12 space, and exactly how to disclose responsibly when the victims are minors.

COPPA — Children's Online Privacy Protection Act (15 U.S.C. §§ 6501–6506)

The Setup: Before Everything Changed

In 2019, the Federal Trade Commission looked at YouTube. Not at hackers. Not at foreign adversaries. At a product launched by Google — a company that employs some of the most sophisticated engineers in the world — and concluded that it had spent years collecting behavioral data on children, feeding that data to advertising algorithms, and profiting from every click a six-year-old made on a cartoon video.

The settlement was $170 million. At the time, the largest COPPA penalty in FTC history.

But that wasn't the end of the story. In 2024, the DOJ filed a complaint against TikTok alleging the same pattern — and proposed a $1.5 billion penalty. The scale had changed. The playbook had not.

COPPA — the Children's Online Privacy Protection Act, 15 U.S.C. §§ 6501–6506 — was enacted in 1998. It has been quietly weaponized ever since.

Who Is a "Child"?

COPPA defines "child" as an individual under 13 years of age. That threshold is the pivot point for the entire statute. Age 13 is not arbitrary — it tracks the Senate's judgment in 1998 about the age at which minors could meaningfully consent to data collection. The statute has not been updated to change that number, though COPPA 2.0 proposals (discussed below) would raise it to 16.

There is no "we didn't know" defense once you have actual knowledge. The "actual knowledge" standard is where litigation lives.

The "Operator" Definition

Under 15 U.S.C. § 6501(2), an "operator" is any person who operates a website or online service directed to children, or any person who operates a website or online service and has actual knowledge that it is collecting personal information from a child.

This definition pulls in two distinct categories:

1. Child-directed sites/services — The FTC uses a multi-factor test to determine whether a site or service is "directed to children": subject matter, visual content, use of animated characters, music or activities popular with children, and advertising on the site. YouTube Kids, Roblox, Disney+, and children's gaming apps are all squarely in this bucket. Mixed-audience platforms — those not primarily directed to children but known to attract them — fall under a modified regime (see Section 4 below).
2. Sites with actual knowledge — An operator of a general-audience site that receives a parental email saying "my 10-year-old uses this" has actual knowledge and becomes subject to COPPA for that user's data going forward.

Security research implication: If you are pentesting a platform and you observe that it collects persistent device identifiers, geolocation, photos, or voice recordings from users who self-identify as under 13 — or who are clearly minors — you have stumbled into COPPA-regulated data. The operator of that platform has legal obligations around that data regardless of whether they are honoring them.

What Counts as "Personal Information" Under COPPA?

The FTC's 2013 amended rule (16 C.F.R. § 312.2) expanded the definition to include:

• First and last name
• Physical address (street and city or town)
• Online contact information (email, IM handle, social media username that allows direct contact)
• Screen name or user name that functions as online contact information
• Telephone number
• Social Security number
• Persistent identifier that can be used to recognize a user across websites or online services — this expressly includes cookies, IP addresses, processor or device serial numbers, and unique device identifiers
• Photograph, video, or audio file containing a child's image or voice
• Geolocation information sufficient to identify street name and city or town
• Information concerning the child or the child's parents collected in combination with any of the above identifiers

The 2013 expansion of "persistent identifier" is the category that catches most modern apps off-guard. A UUID assigned to an app install that tracks a child across sessions is COPPA-regulated personal information.

Verifiable Parental Consent (VPC) — The Hard Part

Before collecting, using, or disclosing personal information from a child under 13, an operator must obtain verifiable parental consent (VPC). This is the statute's hardest operational requirement.

The FTC's Rule (16 C.F.R. § 312.5) lists approved VPC methods:

Email plus — For lower-risk uses (internal operations, no disclosure to third parties), COPPA allows a simplified "email plus" consent: send an email to the parent, wait for a response, then send a confirmation. This is not sufficient for disclosure of data to third parties.

Why this matters for security research: When you find a children's app collecting persistent device identifiers, geolocation, or photos without any VPC mechanism, that is a COPPA violation sitting on your screen. The operator is collecting child data without consent. That's the core of what the FTC enforces.

Data Minimization and Retention Limits

15 U.S.C. § 6502(b)(1)(E) requires that operators collect only as much personal information as is "reasonably necessary" for the activity in which the child is engaged. The FTC's Rule (16 C.F.R. § 312.7) reinforces this: operators must retain children's data only as long as "reasonably necessary to fulfill the purpose for which the information was collected" and must then securely delete it.

There are no specific numeric retention limits in the statute or rule — no "delete after 90 days" bright line. The reasonableness standard is fact-specific. In enforcement actions, the FTC has focused on operators that retained children's data indefinitely with no data lifecycle management at all.

FTC Enforcement: Penalties That Stack

The FTC enforces COPPA under its Section 5 authority (15 U.S.C. § 45) combined with the civil penalty provision in COPPA itself (15 U.S.C. § 6504). Penalties are:

• Up to $51,744 per violation (2024 inflation-adjusted figure; originally $11,000 per violation when COPPA was enacted; the FTC adjusts annually per the Federal Civil Penalties Inflation Adjustment Act)
• Per violation means per individual child affected per day of violation — penalties stack rapidly in mass-data cases

Major enforcement actions:

FTC v. Google / YouTube (2019): The FTC and New York AG found that YouTube served behavioral advertising to children on YouTube Kids and on channels of the broader YouTube platform directed to children, without obtaining parental consent. YouTube collected persistent identifiers (cookies) tied to child viewers and monetized that data through targeted advertising. Settlement: $170 million — $136M to FTC, $34M to New York AG. Google also agreed to create a system to identify child-directed channels and block behavioral advertising on those channels. This remains the largest COPPA settlement in FTC history as of 2025.

FTC v. TikTok / ByteDance (2024 proposed consent order): The DOJ, acting on FTC referral, filed a complaint alleging TikTok and ByteDance violated COPPA and the 2019 consent order (from the Musical.ly acquisition) by continuing to collect personal information from children under 13 without verifiable parental consent, by failing to honor deletion requests, and by allowing children to bypass age-gating controls. Proposed penalty: $1.5 billion — the largest proposed COPPA penalty in FTC history. As of the Session 163 date (2026-04-17), this enforcement action was proceeding through the courts. Note: Verify current status before citing in external filings; propose as "proposed" or "pending" until final.

Other notable COPPA actions:

• United States v. Musical.ly (2019): $5.7M for collecting children's data without consent before TikTok rebrand — at the time, the largest COPPA penalty. The subsequent 2024 TikTok action alleged ByteDance violated the Musical.ly consent order.
• FTC v. Yelp (2014): $450,000 for collecting location data from minors during app registration.
• FTC v. W3 Innovations (2011): $50,000; first mobile app COPPA enforcement action.

COPPA 2.0 — Reform Proposals (2023–2024)

The Kids Online Safety Act (KOSA) and COPPA 2.0

Congress has been trying to update COPPA for years. The most significant recent proposal is COPPA 2.0 (introduced in multiple Senate sessions; latest version introduced by Senators Blumenthal and Markey in 2023-2024). Key proposed changes:

Age expansion — 13 to 16: COPPA 2.0 would extend COPPA protections from under-13 to under-16. This would bring U.S. law closer to the UK Age Appropriate Design Code (AADC / Children's Code), which the UK ICO enforces against services "likely to be accessed" by children under 18.

Design prohibition proposals: COPPA 2.0 includes provisions that would prohibit "design features" that exploit minors' psychology — autoplay, infinite scroll, push notifications, variable reward schedules — when deployed in services directed to children or likely to be used by them. This moves COPPA from a consent-and-disclosure statute toward a design-restriction statute, which is a significant conceptual shift.

Elimination of email-plus consent: The simplified email-plus method would be abolished, requiring stronger VPC for all uses.

Private right of action: Earlier versions of COPPA 2.0 included a private right of action for parents. This is politically contested and was stripped from some versions. As of 2025, no private right of action exists under COPPA — only FTC and state AG enforcement.

Status: COPPA 2.0 had not been enacted as of 2026-04-17. The Kids Online Safety Act (KOSA) passed the Senate in 2024 but faced House opposition. Monitor for updates.

Security research implication of potential age-16 expansion: If COPPA 2.0 passes, any platform with users ages 13-15 — which includes most social media, gaming platforms, and messaging apps — would need to implement VPC mechanisms for a dramatically larger user population. The attack surface for COPPA violations would expand significantly.

FTC COPPA Rule: 16 C.F.R. Part 312

The FTC's implementing regulation (the "COPPA Rule") went through major updates in 2000 (initial rule) and 2013 (expanded revision). The FTC initiated a further rulemaking in 2022 with proposed additional updates; final rule status should be verified for specific enforcement contexts.

"Actual Knowledge" Standard and Mixed-Audience Sites

For general-audience sites, COPPA attaches once the operator has "actual knowledge" of a child user. The FTC's guidance distinguishes two scenarios:

Child-directed sites (primary audience): Full COPPA obligations apply to all users by default. The operator cannot run behavioral advertising on these properties regardless of individual user age.

Mixed-audience sites (general audience with child subpopulation): The FTC created a modified approach. A mixed-audience site that has actual knowledge of a child user must comply with COPPA for that user's data, but need not treat all users as children. The operator may offer a "neutral age screen" (not a biased one — no asking age twice or pre-filling adult birthdays).

The Google/YouTube settlement clarified that channels on a platform can themselves be "directed to children" even if the platform overall is mixed-audience. This "channel-level" analysis is the current FTC standard for large platforms.

School Official Exception (16 C.F.R. § 312.5(b)(1))

Schools can consent to data collection on behalf of parents for school purposes. Under this exception, an operator can provide a service to a school and collect student data without direct parental consent if:

1. The school has obtained parental consent or is operating within the school's authority to consent on behalf of parents
2. The data collection is for an educational purpose
3. The operator is acting only as a data processor for the school's educational use — not for commercial purposes, not for behavioral advertising, not for building profiles for non-educational use

This is the exception that props up virtually the entire K-12 ed-tech industry. Platforms like Google Workspace for Education, Microsoft 365 Education, and thousands of smaller ed-tech apps operate under this exception. The legal risk is that many operators have pushed far beyond "educational purpose" into data monetization while claiming the school official exception covers them.

Security research implication: When you find an ed-tech platform collecting data beyond its stated educational purpose — building behavioral profiles, sharing data with ad networks, retaining data beyond the school year — you are looking at a potential COPPA school official exception violation. The school consented to one thing; the operator is doing another.

Operator as Data Controller

The COPPA Rule treats the operator as the responsible party for complying with parental consent, privacy notice, and data security obligations — not the parent and not the child. If a school deploys an ed-tech platform, the platform (operator) carries the COPPA compliance burden. The school carries the FERPA burden (next section). These two regimes run in parallel and sometimes conflict in ways that neither statute anticipated.

FERPA — Family Educational Rights and Privacy Act (20 U.S.C. § 1232g)

The Data No One Expected to Lose

In January 2025, the scope of what had happened at PowerSchool became clear. The company held student information system data for approximately 16,000 school districts — roughly 90% of the K-12 market. An attacker had used stolen credentials to access the customer support portal and had exfiltrated records for 50 million students. Names. Social Security numbers. Addresses. Medical records. IEPs documenting children with learning disabilities.

It was the largest K-12 data breach in U.S. history. And the law that was supposed to protect those children — FERPA — had no meaningful penalty to impose.

What happened next would expose a structural gap that had existed since 1974.

What FERPA Covers: Education Records

FERPA protects "education records" — records, files, documents, and other materials that (a) contain information directly related to a student and (b) are maintained by an educational agency or institution or by a person acting for or on behalf of the agency or institution.

This is broad. Education records include:

• Grades, transcripts, GPA
• Enrollment records, class schedules
• Disciplinary records
• Financial records (tuition, financial aid)
• Health records maintained by the school (important — if the school nurse keeps your records, FERPA; if your private doctor keeps them, HIPAA)
• Special education IEPs (Individualized Education Programs)
• Student ID numbers if used as identifiers
• Emails and electronic communications that constitute education records (faculty email advising a student on grades = education record content; the email system itself is not)

FERPA's Directory Information Exception

Educational institutions may disclose "directory information" without prior written consent if they have:

1. Notified students (or parents of minor students) what categories they have designated as directory information
2. Given them a reasonable time to opt out

Typical directory information categories: student name, address, telephone, email address, date and place of birth, major field of study, participation in school activities, dates of attendance, degrees earned, most recent previous school attended.

This matters for OSINT work: A school's directory information policy determines what personal data is publicly disclosable. Researchers often encounter student directories, alumni databases, and enrollment verification systems. If a student has opted out of directory information disclosure, even their name and email should not appear in publicly disclosed records.

What FERPA Explicitly Excludes

These records are NOT education records under FERPA:

Legitimate Educational Interest (LEI)

FERPA permits disclosure of education records to "school officials" with a "legitimate educational interest." This is FERPA's primary intra-institution disclosure mechanism. Every institution must define "school official" and "legitimate educational interest" in its annual FERPA notice.

The LEI concept is relevant to security researchers because:

• A school's IT department can access student records under LEI for technical administration
• A third-party vendor doing IT work for the school can access records under LEI if properly contracted
• An ed-tech vendor accessing student records beyond their contracted LEI is a FERPA violation

When a vendor's product — say, a student information system — is breached and student records are exfiltrated, two compliance failures can be in play simultaneously: (1) the vendor failed to protect data it was entrusted with under a LEI authorization, and (2) the breach itself may trigger state breach notification requirements.

FERPA Enforcement: The Toothless Tiger Problem

No Private Right of Action

Gonzaga University v. Doe, 536 U.S. 273 (2002), is the key case: the Supreme Court held that FERPA does not create a private right of action for individuals. You cannot sue your school in federal court under FERPA for disclosing your records. This is one of the most significant enforcement gaps in any major federal privacy statute.

What this means operationally: FERPA complaints go to the U.S. Department of Education's Student Privacy Policy Office (SPPO), formerly the Family Policy Compliance Office. The SPPO investigates complaints and can:

1. Find that the institution violated FERPA and require corrective action
2. Pursue formal enforcement proceedings
3. Recommend that the ED Secretary terminate federal funding to the institution

The Funding Withdrawal Nuclear Option — Never Used

FERPA's enforcement backstop is termination of federal funding to institutions that have a "policy or practice" of violating FERPA. This nuclear option has never been used in FERPA's history since 1974. The ED has been reluctant to pull funding from a school because doing so would harm the very students FERPA was designed to protect.

Instead, the SPPO typically:

• Issues a finding of violation
• Works with the institution to develop a "corrective action plan"
• Monitors compliance
• In egregious cases, refers to DOJ for enforcement — but DOJ enforcement is rare

The practical enforcement ceiling: A school that violates FERPA faces administrative process and potentially mandatory policy changes — not fines, not individual liability, not damages to affected students. This creates weak deterrence compared to COPPA (FTC civil penalties) or HIPAA (OCR civil monetary penalties).

State Law as the Real Enforcement Mechanism

Because FERPA itself lacks private rights of action and meaningful monetary penalties, plaintiffs in student data breach cases typically plead:

• State negligence claims (the school or vendor failed to exercise reasonable care to protect records)
• State unfair business practices (California UCL, for example)
• State breach notification violations (most states have notification laws that cover student PII)
• Contract claims (vendors who breach their data processing agreements with schools)

FERPA can appear in these cases as evidence of the applicable duty of care, even though FERPA itself doesn't provide the cause of action.

Student Data Breach Landscape

PowerSchool — The K-12 Apocalypse (2025)

PowerSchool is the dominant student information system (SIS) in the U.S., used by approximately 16,000 school districts serving 50+ million students — roughly 90% of the K-12 market in terms of SIS installations.

In January 2025, PowerSchool disclosed that an attacker had accessed its PowerSource customer support portal using compromised credentials and had exfiltrated data from its PowerSchool SIS student database. The breach exposed:

• Student names and Social Security numbers
• Birthdates and addresses
• Medical records (including IEP data)
• Grades and academic records
• Teacher and staff PII

The full scale of the breach was extraordinary — with 50+ million students in their system, PowerSchool became the single largest K-12 data breach in U.S. history. The company reportedly paid a ransom to receive a promise that the data would be deleted; extortion threats continued against individual school districts in subsequent months.

Legal aftermath:

• Class action lawsuits filed in multiple jurisdictions
• State AG investigations
• Congressional inquiry into ed-tech vendor security practices
• FTC investigation pending (FTC has authority under Section 5 to pursue unfair security practices even absent COPPA violations)

The PowerSchool breach illustrates the core vulnerability of the K-12 sector: extreme market concentration — one vendor holding data for most of the country's K-12 students — combined with weak FERPA enforcement incentives for vendors, creates catastrophic single-point-of-failure risks.

Los Angeles Unified School District (LAUSD) Ransomware — 2022

In September 2022, the Vice Society ransomware group hit LAUSD, the second-largest school district in the U.S. The attackers exfiltrated approximately 500GB of data including:

• Social Security numbers of students, staff, and contractors
• Disciplinary records
• Financial records including bank account information
• Student psychological evaluations
• Contractor payroll data

LAUSD refused to pay the ransom. Vice Society published the data. The disclosure included records of students with disabilities, children in foster care, and students who had been victims of abuse — categories of data that carry particular sensitivity under California Education Code.

Legal aftermath: Class action filed in C.D. Cal. alleging negligent data security. LAUSD is subject to California Education Code § 49073.1 (which requires student data protections), California AB 1182 (which limits school data sharing), and state breach notification law.

Infinite Campus and Other SIS Vendors

Infinite Campus is the second-largest K-12 SIS after PowerSchool. Multiple security researchers have identified API vulnerabilities in Infinite Campus deployments that exposed student data including enrollment status, grades, and contact information. Unlike PowerSchool, Infinite Campus breaches have generally been district-level — individual school district deployments with misconfigured instances — rather than vendor-wide.

Other notable K-12 breach patterns:

• Illuminate Education (2022): 820,000+ students in NYC public schools; exposed psychological assessments and disability records; Illuminate shut down after the breach
• Pearson (2018-2019): Student data from thousands of U.S. schools exposed via AIMSweb vulnerability; SEC charged Pearson with misleading investors about the breach in 2021

Ed-Tech Security Research: Legal Framework for Researchers

Pen Testing School Systems — The Authorization Problem

If you are hired to conduct a penetration test of a school district's systems, you face a layered authorization problem:

1. The district can authorize CFAA coverage for its own systems — computers, network infrastructure, administrative applications, email servers. The district is the operator of these systems.
2. The district cannot fully authorize access to SIS vendor systems. If the district's SIS is a cloud-hosted platform (PowerSchool, Infinite Campus, Skyward), the district is a customer of that SIS — it is not the operator. Conducting a pentest of the SIS platform requires authorization from the SIS vendor, not just the district. Going into the SIS without vendor authorization is outside the scope of a district engagement.
3. Student records remain FERPA-protected during testing. Even with full authorization, data you access during a pentest that constitutes FERPA-covered education records is still subject to FERPA's redisclosure restrictions. The district's authorization covers the technical access; it does not convert education records into non-FERPA data. Best practice: if you encounter actual student PII during testing, stop, document the exposure, and report it — do not exfiltrate, do not read further than necessary to establish the finding.
4. COPPA during testing: If student data you encounter during an ed-tech pentest includes personal information of students under 13, COPPA's restrictions on that data attach to the operator (the vendor), not to you. You cannot violate COPPA as a pentester by viewing data during an authorized test. But the operator's failure to protect that data is a COPPA security violation that you should document and report.

Responsible Disclosure to School Districts

School districts are not tech companies. They do not have security teams, VDPs, bug bounty programs, or incident response procedures. Responsible disclosure to a district requires adapting the standard CVD process:

Who to contact:

• The district's IT department (usually listed on the district website)
• If no IT contact, the district's superintendent office
• If the vulnerability is in a vendor platform (SIS, LMS), contact the vendor directly AND notify the district
• For severe vulnerabilities (active data exposure, ransomware risk), consider also notifying CISA's K-12 security team — CISA has specific programs for K-12 sector

Timeline expectations: 90-day disclosure timelines assume the vendor can triage and patch quickly. School districts often run legacy systems, have annual budget cycles that govern upgrades, and have minimal IT bandwidth. Flexible timelines (120-180 days) are appropriate when working with districts on district-level vulnerabilities. For vendor platforms, standard 90-day timelines apply.

Data handling: If you captured screenshots or evidence containing actual student PII, your evidence package needs careful handling. Do not post student data publicly even in sanitized bug reports. Redact all student-identifiable information from public disclosures. Note in your disclosure that you captured evidence but have not published it and are prepared to share only with the affected party.

No bug bounty: Almost no K-12 districts have bug bounty programs. Do not expect payment. This is vulnerability research in the public interest.

State Student Privacy Laws

California SB 1177 — SOPIPA (Student Online Personal Information Protection Act, 2014)

Cal. Education Code §§ 22584-22585, operative January 1, 2016. SOPIPA prohibits operators of ed-tech products used in K-12 from:

• Using covered information for behavioral advertising — an operator cannot use student data to serve targeted ads to a student on any platform, not just the school platform
• Building a profile for non-educational purposes — cannot aggregate student data to build a commercial profile
• Selling or renting student information
• Disclosing covered information except for school purposes, with legal process, or with consent

SOPIPA applies to operators of websites, online services, online applications, and mobile applications "designed and marketed" for K-12 school purposes. The "designed and marketed" standard is narrower than COPPA's child-directed test — a general-audience tool used by a school is not necessarily SOPIPA-covered unless it was designed and marketed for K-12.

Enforcement: The California AG can enforce SOPIPA. No private right of action (similar to FERPA). Civil penalties up to $2,500 per intentional violation.

SOPIPA's national influence: At least 47 states have passed student data privacy laws modeled on SOPIPA or addressing similar concerns. The Student Data Privacy Consortium tracks these laws.

New York Education Law § 2-d

New York's student privacy statute (L. 2014, ch. 56, Part B; Education Law § 2-d) applies to educational agencies and their third-party contractors. Key provisions:

• Requires written data sharing agreements between educational agencies and third parties
• Prohibits contractors from selling student data or using it for advertising
• Requires third-party contractors to implement data security protections
• Mandates a Parents' Bill of Rights for Data Privacy and Security — each educational agency must post this on its website
• Requires notification to parents within 60 days of discovering a breach of student data

Regulations (8 NYCRR Part 121): The New York State Education Department implemented detailed regulations including requirements for data encryption, access controls, employee training, and annual security reviews.

Enforcement: The NYSED can investigate complaints, require corrective action, and terminate contracts with vendors. No private right of action under § 2-d, but the requirement for breach notification ties into New York's general breach notification law (NY GBL § 899-aa), which can trigger AG enforcement.

Colorado SB 21-231 — Student Data Transparency and Security Act

Effective July 1, 2022. Colo. Rev. Stat. §§ 22-16-101 through 22-16-115. Applies to educational agencies and "operators" (vendors).

Key provisions:

• Requires operators to implement and maintain reasonable security procedures appropriate to the nature of the covered information and the risks of unauthorized access
• Prohibits using student data for non-educational purposes
• Requires deletion of student data upon contract termination or upon written request
• Operators must provide annual security certifications to educational agencies
• Breach notification within 30 days to the educational agency; the agency then notifies parents

Notable feature: Colorado SB 21-231 explicitly allows educational agencies to conduct or authorize security assessments of operator systems as part of vendor oversight — one of the few state laws that affirmatively addresses security testing in the ed-tech context.

COPPA and Security Research: Practical Scenarios

Children's Apps VDP Landscape

The children's app market is largely VDP-deficient. Major platforms with significant child usership — Roblox, Minecraft (Microsoft), YouTube Kids — have formal bug bounty programs through which researchers can report vulnerabilities. Most smaller children's apps and mobile games do not.

HackerOne and Bugcrowd programs relevant to COPPA:

• Roblox maintains an H1 program covering platform vulnerabilities including those that could expose user data
• Google's VRP covers YouTube Kids and Google Play
• Microsoft's MSRC covers Minecraft and Xbox, both of which have significant minor-user populations

When a children's app has no VDP and you find a vulnerability involving COPPA-regulated data, your disclosure options are:

1. Direct disclosure to the company's security or legal contact
2. CERT/CC or US-CERT as intermediary
3. State AG notification if the violation is ongoing and the company is non-responsive
4. FTC complaint (the FTC has a children's privacy complaint form specifically for COPPA violations)

FTC Safe Harbor Programs — CARU and kidSAFE

The COPPA Rule (16 C.F.R. § 312.11) allows the FTC to approve "safe harbor" programs — industry self-regulatory organizations that implement COPPA-equivalent protections. Companies that participate in a safe harbor program and comply with its requirements have a complete defense to FTC enforcement for conduct covered by the program.

CARU (Children's Advertising Review Unit): Operated by the BBB National Programs. CARU's COPPA Safe Harbor Program covers advertising to children and data collection by participating operators. FTC-approved. Companies in the CARU program include many children's media and app companies.

kidSAFE Seal Program: Another FTC-approved safe harbor. More commonly seen on children's apps and games. Companies with the kidSAFE seal have committed to complying with kidSAFE's data protection standards, which are COPPA-equivalent.

Researcher implication: If you find a vulnerability in a CARU or kidSAFE member company, the responsible disclosure path should include notifying the safe harbor organization, not just the company — the safe harbor program has its own compliance oversight function and may require the member to remediate as a condition of continued membership.

What Happens When You Find COPPA Violations During a Pentest

Scenario: You are conducting a pentest of a mobile app. You discover that the app collects geolocation and device identifiers from users who self-identified as under 13 during registration, sends that data to third-party advertising SDKs, and has no VPC mechanism. This is a COPPA violation.

Your obligations:

1. Document the finding — screenshots, traffic captures, API responses showing the data flow to advertising SDKs
2. Report within scope — this finding goes in your pentest report as a high-severity data privacy finding
3. Advise your client — if your client is the company operating the app, they need to remediate and need to determine whether to self-report to the FTC. Voluntary self-reporting is not a COPPA requirement but the FTC does consider cooperation in penalty calculations.
4. If your client is not the operator — if you discovered this while doing a third-party assessment, your disclosure goes to the operator. You are not personally liable for the operator's COPPA violation. But if you discovered it while working for a school that deploys the app, the school has grounds to terminate the vendor relationship.
5. FTC complaints — you can file a COPPA complaint with the FTC. The FTC does not reveal complainant identity, but you should understand that voluntary FTC complaint is a form of reporting to a federal regulator.

COPPA does not create personal liability for security researchers who discover and document violations — the statute targets operators. Your risk as a researcher is under CFAA (unauthorized access), not under COPPA.

Safe / Grey / Red Matrix

Key Statutes Quick Reference

Practitioner Takeaways for Security Researchers

• COPPA is an operator problem, not a researcher problem. When you find COPPA violations during authorized testing, document them, report them, and let the client decide on FTC disclosure. You are not the liable party.
• FERPA data during testing: look and document, don't take. If you encounter genuine education records during an authorized pentest, capture enough evidence to prove the exposure finding, then stop. Do not read student records for curiosity, do not exfiltrate datasets, do not include identifiable student PII in your public bug report.
• Ed-tech vendor vs. school authorization: get both. If you want to test a cloud SIS platform, get authorization from the vendor, not just the school. The school cannot authorize access to systems the vendor operates.
• FERPA's no-private-right-of-action gap means state law is the real stick. If you are advising a student victim of a data breach, think negligence, state consumer protection, and state breach notification — not FERPA directly.
• PowerSchool is the cautionary tale. A single vendor holding 90% of the K-12 SIS market, with a customer support portal breach exposing 50+ million students, is the predictable outcome of market consolidation without commensurate security requirements. Expect more.
• COPPA 2.0's potential age-16 expansion changes everything. If enacted, platforms currently treating 13-15 year olds as general adult users will need VPC mechanisms for a massive user segment. The compliance burden — and the attack surface for violations — will grow dramatically.

Quiz

See: artifacts/quizzes/quiz-02g.md