Your legal team just forwarded the latest California enforcement settlement. Your engineering lead is asking what an "SDK governance framework" actually entails. Your product manager wants to know if your age gate passes muster. These aren't abstract compliance questions, they're the conversations happening right now in Slack channels across companies with mobile apps or child-directed services.
The recent enforcement action against a mobile gaming company resulted in $500,000 in civil penalties and a detailed consent decree that reads like a compliance roadmap. Below are the questions we're hearing most often, with answers grounded in what the California Attorney General and Los Angeles City Attorney actually required.
What does "SDK governance framework" mean in practice?
It's not just a vendor checkbox. The settlement requires specific, documented activities:
- Inventory every SDK by name and provider in apps directed to children.
- Document the purpose for each SDK's presence.
- Evaluate configuration settings that control what personal information the SDK collects, uses, or discloses.
- Review contracts governing any SDK that touches children's personal information.
- Document sell/share compliance, meaning you've verified the SDK isn't selling or sharing data without Valid Consent.
- Conduct annual assessments of data minimization efforts and SDK governance, including testing actual data flows.
The settlement emphasizes that you're responsible for SDK behavior even when a third party wrote the code. If an SDK in your app sells data from a 12-year-old without parental consent, "we didn't configure it properly" isn't a defense the enforcers accepted.
Our terms say users must be 13+. Isn't that enough?
No. The settlement explicitly states that an age limit in your terms of use doesn't overcome actual knowledge that children under 13 use your service, nor does it change whether your app is directed to children under COPPA.
The enforcers summarized the app's child-directed nature by pointing to "visual content, use of animated characters and fun background music, as well as the simplistic nature of gameplay" that made it "simple and basic for consumers under the age of 13." If your service fits that description, you're subject to COPPA's parental consent requirements regardless of what your terms state.
The settlement also reminds companies that "willfully disregarding the consumer's age" means you're deemed to have actual knowledge. You can't turn a blind eye to obvious child usage.
What's wrong with our age gate if it starts at a default year?
If your age screen defaults to 1953, or any year that requires a child to scroll through decades to enter their real age, the enforcers view that as non-neutral and biased toward false adult identification.
For mixed-audience apps, the settlement clarifies additional requirements:
- Don't collect any personal information before collecting age information.
- Don't default to an age of 16 or above.
- Don't suggest that features will be unavailable for users who identify as younger than 16.
The goal is a neutral mechanism that doesn't nudge children toward misrepresenting their age. Consider a scrollable month/day/year picker that starts at the current date, or a simple text entry field with no pre-filled values.
What counts as "age-inappropriate advertising" in a kids' app?
The settlement flagged ads for a gambling app and a marijuana-growing game as inappropriate for child audiences. But the enforcers went further, identifying structural problems with how ads appeared:
- Unclear methods to exit ads.
- Blurred lines between advertising and gameplay.
- Forced downloading of unnecessary applications.
- Manipulative designs that cause children to "inadvertently or unknowingly engage with" ads or third-party apps.
Work with your ad operations team to ensure ads are clearly labeled, full-screen video ads have obvious exit controls, and display ads can be dismissed without forcing interaction or downloads. If your app is directed to children, you need content filters that block age-inappropriate creative, not just category exclusions.
Do we really need to list SDK categories in our privacy policy?
According to this settlement, yes, and with significant Granularity. Where personal information is sold or shared through SDKs, your privacy policy must provide "clear and conspicuous notice" including:
- Categories of SDKs in use.
- Categories of personal information sold or shared through SDKs.
- The business or commercial purpose for selling or sharing.
This is a higher bar than generic "we work with third-party service providers" language. If you're selling or sharing data via SDKs, name the SDK categories and explain what data flows through them.
The settlement also criticized the company's privacy policy for being "ambiguous and incomplete regarding the use of personal information for targeted and Behavioural Advertising," particularly in relation to children's data. If you engage in targeted advertising, your policy needs to disclose that clearly and explain the CCPA's opt-in regime for consumers under 16 (or parental consent for those under 13).
We fixed things after a self-regulatory review. Are we clear?
Not necessarily. This case began after the Children's Advertising Review Unit (CARU) published findings about the company's COPPA violations. The California Attorney General then opened its own investigation.
Critically, the enforcers noted that the company didn't identify or resolve its SDK misconfiguration even after receiving CARU's report. That failure to remediate strengthened the state's case and may have provided additional claims under California's Unfair Competition Law.
If you've committed to changes following any investigation, whether from a self-regulatory body or a state attorney general, document your remediation and verify it's actually implemented. Promised changes that don't materialize can become separate violations.
Does this settlement apply beyond California?
The legal claims were brought under COPPA (federal), CCPA (California), and California's Unfair Competition Law. But COPPA applies nationwide to operators of child-directed services, so the SDK governance and parental consent requirements affect any company subject to COPPA, regardless of location.
The settlement's emphasis on neutral age gates, SDK documentation, and privacy policy Granularity reflects broader regulatory expectations. Even if you're not subject to CCPA, these requirements offer a window into what enforcers consider reasonable data protection practices for children's services.
Where to go for more
Review the COPPA Rule at 16 C.F.R. § 312 for the foundational requirements on parental consent and data collection from children under 13. The FTC's COPPA FAQs provide practical guidance on mixed-audience determination and verifiable parental consent mechanisms.
For CCPA compliance, focus on Civil Code §§ 1798.100-1798.199, particularly § 1798.120 (right to opt out of sale/sharing) and § 1798.135 (opt-in for minors). The California Attorney General's enforcement regulations at 11 CCR § 7000 et seq. add implementation detail.
If your app uses SDKs for advertising or analytics, audit your data flows now. The settlement makes clear that "we didn't know what the SDK was doing" isn't a viable defense when regulators come asking.
