Checklist · Technology

Drafting a Privacy Policy: A Practical Checklist

15 U.S.C. § 45

Type
Checklist
Jurisdiction
National
Date
2023-12-11
Topic
Technology

A privacy policy is not marketing copy — it is a legally enforceable promise that the FTC and state attorneys general will hold you to word for word. This checklist walks through drafting a lawful, non-deceptive privacy policy from scratch: the FTC Act Section 5 rule that you must actually do what you say, the overlapping mandates of CalOPPA, CCPA/CPRA, GDPR, and COPPA, and the specific disclosures each requires. It covers the categories of data collected, sources and purposes, sharing and the regulated concept of "sale/sharing," retention and security, consumer and data-subject rights and how to exercise them, cookies and tracking technologies, children's data, and international transfers after Schrems II. Each phase carries a "why it matters" explanation, worked examples built around a fictional SaaS company, and the traps that turn a boilerplate policy into an enforcement exhibit. It closes with a consolidated one-glance checklist, versioning and change-notice mechanics, and the primary authorities you should keep at hand.

Drafting a Privacy Policy: A Practical Checklist

Technology > Privacy | Published 11 December 2023 - Updated 20 March 2025 | UpLaw - uplaw.us

A privacy policy is the one legal document your users are most likely to read and your regulators are certain to. Treat every sentence as a promise you can be sued for breaking — because that is exactly what it is.

Keywords: privacy policy, CCPA/CPRA, CalOPPA, GDPR, COPPA, FTC Act Section 5, sale and sharing, consumer rights, cookies and tracking, retention, international transfers, Schrems II, children's privacy, do not sell

How to use this checklist

A privacy policy looks like the easiest document a company will ever publish — copy a template, swap in the company name, paste it at the footer. That instinct is precisely what turns a routine disclosure into a Federal Trade Commission consent decree. The policy is a public, binding representation about how you handle personal information, and three different regimes converge on it: the FTC Act, which treats a false or incomplete policy as a deceptive act; a patchwork of state privacy statutes that dictate what the policy must contain; and the EU's GDPR, which reaches any business handling European residents' data. The goal of this checklist is to help you draft a policy that is simultaneously accurate, complete, and readable — and to keep your operational reality in lockstep with the words on the page.

Work the phases in order. Each ends with a Why it matters, and the traps note. We follow one fictional company throughout: Meadowlark Analytics, a Delaware SaaS startup selling a customer-support dashboard, drafting its first privacy policy as it prepares to sell to mid-market clients and collect data from web visitors, trial users, and paying customers.

Before you draft a single clause, build the factual record the policy will describe. A privacy policy is downstream of a data map; if you do not know what you collect and where it flows, you cannot describe it honestly. For that groundwork, start with Building a Privacy Compliance Program: Governance, Data Mapping, and the Legal Patchwork and the companion Standing Up a Privacy Compliance Program: A Practical Checklist.

Phase 1 — Internalize the core rule: the policy is an enforceable promise

  • [ ] Confirm every factual statement in the draft is literally true of your current operations (not aspirational).
  • [ ] Reconcile the policy against your actual data map, vendor list, and cookie inventory before publishing.
  • [ ] Assign an owner responsible for updating the policy whenever a data practice changes.
  • [ ] Avoid absolute or emphatic promises you cannot guarantee ("we never share your data," "military-grade security," "we will never sell your information") unless they are unconditionally true.
  • [ ] Keep an internal record (a "receipts file") showing the factual basis for each material claim.

Why it matters, and the traps. Section 5 of the FTC Act, 15 U.S.C. § 45, prohibits "unfair or deceptive acts or practices in or affecting commerce." The FTC's entire consumer-privacy enforcement program rests on a simple theory: if your privacy policy says one thing and you do another, that gap is a deception. The agency does not need a privacy statute to be violated — the misrepresentation itself is the violation. This is how the FTC reached companies long before any comprehensive federal privacy law existed, in matters running from In re Snapchat (messages that did not actually disappear) to In re Facebook and the settlements over sharing data with third parties that the policy said would not receive it.

