Children’s Privacy Code: What Canadian Brands Should Audit Now

2026-10-22 · 13 min read

OPC launched Canada’s first Children’s Privacy Code. Audit consent UX, under 13 parental consent, age assurance, and third-party tools on youth-accessible pages.

Children’s Privacy Code: What Canadian Brands Should Audit Now

What To Review Now: Consent Language, Under 13 Parental Consent, Age Assurance, And Third Parties

If you market to families, run youth-facing experiences, or collect personal information from minors, your website, forms, and tracking setup now sit in a hotter spotlight.

On October 20, 2026, the Office of the Privacy Commissioner of Canada (OPC) announced that Privacy Commissioner of Canada Philippe Dufresne launched Canada’s first Children’s Privacy Code. The OPC frames the Code as practical expectations for organizations that handle children’s personal information, and as help for protecting children under Canadian privacy law, including PIPEDA.

For lean teams, the immediate question is operational: where could your current consent language, age checks, and third-party tools fall short of the Code’s expectations, especially on youth-touching pages that quietly collect analytics and marketing data in the background.

What Changed, And Why Small Teams Feel It First

The OPC describes Canada’s first Children’s Privacy Code as aimed at “creating a safer, more transparent online environment for children and teens.” In the same announcement, the OPC says the Code “establishes clear, practical expectations for organizations that handle children’s personal information” and “helps organizations understand how to protect children under Canadian privacy law.”

One practical implication for service firms, e-commerce brands, and education organizations is scope creep. A business can consider itself “not for kids” and still end up with children’s personal information moving through forms, booking tools, embedded video, chat widgets, learning tools, and analytics tags that load on youth-accessible pages.

The OPC also ties this to its long-held position under PIPEDA: while PIPEDA does not expressly distinguish between the privacy rights of children and adults, the OPC has consistently taken the position that children’s personal information warrants heightened protection. That matters because it sets the tone for what regulators expect you to build into privacy design, even if your marketing is not explicitly aimed at children.

Audit Area 1: Consent Language And Consent UX

Meaningful Consent, Calibrated To A Child’s Evolving Capacity

The Code’s “Consent” expectation states: “Organizations must obtain meaningful consent for the collection, use and disclosure of children’s personal information, calibrated to the child’s evolving capacity.” For teams used to a single all-purpose checkbox, this expectation pushes you toward clearer, more situational consent moments.

The Code also draws a hard line around optional processing: “Non-essential data uses should require express, opt-in consent with separate choices offered for each optional feature or enhancement.” It defines “non-essential purposes” as “those that go beyond what is necessary to provide the core product or service.”

Where SMB Websites Commonly Trip: Optional Features Hidden Inside “One Consent”

A useful way to run this audit is to treat every “optional feature or enhancement” as a separate decision point. The Code calls out the need for separate express opt-in choices, which makes one bundled “agree to all” flow risky on youth-touching pages.

Identify each optional feature or enhancement that uses youth data, then verify there is a separate express opt-in choice for each optional feature or enhancement.
Check whether consent is being inferred from “inaction” or “the child’s continued use of a service.” The Code says consent design should not infer consent from those behaviours.
Confirm you support “withdraw consent at any time” for “children and their parents or guardians.”

No Forced Consent For Non Essential Uses

The Code includes an anti-forced-consent rule that has direct UX implications: “Organizations should also not make access to a product or service, or the quality or functionality of that product or service, conditional on a child or parent providing or maintaining consent to non-essential uses of the child’s personal information.”

For marketing and growth leads, this is where conversion tactics can collide with compliance. If the page is likely to be accessed by children, gating a core service behind “yes” to optional tracking, personalization, or extra sharing turns into a clear risk area. The trade-off becomes product and funnel design, because you may need to separate what is truly required to provide the service from what improves measurement or marketing.

Use Notices People Can Actually Understand In The Moment

The OPC’s “Guidelines for obtaining meaningful consent” pushes teams away from depending on a long privacy policy alone. It says organizations are encouraged to use communications strategies such as “just-in-time” notices, interactive tools and customized mobile interfaces to explain privacy practices.

The same guidance stresses that consent processes must take into account the consumer’s perspective, and that consent is only valid where the individual can understand what they are consenting to. When information flows are complex or involve multiple parties, the OPC says the organization should ensure users can access and understand all key elements. For youth-touching pages, “multiple parties” often means third-party scripts and embeds that receive data.

