Children's and Youth Privacy Toolkit: COPPA, Age Assurance, and Design Codes

By Casey Scott McKay · 2024-12-09

Children's privacy is the area where the gap between a company's belief about its audience and the regulator's view of it produces the largest enforcement exposure. This toolkit works COPPA - what makes a service directed to children, what actual knowledge means, and the verifiable parental consent mechanisms that are available and workable. It covers mixed-audience services and age screening design, then the state design codes that impose duties on product design rather than on data, including default settings, dark pattern prohibitions, and best-interests assessments. It sets out the teen privacy obligations that several state statutes now impose above the federal age threshold, the education technology overlay, and the deletion and retention rules. It closes with enforcement patterns and the programme that answers them.

IP and Technology > Privacy Data Security | Toolkit | Published 9 December 2024 - Updated 7 February 2025 | Casey Scott McKay - marksy.us

Summary. Children's privacy is the area where the gap between a company's belief about its audience and the regulator's view of it produces the largest enforcement exposure. This toolkit works COPPA — what makes a service directed to children, what actual knowledge means, and the verifiable parental consent mechanisms that are available and workable. It covers mixed-audience services and age screening design, then the state design codes that impose duties on product design rather than on data, including default settings, dark pattern prohibitions, and best-interests assessments. It sets out the teen privacy obligations that several state statutes now impose above the federal age threshold, the education technology overlay, and the deletion and retention rules. It closes with enforcement patterns and the programme that answers them.

Keywords: COPPA · directed to children · actual knowledge standard · verifiable parental consent · mixed audience services · age screening · age assurance · design codes · best interests of the child · default privacy settings · dark patterns and minors · teen privacy · data minimization for minors · targeted advertising to minors · school and edtech consent · FERPA overlay · safe harbor programs · deletion rights · enforcement exposure

Start Here

A gaming company insists its product is not for children. The terms require users to be thirteen or older. The marketing targets adults.

The regulator looks at the product's bright colours, its cartoon characters, its presence on children's app store charts, its child-focused influencer partnerships, and the survey data the company itself commissioned showing a substantial share of its users are under thirteen.

The company's terms of service are not the answer to any of that. Whether a service is directed to children is determined by its subject matter, visual content, characters, music, advertising, and audience evidence — including the company's own analytics.

This toolkit answers three questions.

Is the service directed to children, or does the company have actual knowledge of child users? That determines whether the federal regime applies at all.
What must be built if it does? Notice, verifiable parental consent, limits on use and disclosure, security, and deletion.
What applies above the federal age? State design codes and teen privacy provisions that impose duties on product design regardless of the child threshold.

If you read only one thing, read Building for Someone Who Cannot Consent. It works the directed-to-children analysis and the consent mechanisms in the order the questions arise.

Scope: Directed to Children

The statute. 15 U.S.C. § 6501 and following govern the online collection of personal information from children under thirteen, implemented by the rule at 16 C.F.R. § 312.2 and following.

Two routes into scope. The service is directed to children, or the operator has actual knowledge that it is collecting personal information from a child.

The directed-to factors. Subject matter. Visual content. Use of animated characters or child-oriented activities and incentives. Music or other audio content. Age of models. Presence of child celebrities or celebrities who appeal to children. Language or other characteristics of the service. Advertising on the service directed to children. And competent and reliable empirical evidence about audience composition or intended audience.

Audience evidence includes the company's own data. Analytics showing a substantial child user base is evidence, and it is discoverable.

Terms of service do not control. A minimum age requirement in terms nobody reads is not a factor, and asserting one while marketing to children is worse than useless.

Third-party services. An operator of a plug-in, advertising network, or analytics service that collects information from a child-directed service is itself subject to the rule where it knows or has reason to know it is collecting from such a service.

Actual knowledge arises from a user's own statement of age, a parent's communication, an internal report, or a report from another user — and once it exists, the obligations attach.

Which makes information handling a design question. A company that asks for a birth date acquires knowledge; one that does not may avoid it, and the trade-off is between actual knowledge exposure and directed-to exposure.

Personal information is defined broadly at 16 C.F.R. § 312.2 and includes persistent identifiers used for recognising a user over time and across services — which brings advertising and analytics squarely into scope.

Mixed Audience and Age Screening