The trap is aspiration. Founders love to promise more than the engineering allows. "We never sell your data" is a landmine if a court or regulator later characterizes an ad-tech arrangement as a "sale." "We use bank-level encryption" is deceptive if half your S3 buckets are unencrypted. Write the policy to describe what you do, in language you can defend with a document. If Meadowlark's marketing team wants to say "your data is 100% secure," legal should strike it — no system is, and the FTC has repeatedly treated overbroad security claims as deceptive. The safest posture: promise process, not perfection.

Phase 2 — Map which laws force a policy and what each demands

  • [ ] Determine whether you collect personal data from California residents (CalOPPA and CCPA/CPRA triggers).
  • [ ] Run the CCPA/CPRA applicability test (for-profit; does business in California; and meets a revenue, volume, or data-sale threshold).
  • [ ] Determine whether you offer goods/services to, or monitor, individuals in the EU/UK/EEA (GDPR/UK GDPR).
  • [ ] Determine whether your service is directed to children under 13 or you have actual knowledge of child users (COPPA).
  • [ ] Screen for sector overlays: health data (HIPAA), financial data (GLBA), biometric data (state biometric laws), and the growing list of state "consumer privacy" statutes (Virginia, Colorado, Connecticut, Texas, and others).
  • [ ] Build a single combined requirements list so one policy satisfies every applicable regime.

Why it matters, and the traps. No single statute says "publish a privacy policy that contains the following." The obligation is assembled from several sources:

  • CalOPPA — California's Online Privacy Protection Act, Cal. Bus. & Prof. Code § 22575 — is the oldest and broadest trigger. Any operator of a commercial website or online service that collects personally identifiable information about California consumers must conspicuously post a privacy policy and must, among other things, describe the categories of PII collected, disclose how it responds to Do Not Track signals, and identify the process for consumers to review and request changes. Because virtually every U.S. website has California visitors, CalOPPA is why "everyone needs a privacy policy" is essentially true.

  • CCPA, as amended by the CPRA — Cal. Civ. Code § 1798.100 et seq. — layers on far more detailed content requirements for covered businesses: the categories of personal information collected, sources, business/commercial purposes, categories disclosed or "sold" or "shared," retention periods, and a full menu of consumer rights with instructions for exercising them.

  • GDPR arts. 13-14, Regulation (EU) 2016/679, prescribe an exhaustive "information to be provided" list for any controller processing EU personal data — identity of the controller, purposes and legal basis, recipients, transfer mechanisms, retention, and data-subject rights.

  • COPPA, 15 U.S.C. § 6501 et seq., adds a separate, stricter regime for operators of child-directed services.

The trap is treating these as alternatives. They are cumulative. A single SaaS company can be subject to all of them at once, and the correct approach is one integrated policy whose content is the union of every applicable requirement, not a patchwork of regional pages. For the multi-jurisdiction lay of the land, see Mobile App Privacy Law: A Compliance Map for Founders and Counsel and, for a broader operating framework, The Privacy and Data Protection Toolkit: Building and Operating a Compliance Program.

Worked example. Meadowlark is a for-profit company that "does business in California" (it has paying California customers and a sales rep in San Francisco). It collects data from more than 100,000 California consumers and households across its free-trial funnel — clearing the CPRA volume threshold. It also markets to EU companies, so GDPR applies to the personal data of their European staff. It is not child-directed, so COPPA is off the table absent actual knowledge of under-13 users. Its combined requirements list is therefore CalOPPA + CCPA/CPRA + GDPR — one policy, engineered to satisfy all three.

Phase 3 — Draft the required disclosures: what you collect, from where, why, and to whom

  • [ ] List every category of personal information you collect (identifiers, commercial information, internet activity, geolocation, professional/employment information, inferences, and any "sensitive personal information" under CPRA).
  • [ ] Disclose the sources of each category (directly from the consumer, automatically via the service, from third parties/data brokers, from public records).
  • [ ] State the business and commercial purposes for each category in specific, non-vague terms.
  • [ ] Identify the categories of third parties with whom you disclose, and specify whether disclosure is for a business purpose (service providers) or constitutes a "sale" or "sharing."
  • [ ] Under GDPR, state the legal basis for each processing purpose (consent, contract, legitimate interests, legal obligation) and, if relying on legitimate interests, identify them.
  • [ ] Include a clear "Do Not Sell or Share My Personal Information" mechanism and describe how to use it, if any sale or sharing occurs.

Why it matters, and the traps. This is the substantive heart of the policy, and it is where vague drafting does the most damage. The CPRA does not accept "we collect information to improve our services" as a purpose statement — regulators expect specificity tied to enumerated statutory categories. "Sensitive personal information" (precise geolocation, government IDs, account credentials, contents of communications, and more) carries its own disclosure and opt-out consequences under CPRA and should be broken out separately.

The most consequential and misunderstood term is "sale/sharing." Under the CPRA, a "sale" is any disclosure of personal information to a third party for "monetary or other valuable consideration," and "sharing" specifically captures disclosures for cross-context behavioral advertising — even when no money changes hands. This is the trap that has snared countless companies: dropping a Meta pixel or a Google Ads tag on your site is very likely "sharing," which triggers an obligation to offer an opt-out and to honor the Global Privacy Control browser signal. A policy that flatly declares "we do not sell your data" while the site pipes visitor identifiers to ad networks is both non-compliant and an FTC-style deception.

Worked example. Meadowlark's first draft says: "We collect your information to run our business and do not sell it." That single sentence fails three ways. It does not enumerate categories or sources; it omits the advertising cookies the growth team added last quarter; and its "do not sell" claim is false because those cookies "share" identifiers for retargeting. The corrected draft breaks collection into a table — identifiers (name, email, IP) from account signup; internet activity (pages viewed, feature usage) collected automatically; commercial information (subscription tier, billing) from the customer; inferences (predicted churn risk) generated internally — each row paired with a purpose and the categories of recipients. It then adds a "Do Not Sell or Share My Personal Information" link that suppresses the advertising tags and honors GPC. Because Meadowlark also emails prospects, it cross-checks its outbound practices against CAN-SPAM Compliance for Commercial Email: A Practical Checklist.

Phase 4 — Disclose retention, security, and the consumer/data-subject rights

  • [ ] State a retention period for each category of personal information, or the criteria used to determine it (required by CPRA and GDPR).
  • [ ] Describe your security posture in defensible, non-absolute terms ("reasonable administrative, technical, and physical safeguards").
  • [ ] Enumerate the consumer rights you must honor: know/access, delete, correct, opt out of sale/sharing, limit use of sensitive PI (CCPA/CPRA); and access, rectification, erasure, restriction, portability, and objection (GDPR).
  • [ ] Provide at least two designated methods for submitting requests (e.g., a toll-free number and a web form, or two electronic methods for online-only businesses).
  • [ ] Explain your identity-verification process and expected response timelines (generally 45 days under CCPA, extendable; one month under GDPR).
  • [ ] State your anti-retaliation / non-discrimination commitment for consumers who exercise rights.
  • [ ] Identify how to appeal a denied request (required by several newer state statutes) and how to lodge a complaint with a supervisory authority (GDPR).

Why it matters, and the traps. Retention is the sleeper obligation. CPRA and GDPR both require you to tell people how long you keep their data, and both embody a storage-limitation principle: you may not keep personal data indefinitely "just in case." Publishing a retention schedule you do not actually follow is its own deception, so the policy must match a real internal retention program. For the doctrine and mechanics behind those schedules, see Data Minimization and Storage Limitation: Curbing the Over-Retention of Personal Data.

The rights section is where policies most often collapse in practice. It is easy to list rights; it is hard to operate them. If your policy promises deletion within 45 days but your engineering team has no way to find and purge a user across systems, you have manufactured a broken promise. Draft the rights section only after you know you can fulfill each request — and stand up the intake and verification workflow described in Responding to a Data Subject Access Request: A Practical Checklist.

On security language, resist superlatives. "Reasonable safeguards appropriate to the sensitivity of the data" is defensible; "unbreakable," "hack-proof," or "military-grade" invites an FTC deception theory the moment there is a breach. The CPRA also creates a private right of action for breaches caused by a failure to maintain reasonable security — another reason the security paragraph should promise a standard of care, not a guarantee of outcomes.

Worked example. Meadowlark commits to deleting trial-account data 18 months after the last login and billing records seven years for tax compliance. It offers a web form and a dedicated privacy email as its two request channels, verifies identity by confirming control of the account email plus a recent invoice number for higher-risk requests, and pledges a 45-day response. Crucially, it builds the deletion runbook before the policy goes live, so the promise is operational on day one.

Phase 5 — Cookies, pixels, SDKs, and tracking-technology disclosures and consent

  • [ ] Inventory every tracking technology on your properties: first-party and third-party cookies, pixels/web beacons, mobile SDKs, session-replay tools, and fingerprinting scripts.
  • [ ] Categorize each as strictly necessary, functional, analytics, or advertising/targeting.
  • [ ] Disclose the technologies, their purposes, and the third parties they feed in the policy (or a linked cookie notice).
  • [ ] Address Do Not Track signals — CalOPPA requires you to state how you respond to them.
  • [ ] Honor the Global Privacy Control opt-out preference signal for sale/sharing under CPRA.
  • [ ] For EU/UK users, deploy a consent banner that obtains prior, affirmative, granular consent before non-essential cookies fire (ePrivacy Directive + GDPR consent standard).
  • [ ] Ensure the consent tool actually blocks tags until consent is given — not merely records a click after the fact.

Why it matters, and the traps. Tracking technologies are where the "sale/sharing" analysis becomes concrete and where U.S. and EU rules diverge sharply. In the U.S., the CPRA model is opt-out: you may run advertising tags but must offer a way to stop them and must honor GPC. In the EU, the model is opt-in: non-essential cookies may not fire at all until the user affirmatively consents, and pre-checked boxes or "by using this site you agree" banners do not count. A single global banner that assumes consent will violate EU law; a U.S.-only "we don't use cookies" statement will be false the moment analytics load.

The sharpest current trap is session-replay and pixel litigation. Plaintiffs have repurposed decades-old wiretap and "pen register" statutes — the California Invasion of Privacy Act chief among them — to attack websites that deploy chat widgets, session-replay scripts, and the Meta pixel without adequate disclosure and consent. The privacy policy is your first line of defense: it must actually disclose these tools. And when the tracking technologies read faces, voices, or other biometric identifiers, a separate and stricter consent regime applies — see Biometric Privacy Law and the AI Systems That Read Faces and Voices.

Worked example. Meadowlark's site loads Google Analytics, a HubSpot chat widget, and a Meta retargeting pixel. Its cookie table lists all three with purposes and links to each vendor's policy. For EU visitors, a geo-targeted banner blocks the analytics and Meta tags until the visitor clicks "Accept"; for U.S. visitors, the same tags load but a persistent "Your Privacy Choices" link and GPC honoring let anyone opt out of the advertising "share."

Phase 6 — Children's data and the COPPA overlay

  • [ ] Determine whether your service is "directed to children" under 13 or whether you have actual knowledge of child users.
  • [ ] If COPPA applies, publish a separate, prominent children's privacy notice describing what you collect from children and how it is used and disclosed.
  • [ ] Implement verifiable parental consent before collecting personal information from a child.
  • [ ] Provide parents the right to review, delete, and refuse further collection of their child's data.
  • [ ] Apply data minimization — collect only what is reasonably necessary for the activity.
  • [ ] If you are not child-directed, state that the service is not intended for children under 13 and that you do not knowingly collect their data — and mean it.
  • [ ] Consider teen protections under CPRA (opt-in consent to sell/share data of consumers under 16) and newer state age-appropriate design rules.

Why it matters, and the traps. COPPA, 15 U.S.C. § 6501 et seq., and its implementing Rule impose the strictest consent regime in U.S. privacy law, and the FTC enforces it with real penalties (the YouTube settlement alone was $170 million). The trap for a general-audience SaaS company is the "actual knowledge" prong: even if your service is not designed for kids, learning that children are using it can pull you into COPPA. Most B2B products handle this by stating clearly that the service is not directed to children and by not knowingly collecting their data — but that statement must be honest, and you cannot bury an obvious child-user population.

Worked example. Meadowlark's dashboard is sold to businesses and has no plausible child audience, so it includes a one-line "Children's Privacy" section stating the service is not intended for anyone under 16, that it does not knowingly collect their data, and that it will delete such data on discovery. Because that is true, the clause protects rather than exposes it.

