COPPA AI compliance checklist with owners, evidence, and pass conditions

A COPPA AI compliance checklist should produce a graded pass and a named gap owner, with the evidence attached. Imagine a child-facing tutor sending a voice clip and chat history to an LLM. Product must document the audience while privacy approves the notice and consent path. Engineering constrains collection and destination while security tests the safeguards. Records staff run the scheduled deletion. I would reject any checklist that ends with "review policy" because nobody can grade that action during an FTC inquiry.

TL;DR

• Assign one accountable owner to every COPPA action and name the supporting artifact before launch.
• Grade scope and notice, then consent and parental rights. Grade minimization and security, followed by vendors and retention, with explicit pass conditions.
• Test the child-facing AI route using synthetic data, including an approved request and a prohibited destination. Also test revocation and deletion.
• Treat gateway records as bounded technical evidence. Privacy and product retain their decisions. Counsel, IAM, vendor management, and records owners retain theirs.

1. Confirm the operator and audience scope

The current COPPA Rule covers child-directed commercial websites and online services that collect personal information, along with general-audience operators in the specified actual-knowledge circumstances.

• Action: document the operator and service. Record the target audience and actual-knowledge signals. Add mixed-audience treatment and collection points. Identify every AI component receiving child data.
• Owner: privacy counsel, with product providing service facts.
• Evidence: signed scope memo and audience research. Attach marketing materials and the age-screen design. Include the data-flow diagram and system inventory.
• Pass condition: the memo reaches each production collection point and model destination, and it records unresolved facts under a current approval.

2. Inventory personal information and collection

The Rule's definition includes names and contact details. It also includes persistent identifiers and images, voice and specified geolocation, government identifiers and biometrics, plus combined information. AI interfaces can gather these through prompts and uploads. They can also gather them through microphones and profile context, as well as telemetry.

• Action: map each field and free-text channel to its purpose and source. Record its storage and recipient. Assign the governing retention rule to each.
• Owner: product privacy lead and data engineering.
• Evidence: field inventory and prompt template register. Attach the SDK list and telemetry schema. Include captures from every tested data flow.
• Pass condition: a synthetic test traverses every collection path and the inventory matches observed payloads.

Student data privacy in EdTech AI explains the separate FERPA and school-vendor questions when a classroom service is involved.

3. Make notice match the AI data flow

The notice provision requires direct and online notices describing collection and use. The notices also describe disclosure and recipients, plus purposes and retention. A model-provider change can alter the facts presented to parents.

• Action: compare notice text with the live prompt route and model provider. Check the subprocessors and purpose. Confirm the configured retention period and trigger.
• Owner: privacy, with engineering attestation.
• Evidence: approved notice version and parent delivery record. Attach the route inventory and change ticket. Include the approved material-change assessment and date.
• Pass condition: every observed recipient and use appears in the effective notice, and a material change triggers the approved re-notice and consent workflow.

4. Verify parental consent and disclosure choice

The consent provision generally requires verifiable parental consent before collection and before any use or disclosure, subject to listed exceptions. The amended Rule also requires separate consent for a third-party disclosure that is not integral to the service.

• Action: connect each child account and covered collection purpose to the applicable consent record or documented exception.
• Accountable owner: the privacy operations team.
• Evidence: consent method and parent verification result. Record the notice version and authorized purposes. Add the disclosure choice and timestamp. Include the revocation status and exception rationale.
• Pass condition: the service blocks covered collection until the required state exists, and tests prove that a disclosure refusal selects the constrained route.

The FTC's COPPA compliance guide gives current staff guidance on scope and notices. It also covers consent methods and rights, plus schools and safe harbors.

5. Exercise parental access and revocation, then deletion

The parental-rights provision requires a reasonable means for a verified parent to review a child's information. The same provision lets that parent refuse further use or collection and direct deletion.

• Action: run an authenticated request through intake and search. Complete the review and revocation. Then complete deletion and response.
• Owner: privacy operations, supported by identity and data teams.
• Evidence: request ticket and parent-verification event. Record the systems searched and produced record. Add the suppression state and deletion result. Include the exception and closure approval.
• Pass condition: the synthetic child's retrievable data is produced. Future covered collection stops after revocation, and deletion reaches each governed system.

