Privacy, Terms and Compliance

Privacy is not a document you generate at the end. It's a set of promises your product must actually keep, and the fastest way to break one is to add a feature or an SDK that collects data your policy doesn't mention. Your privacy label is a public promise, enforced by app stores and, increasingly, by law.

This chapter describes obligations and categories. It is not legal advice. Compliance depends on your jurisdiction, your data, and your users. Use this to know what applies and what to ask; take specifics to a lawyer or a compliance tool.

The concept

Two documents and a growing pile of regulation:

 PRIVACY POLICY    what data you collect, why, who you share it with, how to delete it
 TERMS OF SERVICE  the rules of using your product; liability; disputes
 COMPLIANCE        the laws that apply to your data and your users

The unifying principle: your documents must describe what your product actually does. A privacy policy that doesn't match your behaviour is worse than none, it's a false promise, a store rejection, and in many places a legal violation.

Privacy policy: required, and everywhere

A privacy policy is mandatory if you collect any personal data (which almost every product does, an email is personal data). App stores require a Privacy Policy URL; most jurisdictions require the document itself.

It must honestly state: what you collect, why, who you share it with (every third-party SDK counts), how long you keep it, how users delete it, and how to contact you.

⭐ Your privacy label is a promise a dependency can break

App stores make you declare your data collection as a "nutrition label." The trap:

An SDK you add, even one you don't actively use, can collect data and change what you must declare.

Analytics, ads, social-login, and attribution SDKs frequently collect device identifiers and usage data by default. Adding one changes your privacy label whether or not you call it. Audit what actually ships in your binary, not just what you call (Chapters 21, 22), and keep the label in sync with reality.

📐 A privacy label is not a launch-day form; it's a promise that must track every data-collecting change. The policy must match the label must match the behaviour, all three in agreement, re-checked whenever you add a feature or an SDK. A policy that lags the product is a false promise, even when the lag is honest.

And the label must match the policy must match the behaviour. All three, in agreement.

The major regulations, at a glance

You don't need to be an expert; you need to know which apply and get help:

Two practical rules: if you have any EU users, assume GDPR applies. If your product could attract anyone under 13, COPPA is a hard line with severe penalties, either build for it properly or design to exclude minors.

Data-handling that keeps the promises

• Collect the minimum. Data you don't hold can't leak, can't be subpoenaed, and doesn't need protecting.
• Privacy by default. Sensitive features (a journal, location, contacts) should be private or off unless the user opts in.
• Deletion must actually delete. "Delete my account" has to remove the data, cascading through your database and any third parties (Chapter 21). App stores require in-app deletion once you have accounts.
• Encrypt in transit (HTTPS everywhere) and sensitive data at rest.
• Have a breach plan. GDPR requires notification within 72 hours; you can't write the plan during the breach.

Terms of Service

Less regulated, still important. Covers acceptable use, your liability limits, intellectual property, termination, dispute resolution, and governing law. Don't copy a template you don't understand, a ToS that promises things you can't deliver (uptime guarantees, refund terms a platform controls) is a liability, not a shield.

Consent and cookies

If you use non-essential analytics or tracking and have EU users, you likely need a consent mechanism before collecting. The cleanest escape is privacy-preserving, cookieless analytics (Chapter 38) that don't require a banner at all.

📐 Best practice

Make the policy, the label, and the behaviour all agree.

Audit what your binary collects, including SDKs, and keep the label current.

Collect the minimum data you need.

Privacy by default for sensitive features.

Build real deletion, cascading, and verified by confirming the data is gone.

Update the policy and label when you add any data-collecting feature or SDK, in the same change.

Assume GDPR if you have any EU users.

Treat COPPA as a hard line. Build for it or exclude minors.

Prefer cookieless analytics to avoid consent complexity.

Have a breach-response plan before you need it.

Use a reputable generator or a lawyer, not a random template.

💀 Common mistakes

⭐ A policy that doesn't match behaviour. A false promise, a rejection, a violation.

A dependency silently changing your privacy label.

"Delete my account" that doesn't delete. Store rejection and a broken promise.

Ignoring GDPR because you're not in the EU. It applies to your users' location.

Attracting under-13s without COPPA compliance. Severe penalties.

Collecting data "in case it's useful." Liability with no benefit.

Copy-pasted ToS promising things you can't deliver.

Non-essential tracking with no consent for EU users.

No breach plan. You can't write it in 72 hours mid-incident.