The OPC also frames privacy programs as something you revisit: as a best practice, organizations should periodically audit their information management practices to ensure that personal information continues to be handled in the way described to individuals. If your site has accumulated new tags and plug-ins over time, this audit expectation lands directly on marketing and web operations.

Audit Area 2: Age Checks And Age Assurance

When A Policy Statement Stops Being Meaningful

The OPC’s “Assessing whether and how to use age assurance - Guidance for websites and online services” is aimed at operators deciding whether they are required to use age assurance and how to apply it in a privacy-protective manner. One of its clearest operational warnings is about relying on policy language as a substitute for enforcement: “An unenforced statement in a privacy policy that individuals under a given age are not intended or permitted to use the site or service would not be a meaningful factor in establishing the actual age demographics of users.”

This is a second-order issue for small teams: you can have “good” written policies and still run a system that behaves like it expects child users, because the experience never checks. From a risk perspective, the interface you run matters as much as the PDF you publish.

A Risk Based Bar For Certainty About Age

The Code describes a sliding expectation: “Where risks are higher, organizations will be expected to have a greater degree of certainty about the age of their users, which may require more robust measures such as parental confirmation or age assurance tools.” It also adds: “Where sufficient certainty cannot be achieved, protections should be applied to all users as a default.”

That last sentence has a practical impact on marketing stacks. If your team cannot reach sufficient certainty, applying protections to all users by default can change what tools you run on key pages, what gets loaded automatically, and what gets deferred until an appropriate consent choice is made.

What Age Assurance Looks Like In Practice, And What Often Fails

The OPC’s “Global Privacy Enforcement Network (GPEN) Sweep Report: Children’s Privacy” summarizes common approaches to age assurance:

Self-declaration (a user states their age but is not required to provide evidence).
Age verification (a user is asked to verify their age, for example by providing a form of ID).
Age estimation (a user’s age is estimated, often by algorithmic means, for example facial age estimation).

The same report provides useful numbers that explain why audits are being pushed now. It reports that the terms of service for 62% of all websites and apps reviewed (517 out of 832) explicitly limited access to users over a certain age, most often 13 years of age. Of those with age restrictions, 32% (164 out of 517) did not use any age assurance mechanisms at all.

Among organizations that did use mechanisms (353), the sweep reports: self-declaration (88%, or 311 out of 353), age verification (11%, or 38 out of 353), and age estimation (5%, or 19 out of 353). It also reports circumvention: sweepers were able to circumvent age assurance measures used in 72% (460 out of 641) of cases, most often where self-declaration was used.

The report also explicitly compares GPEN 2015 results to later results: participants in the GPEN 2015 Sweep reported that only 15% used a form of age assurance. A decade later, 45% deployed a form of age assurance, an increase of 30%.

Audit Area 3: Third Party Tools And Profiling

Third Party Sharing Off By Default

The Code states: “Sharing of a child’s personal information with third parties should be off by default.” It adds: “Data must not be disclosed to third parties unless the child, parent or guardian has consented.”

This is where many marketing stacks break in quiet ways. It is common for third-party scripts to transmit data as soon as a page loads, before anyone makes a choice. On pages likely to be accessed by children, that default behaviour runs directly against the “off by default” expectation.

The Code also warns against papering over this with general legal language: “Blanket consent obtained through terms of service would likely not satisfy this expectation.”

Profiling And Targeted Or Behavioural Advertising

The OPC news release lists an expectation to “Avoid profiling children for marketing purposes, including targeted or behavioural advertising, or for the purposes of AI (artificial intelligence)-driven decision-making.”

The Code’s “Avoiding profiling” section states that organizations should not use children’s personal information to deliver targeted or behavioural advertising to them, infer characteristics from children’s digital activities that can be used to target them commercially, or share children’s profile data with third parties for advertising or marketing purposes. It also states: “Profiling of children should be off by default.”

For an SMB, this can create a hard choice: the same pixels and audiences that improve marketing measurement can also function as profiling infrastructure. A clean audit result often means creating separate “youth paths” where those tools are disabled by default, and where any optional enhancements only run after express opt-in consent for each optional feature or enhancement.

Deceptive Design Patterns

The news release states the Code outlines that “websites and mobile apps cannot use deceptive design practices to influence, manipulate, or coerce children to provide more personal information than they need to, or use children’s information to exploit their vulnerabilities.”