The mixed audience concept. A service that is directed to children but does not target children as its primary audience may screen users by age and apply the full requirements only to those who identify as under thirteen.

The screen must be neutral. It must not encourage falsification — no "you must be thirteen to continue," no default date that passes the check, no ability to go back and change the answer after being blocked.

Neutral means a genuine open-ended request. A date-of-birth field with no indication of the consequence, or an age gate presented before any indication of what answer is favourable.

Session persistence. A user who fails the screen should not be able to retry immediately, and the result should persist through cookies or account state.

No collection before the screen. Persistent identifiers collected before the age determination are collected from an unknown user, and if that user is a child the collection has already occurred.

Which is the most common technical failure. Analytics and advertising tags firing on page load, before any age gate, on a service with child users.

Age assurance beyond self-declaration. Several state regimes and some product contexts call for more than a self-declared age — inference from behavioural signals, verification against records, or estimation. Each carries its own privacy cost, because verification collects more data about a child, not less.

Which is the central tension in this area. Stronger age assurance requires more data collection, and the regimes demanding it are the same regimes demanding minimisation. There is no clean answer, and the practical approach is the least intrusive method sufficient for the risk.

Document the choice. Why this method, what it collects, how long it is retained, and why a less intrusive method was insufficient.

Verifiable Parental Consent

The requirement. 16 C.F.R. § 312.5 requires an operator to obtain verifiable parental consent before any collection, use, or disclosure of personal information from a child.

The standard. A method reasonably calculated, in light of available technology, to ensure that the person providing consent is the child's parent.

Approved methods include a signed consent form returned by mail, fax, or electronic scan; a credit or debit card transaction that provides notification; a toll-free telephone call to trained personnel; a video conference with trained personnel; verification against government identification checked against a database and then deleted; and, in defined circumstances, knowledge-based authentication or facial recognition matched to a photo identification.

The email-plus method. For internal use only, an email to the parent with an additional confirming step, which is permitted where the information will not be disclosed.

Notice first. 16 C.F.R. § 312.4 requires direct notice to the parent and a clear online notice, describing what is collected, how it is used, disclosure practices, and the parent's rights.

Parental rights. 16 C.F.R. § 312.6 gives parents the right to review the information collected, to refuse further collection, and to direct deletion.

No conditioning. 16 C.F.R. § 312.7 prohibits conditioning a child's participation in an activity on disclosing more information than is reasonably necessary to participate.

Security and retention. 16 C.F.R. § 312.8 requires reasonable procedures to protect confidentiality, security, and integrity. 16 C.F.R. § 312.10 requires retention only as long as reasonably necessary and secure deletion afterwards.

Safe harbour programmes. 16 C.F.R. § 312.11 provides for approved self-regulatory programmes whose members are subject to the programme's review in lieu of formal enforcement, which is worth considering for services with significant child audiences.

Practical reality. Verifiable parental consent is expensive and produces friction that kills conversion. Most companies respond by avoiding the trigger — not collecting personal information from children, or building a genuinely separate child experience with no persistent identifiers and no advertising.

Design Codes

A different regulatory model, imposing duties on how a product is designed rather than on how data is handled.

The premise. Where a service is likely to be accessed by minors, the design of the service should serve their best interests — which reaches defaults, nudges, engagement mechanics, and information architecture rather than only data flows.

The likely-to-be-accessed standard is broader than directed-to-children, reaching general audience services with a meaningful minor audience.

Typical obligations. High privacy settings by default for minors. No profiling by default. Precise geolocation off by default, with a signal when it is active. No dark patterns that encourage minors to provide more data or weaken protections. Age-appropriate, clear privacy information. And no use of personal data in ways the service knows or should know are materially detrimental to a minor.

Assessments. Design codes typically require a documented assessment before a new service or feature is offered to minors, addressing the risks the design presents and the mitigations applied, with the assessment retained and available to the regulator.

Which is a product-development obligation. The assessment has to happen at design time, and a compliance function that reviews at launch is reviewing too late.

Constitutional litigation is active. Provisions requiring age estimation and those regulating content and curation have been challenged, and Moody v. NetChoice confirms that curation implicates expressive interests while leaving the substantive questions to be worked out. Data-handling and default-setting provisions have generally fared better than content-adjacent ones.

Which suggests where to invest. Default settings, dark pattern removal, and minimisation for minors are the obligations most likely to survive and are worth doing regardless. Age estimation mandates are the contested part.

Section 230 does not answer them. Duties on product design are not publishing duties, which is precisely why this legislative model is used. See Platform Liability and Section 230 Toolkit.

Practical approach. Build the defaults, remove the dark patterns, minimise for minors, and document a design assessment for any feature reaching them — because all of that is defensible, useful, and cheaper than litigating.

Teens

The age group that federal law largely ignores and state law increasingly does not.

Above thirteen, below eighteen. The federal rule stops at thirteen. Several state statutes impose obligations for minors up to sixteen or eighteen.

Targeted advertising. Several statutes prohibit processing a minor's personal data for targeted advertising without consent, or prohibit it outright for defined age bands.

Sale of personal data. Similar restrictions, frequently with an opt-in rather than an opt-out structure.

Profiling. Restrictions on profiling in furtherance of decisions with significant effects.

Which means age matters at two thresholds, and a service with mixed ages needs to distinguish under-thirteen, teen, and adult treatment.

Knowledge standards vary. Some statutes apply where the controller knows or wilfully disregards that the consumer is a minor, which is a lower bar than actual knowledge and reaches companies that avoided asking.

Wilful disregard is the provision to watch. A service with obvious minor users that declines to ask, precisely to avoid knowledge, is the fact pattern the standard was written for.

Personal data of a known child is sensitive data under most comprehensive statutes, requiring consent or an opt-out right depending on the state. See State Privacy Compliance Toolkit.

Deletion rights for minors. Several statutes give minors, or their parents, enhanced deletion rights over content they posted.

Practical approach. Build three tiers — under thirteen, thirteen to seventeen, and adult — with advertising and profiling off for the first two by default, and a documented basis for anything else.

Education Technology

A distinct context with its own consent architecture and its own failure modes.

School consent. Where a service is used by a school for an educational purpose, the school may in defined circumstances provide consent on behalf of parents under the federal children's privacy framework — provided the data is used solely for the educational context and not for commercial purposes.

Which is narrow. Advertising, profiling for non-educational purposes, and building products from student data fall outside it.

The education records framework. 20 U.S.C. § 1232g governs education records held by institutions receiving federal funding, and 34 C.F.R. § 99.31 permits disclosure without consent to a school official with a legitimate educational interest — the provision under which vendors are typically engaged.

The school official exception has conditions. The vendor must perform a function the institution would otherwise perform, be under the institution's direct control regarding use and maintenance, and comply with the redisclosure limits.

State student privacy statutes add obligations directly on vendors — prohibitions on targeted advertising, on profiling, and on selling student data, with deletion obligations on request from the school.

Which means the vendor is regulated directly, not only through its contract with the school.

Contracting. Institutions increasingly require specific terms — data use limitations, deletion on termination, breach notification, subprocessor restrictions, and prohibitions on secondary use — and a vendor without a standard rider will negotiate each one.

The recurring failure. A product built for consumers, sold into schools, with analytics and advertising integrations that were never removed.

Practical approach. A separate education tier with advertising and profiling disabled, a standard institutional rider, deletion on termination implemented in fact, and a documented analysis of the school consent basis relied on.

Building the Programme

Step one: the audience assessment. Analyse the service against the 16 C.F.R. § 312.2 factors, using the company's own analytics, app store categorisation, marketing materials, and any audience research. Write the conclusion down and date it. If the honest answer is that children use the service, that is the finding to act on rather than to argue with.

Step two: decide the model. Three options. Exclude children genuinely, with neutral age screening and no collection before the screen. Serve children with full compliance, including verifiable parental consent. Or build a separate child experience with no personal information collection at all — no persistent identifiers, no advertising, no analytics — which avoids the trigger entirely and is what most companies eventually choose.

Step three: fix the tag order. No analytics, advertising, or identifier collection before the age determination. This is the single most common technical violation and the easiest to fix.

Step four: build the tiers. Under thirteen, teen, and adult, with defaults set appropriately and advertising and profiling disabled for the first two.

Step five: the consent mechanism, where required, with the record showing method, date, and parent identifier.

Step six: notices. Direct notice to parents and the online notice under 16 C.F.R. § 312.4, written to be understood by the audience.

Step seven: parental rights. Review, refusal, and deletion under 16 C.F.R. § 312.6, with an operational workflow rather than an email address nobody monitors.

Step eight: retention and deletion. 16 C.F.R. § 312.10 requires deletion when no longer reasonably necessary, and an enforced retention schedule is the evidence.

Step nine: vendors. Every third party operating on a child-directed property is itself an operator. Inventory them, remove what is not needed, and contract for the rest.

Step ten: the design assessment, at feature design time, addressing risks to minors and the mitigations applied.

Step eleven: test it. Load the service as a new user and inspect what fires before the age gate. That test takes ten minutes and it is the one regulators run.

Enforcement Patterns

The cases in this area follow a small number of recognisable shapes, and knowing them tells a company where to look.

The service that said it was not for children. Terms requiring users to be thirteen, marketing aimed at adults, and analytics showing a large child audience. The terms are irrelevant; the evidence controls.

The persistent identifier case. A child-directed service with advertising and analytics tags, collecting identifiers that 16 C.F.R. § 312.2 treats as personal information, with no parental consent.

The tags-before-the-gate case. An age gate that works, on a service that fires identifiers on page load before the gate is answered.

The actual knowledge case. A company that received reports of child users — from parents, from moderators, from internal analysis — and continued collecting.

The third-party operator case. An advertising network or plug-in operating on child-directed services, itself an operator, without a compliance programme.

The retention case. Data from children retained indefinitely, contrary to 16 C.F.R. § 312.10, and surfacing in a breach.

The parental rights case. A review and deletion mechanism that exists in the notice and not in operation.

The education technology case. A consumer product sold into schools with its advertising integrations intact.

Penalties. Civil penalties per violation under 15 U.S.C. § 6505 and 15 U.S.C. § 45, calculated per child in practice, producing very large aggregate figures. Orders typically require deletion of the data collected, algorithmic or model deletion where the data trained something, and years of compliance reporting.

Deletion of derived assets is the remedy that has changed the calculation most. Where child data trained a model or built a profile system, an order to delete what was derived from it can be far more costly than the penalty.

State attorneys general enforce both the federal rule and their own statutes, frequently in coordinated actions.

Which is the argument for the audience assessment. The assessment is a day of work. The enforcement outcome includes a penalty, deletion of derived assets, and a decade of reporting.

Common Mistakes

Relying on terms of service. A minimum age requirement is not a factor in the 16 C.F.R. § 312.2 analysis, and asserting one while marketing to children is worse than saying nothing.

No audience assessment. Its absence is treated as an answer.

Ignoring the company's own analytics, which are evidence and are discoverable.

Tags firing before the age gate.

A non-neutral age screen that signals the right answer, or lets a blocked user retry immediately.

Treating persistent identifiers as non-personal. The rule says otherwise, and that is where most child-directed enforcement sits.

Avoiding knowledge deliberately, which the wilful disregard standards in several state statutes are written to reach.

A parental rights process that exists only in the notice.

Indefinite retention contrary to 16 C.F.R. § 312.10.

Third-party services unmanaged on child-directed properties, each of which is an operator.

Design assessments written at launch rather than at design time, when the obligation is to assess before offering the feature.

No teen tier, so a service treats a fourteen-year-old exactly as it treats an adult in states where it may not.

Consumer products sold into schools without an education tier and an institutional rider.

Age assurance that collects more data than the risk warrants, which trades one violation for another.

Worked Example: The Family App

A company operates a puzzle app with sixty million users. It believes its audience is adults.

The assessment. Analytics show a fifth of sessions come from devices with child-oriented usage patterns. The app store lists it in a family category in three markets. Two of its five influencer partnerships are with creators whose audiences are predominantly under thirteen. Its own user research describes "family play" as a core use case. The honest conclusion is that the service is at least mixed audience.

The decision. Full parental consent for a fifth of a sixty-million-user base is commercially impossible. The company builds a separate child experience instead: no account, no persistent identifiers, no advertising, no analytics beyond aggregate counts, and no social features.

The age screen. A neutral date-of-birth request at first launch, before any tag fires, with no indication of the consequence and no retry. Users under thirteen enter the child experience; others continue as before.

The tag order. Advertising and analytics tags moved behind the age determination. This was the largest engineering change and it took two sprints.

The teen tier. Users between thirteen and seventeen keep accounts and social features, with targeted advertising and profiling disabled by default, reflecting the state statutes that require it and applied universally rather than by state.