6. Enforce data minimization in the interface

The minimization provision bars conditioning participation on more personal information than is reasonably necessary. A conversational interface can invite excess detail.

• Action: challenge every mandatory field and prompt instruction against the activity's purpose. Review each profile injection and memory feature. Review every request for an attachment.
• Owner: product manager, approved by privacy.
• Evidence: necessity decision and interface copy. Attach the test script and rejected-field list. Include every approved exception and its owner.
• Pass condition: the child can complete the activity without supplying fields rejected by the necessity review, and synthetic overcollection tests trigger the designed response.

7. Operate the written security program

The security provision requires a written program and coordinator. It also requires a risk assessment at least annually and safeguards. The program must include regular testing and monitoring, evaluation, and relevant provider assurances.

• Action: place child-facing AI threats and provider routes inside the security program. Include prompt content and credentials. Add storage and parental workflows.
• Accountable owner: the designated security coordinator.
• Evidence: current risk assessment and safeguard register. Attach test results and monitoring records. Record each finding with its remediation owner. Include the dated annual program evaluation.
• Pass condition: each identified material risk has an operating safeguard, recent test, accountable remediation owner, and approved disposition.

8. Constrain service providers and third parties

An operator must take reasonable steps before allowing relevant entities to collect or maintain children's information and obtain required written assurances. Procurement paperwork should match the endpoint receiving production prompts.

• Action: reconcile contracts and subprocessors with observed traffic. Check model accounts and regions. Confirm purposes and security assurances. Verify the provider's contractual deletion terms.
• Owner: vendor management and privacy.
• Evidence: diligence file and executed terms. Attach the subprocessor register and provider configuration. Include the route test and reassessment date.
• Pass condition: each observed destination has approved terms and assurance evidence, while an unapproved destination is blocked or removed.

Use the AI vendor due diligence checklist for the wider procurement review.

9. Apply purpose-bound retention and deletion

The retention provision limits storage to the period reasonably necessary for the collection purpose and prohibits indefinite retention. The written policy must pair the purpose and business need with a deletion timeframe.

• Action: set and test retention for prompts and outputs. Cover consent data and support copies. Include model-provider records and backups. Set retention for audit evidence.
• Owner: records management, with privacy and system owners.
• Evidence: written retention policy and configured schedules. Attach deletion jobs and the exception register. Include provider confirmations and test results.
• Pass condition: expired synthetic records disappear through the documented process, and every surviving copy has an approved purpose plus disposal date.

The FTC's 2025 final amendments provide the rulemaking basis for the updated security and notice provisions, along with disclosure and retention provisions.

10. Test the routed LLM control point

Where the application routes authenticated HTTP traffic to an LLM, test a consented request to an approved endpoint. Then test prohibited variants that carry excess data or revoked consent, plus one that targets an unapproved destination.

• Action: execute synthetic allow and redact cases. Run deny and error cases. Complete a test after the policy version changes.
• Accountable owner: the AI platform security team.
• Evidence: test plan and expected outcomes. Record request IDs and policy version. Add the classifications and selected model destination. Include decisions and integrity data. Obtain approval from the named reviewer.
• Pass condition: actual results match approved policy and every test event is retrievable through a stable reference.

FERPA and AI compliance describes the school-official and education-record layer that is separate from this COPPA checklist.

DeepInspect

DeepInspect can enforce the tenth item on authenticated HTTP AI traffic that an application routes through the proxy. The application supplies identity and age or audience context. It also supplies purpose and consent-related policy inputs. DeepInspect evaluates those fields against the prompt classification and model destination under a versioned rule, then permits, redacts, denies, and records the outcome.

Its per-decision record can support test evidence and route reconciliation. Parental consent and legally sufficient notice sit outside that record. Parent authentication and application-database deletion require separate systems. An opaque embedded-vendor path also remains outside the proxy boundary. Privacy and product retain those controls, alongside IAM, records, and vendor owners. Book a demo today.