Phase 7 — International transfers and the Schrems II disclosures

  • [ ] Identify every cross-border data flow (e.g., EU customer data processed on U.S.-based servers or by U.S. sub-processors).
  • [ ] Disclose in the policy that personal data may be transferred to and processed in other countries, including the United States.
  • [ ] Identify the transfer mechanism relied upon: the EU-U.S. Data Privacy Framework (for certified U.S. importers), Standard Contractual Clauses, or another valid basis.
  • [ ] Reference the supplementary measures / transfer impact assessment you conducted post-Schrems II where SCCs are the basis.
  • [ ] Offer to make transfer safeguards available on request (a common GDPR-notice practice).
  • [ ] Keep the mechanism current — the legal ground for EU-to-U.S. transfers has changed repeatedly.

Why it matters, and the traps. When the Court of Justice of the European Union invalidated the Privacy Shield in Data Protection Commissioner v. Facebook Ireland and Schrems ("Schrems II"), it did not just kill one mechanism — it held that exporters relying on SCCs must assess whether the destination country's surveillance laws undermine the clauses' protections and, if so, add supplementary measures. GDPR arts. 13-14 require you to tell data subjects that transfers occur and on what basis. The trap is a stale or hand-waving transfer clause: pointing to "Privacy Shield" (dead since 2020) or naming SCCs without having actually executed them and run a transfer impact assessment. For the full mechanics of getting data out of the EU lawfully, see Moving Personal Data Out of the EU After Schrems II: SCCs and Transfer Impact Assessments.

Worked example. Meadowlark hosts EU customer data on U.S. AWS regions and uses a U.S. email-delivery vendor. Its policy discloses the transfer, states that it relies on the EU-U.S. Data Privacy Framework where its importers are certified and on SCCs otherwise, notes that it performed transfer impact assessments, and offers to provide the safeguards on request.

Phase 8 — Draft for readability, then version and give change-notice

  • [ ] Write in plain language at a reasonable reading level; avoid legalese that obscures required disclosures.
  • [ ] Use headings, a summary/table-of-contents, and layered notices so users can find key points quickly.
  • [ ] Include an effective date and a "Last updated" date.
  • [ ] Maintain a version archive of prior policies.
  • [ ] Define how you will give notice of material changes (email, in-product banner, or prominent site notice) and, where required, obtain fresh consent.
  • [ ] Do not apply materially different practices to previously collected data retroactively without appropriate notice or consent.
  • [ ] Localize where required (e.g., a distinct "California Privacy Rights" or "EEA/UK" addendum) while keeping a single coherent document.

Why it matters, and the traps. Readability is not a nicety — it is a legal requirement in disguise. A disclosure buried in dense boilerplate can be deemed not "conspicuous" under CalOPPA and not "transparent" under GDPR art. 12. Versioning matters because the FTC's Gateway Learning case established the enduring principle that you cannot quietly change your policy and apply the new, looser terms to data you already collected under the old promise; a material, retroactive change requires notice and, often, opt-in consent. Keep dated archives so you can prove which promise governed which data.

Worked example. When Meadowlark later adds an AI feature that trains models on customer content, that is a material change. It emails all customers 30 days in advance, posts an in-app banner, updates the "Last updated" date, archives the prior version, and — because training on customer data is a new purpose — obtains opt-in consent rather than assuming silence is agreement.

Common Mistakes to Avoid

  • Copying a competitor's policy. Their data practices are not yours; their promises become your deceptions. A borrowed policy that describes collection you do not do, or omits collection you do do, is worse than none.
  • "We do not sell your data" while running ad-tech. Under CPRA, pixels and ad tags almost always constitute "sharing," and often "sale." Match the words to the tags.
  • Promising perfect security. Absolute security claims are deceptive by definition and become Exhibit A after a breach.
  • Listing rights you cannot operationalize. A deletion or access right you cannot actually execute is a broken promise waiting for a complaint.
  • Ignoring retention. Both CPRA and GDPR require retention disclosures; "we keep data as long as necessary" without criteria is increasingly inadequate.
  • A single global cookie banner. Opt-in for the EU and opt-out for the U.S. are different regimes; one banner rarely satisfies both.
  • Silent material changes. Retroactively applying new practices to old data without notice violates the Gateway Learning principle and Section 5.
  • Forgetting the "actual knowledge" COPPA trap. A general-audience service that learns it has under-13 users cannot ignore COPPA.
  • Treating the policy as static. It must be revisited whenever a vendor, tracker, data category, or purpose changes.
  • Health, financial, or biometric blind spots. If you touch protected health information, the policy sits atop HIPAA obligations — see HIPAA in the Cloud: Business Associates, BAAs, and Protecting ePHI.

Consolidated one-glance checklist

Foundation

  • [ ] Policy is literally true of current practices; backed by a data map and cookie inventory.
  • [ ] An owner is assigned to keep it current.

Scope

  • [ ] CalOPPA, CCPA/CPRA, GDPR, COPPA, and sector overlays screened; combined requirements list built.

Required disclosures

  • [ ] Categories of personal information collected (including sensitive PI).
  • [ ] Sources of each category.
  • [ ] Business/commercial purposes, stated specifically.
  • [ ] Categories of third-party recipients; sale/sharing identified; opt-out link and GPC honored.
  • [ ] GDPR legal basis stated for each purpose.

Retention, security, rights

  • [ ] Retention periods or criteria disclosed and operational.
  • [ ] Reasonable-security language (no absolutes).
  • [ ] Full rights menu with two request channels, verification, timelines, non-discrimination, and appeal path.

Tracking

  • [ ] Cookies/pixels/SDKs inventoried and disclosed; Do Not Track response stated.
  • [ ] EU consent banner blocks non-essential tags until opt-in; U.S. opt-out available.

Children & transfers

  • [ ] COPPA notice and verifiable parental consent (if child-directed) or honest not-for-children statement.
  • [ ] International transfers disclosed with a valid, current mechanism (DPF/SCCs) and TIA.

Governance

  • [ ] Plain-language drafting; effective and "last updated" dates; version archive.
  • [ ] Material-change notice process defined; no silent retroactive changes.

For the surrounding launch obligations a new site must satisfy alongside its privacy policy, run Launching a Website: A Legal Compliance Checklist, and for the full internet-law map see The Website and Internet Law Toolkit.

Primary Authority

  • FTC Act § 5, 15 U.S.C. § 45 — prohibits unfair or deceptive acts or practices; the basis for treating a false or incomplete privacy policy as a deception.
  • California Online Privacy Protection Act (CalOPPA), Cal. Bus. & Prof. Code § 22575 et seq. — requires a conspicuously posted privacy policy, disclosure of PII categories, and a stated response to Do Not Track signals.
  • California Consumer Privacy Act / CPRA, Cal. Civ. Code § 1798.100 et seq. — detailed content requirements, sale/sharing rules, consumer rights, retention disclosures, and the sensitive-PI framework.
  • GDPR arts. 12-14, Regulation (EU) 2016/679 — transparency principle and the exhaustive list of information a controller must provide, including legal basis, recipients, retention, transfers, and data-subject rights.
  • Children's Online Privacy Protection Act (COPPA), 15 U.S.C. § 6501 et seq., and the FTC's COPPA Rule — verifiable parental consent and children's-notice requirements.
  • ePrivacy Directive 2002/58/EC (as amended) — the EU consent-before-cookies requirement for non-essential trackers.
  • Data Protection Commissioner v. Facebook Ireland Ltd. and Maximillian Schrems (Schrems II), CJEU (2020) — invalidated Privacy Shield and imposed transfer-impact obligations on SCC reliance.
  • FTC enforcement precedent — In re Gateway Learning Corp. (no silent retroactive policy changes); In re Snapchat, Inc.; United States v. YouTube/Google (COPPA). Cited for the principles stated; consult the FTC's published orders for exact terms.

Related UpLaw Resources

Related Guides & Articles

Related Checklists

Related Toolkits

This checklist is general legal information from UpLaw (uplaw.us), not legal advice, and does not create an attorney-client relationship. Privacy statutes, regulations, and enforcement priorities change frequently and vary by jurisdiction; verify current requirements and consult qualified counsel before publishing or relying on a privacy policy.