The design assessment. Written for the child and teen experiences, addressing engagement mechanics, notification patterns, and social exposure, with the mitigations applied.

The vendors. Eleven third-party services were present. Four were removed entirely, five were restricted to the adult experience, and two were retained under contracts reflecting their operator status.

Retention. A schedule applied to all minor-associated data, with deletion implemented and evidenced.

Parental rights. A workflow with an owner, a response target, and a record — replacing an email address that had received four hundred unanswered messages.

The result. Revenue from the child cohort fell to approximately zero, because it had been advertising revenue. The company accepted that, having priced the alternative.

The lesson. The commercially viable answer in this area is usually to build an experience that does not trigger the obligations, rather than to comply with them at scale. That is a product decision, and it should be made deliberately rather than discovered under an enforcement inquiry.

Diligence Questions

Is there an audience assessment, dated, against the 16 C.F.R. § 312.2 factors?

What do the company's own analytics say about user age distribution?

What app store categories does the product appear in, in which markets?

Who are the marketing partners, and what are their audiences?

Is there an age screen? Is it neutral, does it persist, and what fires before it?

Load the product as a new user and inspect the network traffic. What is collected before any age determination?

Is there a child experience, and does it collect personal information as defined by the rule?

Is there a teen tier, with advertising and profiling defaults appropriate to the state statutes?

How is verifiable parental consent obtained, and can consent records be produced?

Is there a parental rights workflow, with volume and response metrics?

What is the retention schedule for minor data, and is it enforced?

Which third parties operate on child-directed surfaces, and what do their contracts say?

Are design assessments completed before features reaching minors are released?

Is the product sold into schools? With what consent basis, what rider, and what advertising configuration?

Any inquiries, orders, or safe harbour programme membership?

Questions Clients Ask

Our terms say users must be thirteen. Does that protect us? No. The 16 C.F.R. § 312.2 factors do not include terms of service, and marketing to children while asserting an age limit is an aggravating fact rather than a defence.

We do not ask for age. Does that avoid actual knowledge? It may avoid actual knowledge under the federal rule. It does not avoid the directed-to-children analysis, and several state statutes reach wilful disregard, which is written for exactly that practice.

Is a cookie personal information? A persistent identifier used to recognise a user over time and across services is personal information under 16 C.F.R. § 312.2. That is why advertising and analytics on child-directed services are the centre of enforcement.

How do we get verifiable parental consent? Through one of the approved methods under 16 C.F.R. § 312.5. All of them create friction, and most companies restructure the product instead.

Can we use email to the parent? Only for internal use of the information, under the email-plus method with an additional confirming step.

Can we condition the game on giving us data? 16 C.F.R. § 312.7 prohibits conditioning participation on disclosing more than is reasonably necessary.

What do we do with a parental deletion request? Honour it under 16 C.F.R. § 312.6, across systems and vendors, and record it.

How long can we keep the data? Only as long as reasonably necessary to fulfil the purpose, then delete securely under 16 C.F.R. § 312.10.

Do design codes apply to us if we are not a children's service? The likely-to-be-accessed standard is broader than directed-to-children, so a general audience service with a meaningful minor audience can be in scope.

Are the design codes enforceable? The data-handling and default-setting provisions have generally fared better in litigation than content-adjacent ones, and Moody v. NetChoice leaves much unresolved. The defaults and minimisation obligations are worth building regardless.

Does Section 230 help? Not against design duties. 47 U.S.C. § 230 bars publishing claims, and duties on product design are not publishing duties.

We sell to schools. Does the school consent for us? In defined circumstances and only for the educational context. Advertising and commercial use fall outside it, and state student privacy statutes regulate the vendor directly.

What is the single most important thing? The audience assessment, honestly written. Everything else follows from what it concludes.

Sector Notes

Mobile games. The highest-exposure category. Bright visuals, character-driven design, family app store categories, and advertising monetisation that depends on the identifiers the rule treats as personal information.

Video and streaming. Content categorisation determines the analysis surface by surface — a children's section within a general service is child-directed even where the service is not.

Social platforms. Design code obligations, teen tier requirements, and the failure-to-warn and product design claims that Section 230 does not answer. See Platform Liability and Section 230 Toolkit.

Education technology. School consent, the framework at 20 U.S.C. § 1232g, state student privacy statutes reaching vendors directly, and institutional riders.

Connected toys and devices. Voice recordings, precise geolocation, and cameras, all engaging both the federal rule and the sensitive data provisions of the state statutes.

Health and wellness apps for families. Consumer health data statutes reaching data outside the federal health framework, plus the children's obligations.

Retail and consumer brands. Child-oriented product lines with their own microsites, which are frequently child-directed properties that nobody in legal has looked at.

Advertising and analytics providers. Themselves operators when serving child-directed properties, with the obligation attaching directly rather than through the publisher.

General audience services with minor users. The likely-to-be-accessed standard reaches them for design code purposes, and the wilful disregard standards reach them under state privacy statutes.

Working With Other Advisers

Product and design, who own the defaults, the age gate, the engagement mechanics, and the design assessment. This is the function the design codes actually regulate.

Engineering, who own tag ordering — the single most common technical violation and a change only they can make.

Analytics and data teams, whose own data supplies the audience evidence, and who should be asked for it before a regulator is.

Marketing, whose partner selection and app store categorisation are directed-to-children factors.

Monetisation, because the honest conversation about a child experience is a conversation about foregone advertising revenue, and it should happen with numbers.

Privacy counsel for the audience assessment, the consent mechanism selection, and the state statute mapping.

Education sales, where the product is sold into schools and the consent architecture is different.

Outside counsel with enforcement experience, because the remedies in this area — deletion of derived assets, model deletion, extended reporting — are unusual and shape how an inquiry should be handled from the first contact.

Cadence

At every new feature reaching minors. Design assessment written before release, addressing risks and mitigations.

At every marketing partnership. Partner audience checked, because it is a directed-to-children factor.

At every new third-party integration. Operator status assessed for child-directed surfaces, contract executed, and the integration restricted to the tiers where it belongs.

Monthly. Parental rights request metrics — volume, response times, and any unanswered.

Quarterly. Load the product as a new user and inspect what fires before the age gate. Review analytics for shifts in audience age distribution. Verify retention deletion is running.

Semi-annually. Age screen neutrality reviewed, teen tier defaults verified against current state statutes, vendor inventory refreshed on child-directed surfaces.

Annually. Full audience assessment refreshed and dated. Design assessments reviewed for continuing features. Training for product, engineering, marketing, and analytics teams. Board report on the child and teen audience and the compliance posture.

On any report of child users — from a parent, a moderator, an internal analysis, or a partner — escalate, because that is how actual knowledge arises and the obligations attach from that point.

On any app store recategorisation into a family or children's category, which changes the analysis.

The One-Page Position

Children's and youth privacy position — [service], [date]. Audience assessment completed [date]; conclusion [general audience / mixed audience / directed to children]; evidence relied on [analytics, app store category, marketing partners, research]. Estimated audience under thirteen [N] per cent; thirteen to seventeen [N] per cent. Model adopted: [exclusion / full compliance / separate child experience with no personal information collection]. Age screen: [in place since date], neutral [yes/no], persists [yes/no]; tags firing before the gate [none / list]. Tiers implemented: under thirteen [description], teen [advertising and profiling disabled], adult. Verifiable parental consent: method [X] under 16 C.F.R. § 312.5, [N] consents obtained, records retained. Notices: direct parental notice and online notice per 16 C.F.R. § 312.4, reviewed [date]. Parental rights: [N] requests, median response [N] days, [N] deletions executed. Retention: schedule applied [date], deletion verified [date]. Third-party operators on child-directed surfaces: [N] present, [N] removed, [N] contracted. Design assessments: [N] completed, [N] before release. Education deployment: [none / details with consent basis and rider]. Safe harbour programme: [member / not]. Enforcement history: [none / details]. Recommended actions: [move the tags behind the gate / build the teen tier / write the audience assessment / remove vendor X from the child surface].

A Closing Note

The distinguishing feature of this area is that the legal analysis is straightforward and the commercial conversation is not.

The rules are clear enough. What makes a service directed to children is a defined list of factors. What personal information means includes persistent identifiers. What consent requires is set out with the approved methods enumerated. None of it is genuinely uncertain.

What is difficult is telling a company that a fifth of its users are children, that the advertising revenue from those users is unlawful, and that the compliant alternatives are an experience that collects nothing or a consent process that will convert at a few per cent. That conversation is where the work actually is, and it goes better when it starts with the company's own analytics rather than with a regulator's.

The practical recommendation is therefore unusual for a compliance toolkit. Do the audience assessment first and honestly, even though — especially though — the answer may be inconvenient. Price the options. And make the product decision deliberately, because the alternative is having it made for you, retroactively, with a penalty calculated per child and an order to delete whatever that data built.

What This Costs

The audience assessment. A day, mostly spent pulling analytics and app store data that already exist.

Fixing the tag order. One to two engineering sprints, and it removes the most commonly enforced violation.

The age screen. Days of design and engineering, and the neutrality requirements are design constraints rather than added work.

The child experience. A real product investment where one is built, and the honest cost is the foregone advertising revenue rather than the engineering.

The teen tier. Configuration rather than construction in most products — defaults changed, advertising and profiling disabled for an age band.

Verifiable parental consent. Per-consent cost plus the conversion loss, which is why so few companies choose this path.

Design assessments. Half a day each, done at design time, and they double as product documentation.

Vendor cleanup. Contract work plus the integration removals, which frequently improves performance as a side effect.

Parental rights workflow. Modest, and it replaces an unmonitored mailbox that is itself a violation.

Against that: penalties calculated per child, orders requiring deletion of models and profiles derived from child data, years of compliance reporting, and the app store consequences that follow public enforcement.

The asymmetry is larger here than anywhere else in privacy practice, and the reason companies still get it wrong is that the compliant path costs revenue they can see and the exposure is a number they have not calculated.

A Suggested Reading Path

For the federal regime:

For the surrounding privacy work:

For the platform and design context:

Primary Authorities

| Authority | Proposition | |---|---| | 15 U.S.C. § 6501 | Definitions; child; operator | | 15 U.S.C. § 6502 | Collection restrictions; parental consent | | 15 U.S.C. § 6503 | Safe harbour programmes | | 15 U.S.C. § 6505 | Enforcement | | 16 C.F.R. § 312.2 | Directed to children; personal information | | 16 C.F.R. § 312.3 | General requirements | | 16 C.F.R. § 312.4 | Notice requirements | | 16 C.F.R. § 312.5 | Verifiable parental consent | | 16 C.F.R. § 312.6 | Parental review and deletion | | 16 C.F.R. § 312.7 | Prohibition on conditioning | | 16 C.F.R. § 312.8 | Confidentiality and security | | 16 C.F.R. § 312.10 | Data retention and deletion | | 16 C.F.R. § 312.11 | Safe harbour programmes | | 15 U.S.C. § 45 | Unfair or deceptive practices | | 20 U.S.C. § 1232g | Education records; FERPA | | 34 C.F.R. § 99.31 | Disclosure without consent; school official exception | | 18 U.S.C. § 2258A | Reporting obligations | | 47 U.S.C. § 230 | Platform immunity; design duties outside it | | Moody v. NetChoice | State regulation of platform curation | | California Age-Appropriate Design Code | Design duties and assessments | | TransUnion v. Ramirez | Standing for statutory claims |

Forms and Templates

Children's privacy compliance produces three artefacts that matter more than any policy document. The first is the audience assessment: a dated record analysing the service against the 16 C.F.R. § 312.2 factors, with the analytics data, the app store category, the marketing materials, and the honest conclusion. That document is the first thing a regulator asks for and the thing whose absence is treated as an answer in itself. The Portfolio Inventory Template adapts to the second: a per-service register showing the audience conclusion, the age screening method, the consent mechanism, the data collected from minors, the retention period, and the deletion practice. The third is the parental consent record, which must show the method used, the date, and the parent's identifier — because a consent that cannot be produced is a collection without consent. The License Agreement Template supplies the vendor architecture for third-party services operating on child-directed properties, which are themselves operators under the rule and whose contracts must reflect that.

Related Toolkits and Checklists

The State Privacy Compliance Toolkit covers the comprehensive statutes under which personal data of a known child is sensitive data requiring its own basis, and which impose teen protections above the federal age threshold. The Children's Privacy Compliance Checklist runs the assessment and build steps in order. The Platform Liability and Section 230 Toolkit covers the design-duty framing that makes minors legislation effective against platforms, because duties on product design are not publishing duties. And the Online Terms and Consumer Contracts Toolkit covers the dark pattern rules that apply with particular force to interfaces reaching minors.