Sensitive data (health, payment, children's) sent to a third party without checking obligations.

Sending regulated data to an AI provider without checking retention/training terms (Chapter 23).

The professional workflow

 1. INVENTORY YOUR DATA
    what you collect · why · where it goes (every SDK) · how long you keep it

 2. MINIMISE — drop anything you don't need

 3. WRITE/GENERATE THE PRIVACY POLICY to match the inventory

 4. FILL THE PRIVACY LABEL to match the policy and the binary

 5. PRIVACY BY DEFAULT for sensitive features

 6. BUILD DELETION — cascading, verified to actually delete

 7. WRITE/REVIEW TERMS OF SERVICE for your real product

 8. IDENTIFY APPLICABLE LAW
    EU users → GDPR · CA → CCPA · under-13 → COPPA · get help where unsure

 9. CONSENT if non-essential tracking + EU users (or go cookieless)

10. BREACH PLAN written and stored

11. RE-SYNC all three (policy, label, behaviour) on EVERY data change

Tools, websites & costs

A compliant privacy setup for a small consumer product is $0-20/month. Enterprise compliance (SOC 2) is a later, sales-driven cost.

Alternatives & trade-offs

Generator vs lawyer. A reputable generator handles the standard consumer case cheaply and produces a document that matches a questionnaire, which is only as good as your honest answers. A lawyer is worth it for anything non-standard: health data, children, B2B DPAs, unusual data flows.

Minimal vs comprehensive collection. Collecting less limits your product insight and your liability. Collecting more powers personalisation and analytics at a compliance and risk cost. Default to minimal; add with a clear purpose and disclosure.

Consent banner vs cookieless. A banner lets you use richer (tracking) analytics at the cost of friction and a compliance surface. Cookieless avoids the banner and gives you less. For most early products, cookieless is enough.

In-house compliance vs automation platform. Platforms (Vanta, Drata) accelerate SOC 2 and continuous compliance at real cost; in-house is cheaper and slower. Only relevant once enterprise customers demand certifications.

Checklist

• I have a data inventory, what, why, where (every SDK), how long
• I collect the minimum needed
• The privacy policy matches the inventory
• The privacy label matches the policy and the binary
• Sensitive features are private by default
• Deletion cascades and is verified to actually delete
• Policy and label are updated whenever data collection changes
• I know which regulations apply (GDPR / CCPA / COPPA)
• Consent handled for EU non-essential tracking (or I'm cookieless)
• A breach plan exists
• No regulated data sent to third parties without checking obligations
• Non-standard cases reviewed by a lawyer

📓 Case Study: a policy that had to keep up with the product

Project: SOLIS. This is the one Part-VIII topic the project genuinely exercised, because privacy obligations arrived automatically as capabilities were added.

Privacy by default was designed in, correctly. The evening journal, the most sensitive data in the app, was on-device only unless the user explicitly opted into sync. The backend plan recorded it as a deliberate principle: "journal syncs only when the user opts in (private-by-default preserved)." Sensitive features off unless chosen is exactly the right default (Chapter 14).

Account deletion was built and verified to a good standard. The store requires in-app deletion once you have accounts (Guideline 5.1.1(v)). A server function verified the caller, deleted the auth user, and cascaded to all data via database constraints. And the verification was the right kind, fresh account created → deleted in-app → database back to zero users, zero rows. Confirming the data is gone, not that the button worked (Chapter 21).

⭐ The privacy label had to track the product, and a dependency nearly broke it. Two moments illustrate the core lesson of this chapter.

First, the label started honest and became wrong: the initial local-only build correctly declared "Data Not Collected." Then the backend landed, collecting account email, progress, opt-in journal, and a device token, and the note was explicit:

The app now collects account email/name, progress, opt-in journal, and (later) a device token. Revise the privacy policy and the App Privacy label answers to match. Launch/review requirement.

The policy and label had to be re-synced with the new behaviour. A privacy label is not a launch-day form; it's a promise that has to track every data-collecting change.

Second, a dependency almost changed the label silently. The social-login plugin ships a third-party tracking SDK by default. It was explicitly disabled in configuration:

keeps the [tracking] SDK out of the binary, it ships by default and would have forced a much heavier privacy label.

That's the exact trap this chapter warns about: an SDK you don't actively use still collects data and still changes what you must declare. Catching it required auditing what shipped in the binary, not just what the code called.

⚠️ Deviation: the privacy-policy and label update was an open item at the end. The recognition was correct and early; the execution was deferred. Both the revised policy copy and the updated label answers were still on the launch-blocker list at the last entry, meaning the live document did not yet match the product's actual data collection. A privacy policy that lags the product is a false promise, even when the lag is honest and tracked.

🚩 Untested where it matters most. GDPR/CCPA obligations were never exercised because there were no users, and the deletion Edge Function, while verified against a fresh test account, was never run against real user data at any volume.

Lessons

1. Your documents must describe what your product actually does. Policy, label, and behaviour must all agree.
2. ⭐ A dependency can silently change your privacy label. Audit the binary, not just your code.
3. The privacy label tracks every data change, it's a promise, not a launch-day form.
4. Privacy by default for sensitive features. Off unless chosen.
5. Deletion must actually delete, cascading, verified by confirming the data is gone.
6. Update policy and label in the same change that adds data collection.
7. GDPR applies to your users' location, not yours.
8. COPPA is a hard line. Build for it or exclude minors.
9. Prefer cookieless analytics to sidestep consent complexity.
10. Collect the minimum. Data you don't hold can't leak.
11. Recognising an obligation isn't meeting it. A tracked-but-open privacy update is still a live false promise.

Next: Chapter 41: Taxes and Financial Admin →