The Code also states: “Organizations must not use deceptive design patterns to deceive children into disclosing more personal information than they would otherwise choose to share or undermine their ability to exercise meaningful privacy choices.” For marketers, “design patterns” includes the mechanics of prompts, defaults, nudges, and friction, not only page copy.

Two Tests That Catch “We Don’t Target Kids” Businesses

Likely To Be Accessed By Children

The Code includes indicators that can pull in organizations that did not set out to build a children’s product. It points to factors such as third-party advertisers placing ads directed at children on an organization’s website, the presence of content, design features or activities appealing to children, and whether children are known to access similar websites and services.

The OPC’s age assurance guidance also frames “relevant factors” and repeats a key point: an unenforced statement about underage users in a policy does not meaningfully establish actual age demographics.

Under 13: Parental Consent Expectations

The OPC news release includes “parental consent for those under 13” as an expectation. The Code is explicit: “Where a child is under 13, parental consent is always required.” It also states, “In all but exceptional circumstances, organizations must obtain consent from a parent or guardian” for children under 13.

The Code also calls out “children 13 to 18” and says organizations should assess whether the child has sufficient capacity to understand what they are consenting to in the context of the specific data practice, particularly for sensitive personal information.

Age Assurance Systems: Don’t Turn Age Checks Into Tracking

If you use a third-party age assurance service provider, or build your own flow, the OPC’s age assurance developer guidance includes expectations that help prevent age checks from becoming a new data collection engine.

It states providers must not use personal information collected for age assurance for secondary purposes, nor disclose that information, with exceptions including disclosures based on a legal obligation, or certain limited processing if the individual is clearly informed and provides express consent. The same guidance also says to minimize, and not keep or disclose, information generated during the age assurance process (excepting the final result).

On the operator side, the OPC’s web-operator guidance says age assurance providers are not permitted to retain, disclose, or use information collected for age assurance for other purposes, and that the relying party receiving the age assurance result is also not permitted to do so. It gives an example prohibition: the relying party must not use that information as part of an advertising profile for the individual.

The developer guidance also discusses “double anonymity” as a privacy protection and says providers are not required to meet this requirement, but the OPC strongly encourages it to be built into systems. For business leaders choosing vendors, this becomes a procurement question, not only a technical one.

A Concrete, Marketing Led Audit Plan

For most SMBs, the fastest way to reduce risk is to audit by journey, not by policy section. Start with every path where youth are likely to show up, even if your brand does not consider itself “for kids,” then track what data gets collected, what tools receive it, and what the defaults are.

Map every youth-touching data flow. Identify family marketing landing pages, school program pages, teen signup flows, student portals or LMS areas, youth event registrations, and youth sports or lessons signups. For each journey, inventory the third-party scripts and tools that receive data, and verify whether defaults align with the Code’s “off by default” expectation for third-party sharing where a child is involved.
Rewrite consent UX around “non-essential data uses.” Implement “express, opt-in consent” for non-essential data uses, with separate choices for each optional feature or enhancement. Remove reliance on blanket terms of service consent for third-party sharing, because the Code states it would likely not satisfy the expectation.
Decide what you need for age assurance. Use the OPC operator guidance to assess whether age assurance is required and how to do it in a privacy-protective manner. Avoid treating an unenforced underage restriction statement as an actual control.
Turn off profiling on youth paths. Audit whether pixels, audiences, or tracking could be used to deliver targeted or behavioural advertising to children or to share profile data with third parties for advertising or marketing purposes. The Code’s position is direct, and it says profiling of children should be off by default.
Vendor due diligence for age assurance. Confirm providers avoid secondary use and disclosure of personal information collected for age assurance, and confirm your own business does not retain, reuse, or apply age assurance results to advertising profiling.

Process Note: There Is A Comment Window

The OPC news release states it is accepting comments on the Code until January 20, 2027, after which the document may be updated. For organizations with youth-touching services, that timeline sets a clear internal milestone: complete an audit and identify which changes you want to make, and which points you want to comment on, using the Code’s own language as your reference.

The Children’s Privacy Code turns children’s privacy from a policy document into a product and marketing systems check. Consent language, age checks, and third-party scripts all become part of the same operational question: what is “off by default,” what requires express opt-in, and what should not happen at all on youth paths.

If you want help mapping youth-touching journeys, cleaning up consent UX, and aligning marketing and sales workflows with human-guided automation, IN-STORE can support the build and ongoing execution as a monthly marketing partner.

Sources: