Summary. This checklist turns the law of privacy disclosures into concrete tasks for anyone who drafts, approves, audits, or challenges a privacy policy. It starts with scope and fact-gathering, because a policy can only be checked against the data map, the vendor contracts, a network capture, the retention schedule, and every other public statement the company has made about data. It then works through architecture and placement, collection, use, disclosure and sale, cookies and opt-out signals, consent flows and dark patterns, sensitive and children's data, retention and security, and consumer rights, followed by the California, multistate, and GDPR sections and the sector notices and statutory consents that must live in their own instruments. Later parts cover a line-by-line review of the words that create liability, the policy as a contract, change management and the retroactive-change rule, version control and evidence, and the annual accuracy audit. A reverse-use part shows how plaintiffs, regulators, and acquirers run the same checks, and the checklist closes with common mistakes, an FAQ, and practical takeaways. Each item carries a short note and the governing authority so a reviewer can trace it to its source.

Most privacy policies that end up quoted in an FTC complaint were true on the day they were posted. Then marketing added a pixel, product shipped a feature, someone decided the old data would make a good training set, and the document kept making the same promises about a company that no longer existed. Reading the policy will not find that problem. Comparing every sentence in it to the system it describes will, and that is what this checklist does.

The short answer

  • Review the policy against facts, not against other policies. If you cannot point to the data map entry, vendor contract, network capture, or deletion job that proves a sentence, the sentence is not ready to publish.
  • Statutes dictate the contents; the FTC Act polices the truth. CalOPPA, the CCPA and its regulations, the other state privacy laws, COPPA, GLBA, HIPAA, and the GDPR decide what must be said. Section 5 of the FTC Act, 15 U.S.C. § 45, treats every statement in the document as a representation, and a misleading one as deception.
  • The expensive mistakes are predictable. "We do not sell your data" next to advertising pixels; a consent banner that gates nothing; absolute promises about security, anonymity, or deletion; silence about a use customers would not expect, including AI training; and a material change applied to data collected under the old promise.
  • The review is not over when the policy goes live. Version control, an archive with screenshots, consent records, and an annual accuracy audit are what let you prove later what the policy said and that it was true.

How to use this checklist

  • Who uses it. The drafter (in-house counsel, outside counsel, or the privacy lead), the engineers and marketers who run the systems the policy describes, and the person who approves publication. Plaintiffs' lawyers, regulators, and acquirers can run the same items in reverse; Part 19 shows how.
  • When. Before publishing a new policy, at least every 12 months (California requires the policy to be updated at least that often under Cal. Civ. Code § 1798.130(a)(5)), and whenever a trigger listed in Part 18 occurs.
  • How to mark items. Mark each item done (with the location of the evidence), not applicable (with a one-line reason), or open (with an owner and a due date). A "not applicable" with no reason is the first thing a regulator or opposing expert will question.
  • The rule for every factual sentence. Next to each sentence in the draft, record its source of truth. A sentence with no source is a finding, not a style problem.
  • What it covers. The consumer-facing privacy policy and the notices that sit beside it: the notice at collection, opt-out and limit notices, financial incentive notices, just-in-time notices, and the cookie banner. Sector notices and statutory consents appear in Part 13 for their interaction with the policy; their full requirements are in the documents cited there.
  • Companion documents. For the law behind each item, see Privacy Policies, Notices, and Consent: Drafting Disclosures That Are True and Survive the FTC. For the drafting process step by step, see Drafting and Maintaining a Privacy Policy: A Practical Guide. For model language, consent flows, and change records, see Privacy Notice Toolkit: Policy Templates, Consent Flows, and Change Management Records.

Part 1: Scope and applicability

  • List every entity, brand, website, app, device, and offline channel the policy covers, and what it does not cover (data processed for business customers, employee and applicant data, products with their own notices). The scope statement is itself a representation.
  • Choose one unified policy or several specific notices. If several, give each a clear scope and make sure they neither contradict one another nor leave gaps. Separate notices are common for employees and applicants, B2B service-provider data, consumer health data, children's services, and regulated financial products.
  • Confirm whether CalOPPA applies (any commercial website or online service, apps included, that collects personally identifiable information from California residents) and note its required elements: categories collected and shared, the review-and-correction process, how material changes are announced, the effective date, the Do Not Track response, and whether other parties track users across sites.
    • Cal. Bus. & Prof. Code § 22575(b). Under § 22576, failing to comply with your own posted policy, knowingly and willfully or negligently and materially, is itself a violation.
  • Run the CCPA thresholds (Cal. Civ. Code § 1798.140(d)): annual gross revenue above the inflation-adjusted figure ($26,625,000 beginning in 2025); buying, selling, or sharing the personal information of 100,000 or more consumers or households; or deriving half or more of annual revenue from selling or sharing it.
  • Run every other state's thresholds. Most use processing-volume tests (100,000 consumers, or fewer combined with revenue from selling data, with some as low as 35,000), while Texas and Nebraska reach nearly any business that is not a small business. See State Consumer Privacy Laws: The CCPA, the CPRA, and the Multi-State Patchwork.
  • Flag every sector regime with its own notice or consent: COPPA; the GLBA for "financial institutions" as defined in 15 U.S.C. § 6809; HIPAA; FERPA; the FCRA; the VPPA; the TCPA and CAN-SPAM; BIPA and other biometric laws; Washington's My Health My Data Act; and the cable and telecommunications rules.
  • Flag international reach. The GDPR reaches a US business that offers goods or services to people in the EU or monitors their behavior there (Article 3(2)); the UK GDPR mirrors it.
  • Record each applicability decision and its reason in a short memo signed by counsel, and refresh it after any acquisition, new product line, or new market.

Part 2: Gather the facts before drafting

  • Obtain or build the data map: categories of personal information, sources, systems, purposes, recipients, locations, and retention. Without one, the drafting project is really a fact-finding project; see Developing a Privacy Compliance Program.
  • Obtain the vendor list and contracts, and classify every recipient as a service provider or processor (its use is limited to serving you), a contractor, a third party, or an affiliate. The classification decides whether a disclosure is a "sale" or "sharing" and which opt-outs are owed.
  • Run a network capture of the site and apps in every consent state (before any choice, after accepting, after rejecting, and with Global Privacy Control on), logged in and logged out, including sensitive pages and forms. A tag list from marketing is not a substitute; see Auditing Your Website Tracking Stack: A Practical Guide and Website Tracking Compliance Checklist: A Practical Checklist.
  • Inventory each app's SDKs and compare them with the app store disclosures (Apple's privacy labels and privacy manifests, Google Play's Data safety section). "Data Not Collected" beside an analytics SDK that sends device identifiers is the Flo Health fact pattern; see Legal Issues for Mobile Applications: Privacy.
  • Obtain the retention schedule and confirm that the deletion jobs run, including backups and copies held by vendors.
  • Obtain the rights-request workflow and the consent platform's configuration, with sample consent records for each jurisdiction.
  • Collect every other public statement about data: help-center answers, product notices, permission prompts, banner text, the trust or security page, marketing claims, sales decks, security questionnaires, and investor disclosures.
  • Collect every prior version of the policy with its effective dates, and record which data was collected under which version. Parts 16 and 17 depend on it.
  • Interview each system owner from a written question list, then verify the answers against the capture. Engineers describe what the code is supposed to do; the capture shows what it does.
  • List the changes planned for the next 12 months (new features, AI training, new markets, loyalty programs, acquisitions) and decide whether to disclose them now or route them through Part 16.

Part 3: Architecture, placement, and presentation

  • Use a recognizable architecture: scope and who we are; a summary; what we collect; how we use it; how we disclose it; cookies and choices; sensitive data and children; retention; security; your rights; state and international sections; changes; contact information and effective date.
  • Make the summary layer accurate on its own. Readers stop at the first layer, so a summary that says "we never sell your data" is deceptive even if section 9 discloses sharing for advertising.
  • Post the policy conspicuously: a homepage link that contains the word "privacy" and stands out from the surrounding text (Cal. Bus. & Prof. Code § 22577(b)) or, for an app, a link on the download or landing page (Cal. Code Regs. tit. 11, § 7011(d)).
  • Link the policy at every collection point: account creation, checkout, lead forms, app onboarding, the app settings menu, and the store listing.
  • Show the effective date and the "last updated" date at the top. CalOPPA requires the first and the CCPA the second.
  • Write in plain language that reads on a phone: short sentences, everyday words, and defined terms only where they earn their place (Cal. Code Regs. tit. 11, § 7003; GDPR Article 12).
  • Publish the policy in every language the business ordinarily uses with consumers, and version the translations with the English text. An "English controls" clause does not cure a misleading translation.
  • Make the policy accessible (online, generally WCAG 2.1 AA) and printable as a single document, as the CCPA regulations require. See Website Accessibility Remediation Checklist: A Practical Checklist.
  • Use tables for category-by-category disclosures (category, source, purpose, recipients, sold or shared, retention). A table forces the precision that prose lets drafters avoid.
  • Keep state and international sections consistent with the general text. If the California section says the company "shares" data for advertising, the general section cannot say it never discloses data for advertising.

Part 4: What you collect

  • List the categories of personal information by source: what the consumer provides; what is collected automatically (device identifiers, IP address, cookie and pixel data, location, usage events); what comes from third parties (data brokers, advertising and social login partners, business partners); and what the company infers (profiles, segments, predictions).
  • Use the statutory category names where a law requires them, with enough description that a reader understands what each covers.
    • The CCPA's categories appear in the definition of personal information, Cal. Civ. Code § 1798.140(v). A bare list of labels ("identifiers, commercial information") satisfies no one; say what the identifiers are.
  • Call out sensitive personal information separately: government identifiers, account credentials, precise geolocation, racial or ethnic origin, religious beliefs, union membership, the contents of messages not directed to the company, genetic data, biometric data used for identification, health information, sex life or sexual orientation, citizenship or immigration status, children's data, and (in California since 2025) neural data.
    • Definitions vary by state (California's is in Cal. Civ. Code § 1798.140(ae)), so build the list from the strictest law that applies.
  • Describe automatic collection specifically, including cross-device tracking, fingerprinting, session replay, chat transcripts, and server-side event forwarding.
    • The FTC's position since its 2012 privacy report is that practices consumers would not expect must be disclosed clearly and before collection. Session replay and chat recording also raise the consent questions in Parts 7 and 8.
  • Do not describe identifiers as "anonymous." Persistent identifiers and device IDs are personal information under the COPPA Rule (16 C.F.R. Part 312), hashed email addresses and similar identifiers are personal information under the state laws, and the FTC's Avast order treated "anonymized" browsing data as a false claim.
  • State whether the service is directed to children under 13 (and whether it knowingly collects from teens where state law protects them), and make the statement match the audience analysis in Part 9.
  • Reconcile both directions. Every category that appears in the capture or the data map must appear in the policy, and every category in the policy should still be collected; delete what the company stopped collecting.

Part 5: How you use it

  • List each purpose concretely: providing the service, payments, security and fraud prevention, customer support, analytics, product improvement, personalization, marketing, targeted advertising, research, legal compliance, and AI or model training.
  • Delete catch-all purposes such as "other business purposes" or "any purpose permitted by law." Under the GDPR they are noncompliant on their face, and under Section 5 they disclose nothing.
  • For GDPR readers, tie each purpose to a legal basis under Article 6 and name the legitimate interests relied on (Article 13(1)(c) and (d)).
  • Disclose AI and model training specifically: which data, whether customer data trains shared models, whether vendors may train on it, and whether users can opt out.
    • The FTC staff warned in February 2024 that quietly changing terms to permit AI training on previously collected data can be unfair or deceptive, and the Everalbum line of orders shows the remedy: deletion of the models.
  • Disclose profiling and automated decisions that produce legal or similarly significant effects, together with any opt-out or appeal right the governing law provides.
    • GDPR Article 13(2)(f) requires meaningful information about the logic involved. California's 2025 regulations on automated decisionmaking technology add a pre-use notice for significant decisions, with compliance required by January 1, 2027.
  • Test purpose limitation. Under Cal. Civ. Code § 1798.100(c), collection and use must be reasonably necessary and proportionate to the purposes disclosed, and the California Attorney General's 2025 Healthline settlement was built on that principle. A new purpose that is incompatible with what people were told needs fresh notice and, often, consent (Part 16).
  • Match the purposes to the vendor contracts. If the policy says data is used "only to provide our services" while a vendor contract lets the vendor use it for its own product development, one of the two documents is wrong.

Part 6: How you disclose, sell, and share it

  • List the categories of recipients (service providers, contractors, advertising and analytics partners, affiliates, business partners, data brokers, authorities and litigants, acquirers) with the categories of data and the purpose for each.
  • Classify every pixel, SDK, and data partner as a service provider or contractor (with the contract terms the law requires) or as a third party.
    • California's "sharing" covers disclosure for cross-context behavioral advertising whether or not money changes hands (Cal. Civ. Code § 1798.140(ah)), and several states treat an exchange for other valuable consideration as a "sale."
  • Use the statutory vocabulary and make each statement literally true. For example: "We do not sell personal information for money. We share it with advertising partners for targeted advertising, which California law calls 'sharing.' You can opt out here."
  • Re-test every "we never share" sentence against the capture. Flo Health, GoodRx, and BetterHelp promised confidentiality while SDKs sent health-related events to advertising platforms, and the FTC treated those tools as third parties.
  • If the business knowingly sells or shares the data of consumers under 16, describe the opt-in process the CCPA requires (the teen's own opt-in from 13 to 15, a parent's under 13).
  • Add the Texas notices if the business sells sensitive or biometric data: "NOTICE: We may sell your sensitive personal data" and "NOTICE: We may sell your biometric personal data" (Tex. Bus. & Com. Code § 541.102).
  • Check affiliate sharing against the financial privacy rules, including the FCRA's affiliate-marketing notice and opt-out, 15 U.S.C. § 1681s-3 and 16 C.F.R. Part 680.
  • Describe legal process honestly: when the company discloses data to law enforcement or civil litigants, and whether it notifies users first. Litigants trying to unmask an anonymous user will test that promise; see Identifying an Anonymous Defendant Online: A Practical Guide.
  • Disclose that data may transfer in a merger, acquisition, financing, or bankruptcy, and understand that the buyer takes the promises along with the data.
    • In bankruptcy, 11 U.S.C. § 363(b)(1) restricts a sale of personal information that would violate the policy in effect at filing unless the court approves it after review by a consumer privacy ombudsman appointed under 11 U.S.C. § 332.
  • If the company sells, licenses, or gives access to bulk sensitive data, check the foreign-adversary rules: the Justice Department's data security regulations, 28 C.F.R. Part 202, and the Protecting Americans' Data from Foreign Adversaries Act of 2024, 15 U.S.C. § 9901, which bars data brokers from transferring sensitive data to foreign adversary countries or entities they control.

Part 7: Cookies, pixels, SDKs, and opt-out signals

  • Describe each category of tracking technology (cookies, pixels, SDKs, local storage, server-side tags, fingerprinting) and who receives the data each collects.
  • Answer CalOPPA's Do Not Track question separately from Global Privacy Control. "We do not respond to Do Not Track signals" is usually true. "We do not respond to browser privacy signals" is false for any business that must honor Global Privacy Control.
  • Honor opt-out preference signals wherever the law requires, and say in the policy how the company processes them: for the browser only, for a logged-in account, for offline sales, and in which states.
    • Cal. Code Regs. tit. 11, § 7025; Colorado and a growing majority of the other state laws now require recognition of universal opt-out mechanisms. California's amended regulations also call for the site to display whether it has processed the signal, which doubles as the best evidence that it did.
  • Post the California opt-out links where required: "Do Not Sell or Share My Personal Information" and "Limit the Use of My Sensitive Personal Information," or the single alternative link ("Your Privacy Choices" or "Your California Privacy Choices," with the prescribed icon).
    • Cal. Civ. Code § 1798.135; Cal. Code Regs. tit. 11, §§ 7013 to 7015.
  • Verify that the banner actually gates the tags. In a capture, no advertising or analytics tag should fire before a choice where opt-in applies, and none should fire after a rejection anywhere.
    • A banner that gates nothing is evidence against the company, not a defense.
  • Hold session replay, chat recording, and pixels on sensitive pages until the user has seen and acted on a notice.
  • Keep video viewing data out of pixels unless the company has VPPA consent in a form distinct and separate from other terms, 18 U.S.C. § 2710(b)(2)(B).
  • Match the cookie notice and the consent categories to the tag inventory, including tags loaded by other tags and tags added by agencies.

Part 8: Consent flows and dark patterns

  • Identify every point where the law requires consent, not just notice: sensitive data in most states, children's data, consumer health data under Washington and Nevada law, biometric data, nonessential cookies for EU and UK users, TCPA marketing, VPPA disclosures, financial incentive programs, and material retroactive changes.
  • Make the choices symmetrical: equal-weight "Accept" and "Reject" buttons, never "Accept All" beside a small "Settings" link (Cal. Code Regs. tit. 11, § 7004).
    • The California Privacy Protection Agency's 2025 order against Honda faulted a cookie tool that took one click to accept and more to decline.
  • Remove the named dark patterns: confusing language, double negatives, toggles whose state is unclear, shaming ("No thanks, I don't care about my privacy"), pre-checked boxes, bundled purposes, and repeated prompts after a refusal.
    • Consent obtained through a dark pattern is not consent in California (Cal. Civ. Code § 1798.140(h), (l)). The FTC attacks the same designs under 15 U.S.C. § 45, as its 2022 staff report Bringing Dark Patterns to Light explains.
  • Make each consent specific and informed: what data, for what purpose, and who receives it, with separate consents where the law requires them. Washington requires separate consent to collect and to share consumer health data; the amended COPPA Rule requires separate parental consent before most disclosures to third parties.
  • Make withdrawal as easy as giving consent, through a persistent link or a settings toggle rather than a support ticket (GDPR Article 7(3) states the rule expressly).
  • Put the consent before the processing. Tags wait for the choice, replay waits for the notice, and permission prompts appear before the app reads contacts or location.
  • Keep consent records that prove what happened: timestamp, identifier, jurisdiction, notice version, the interface shown, the choice made, and any later withdrawal.
  • Never treat the policy as consent to a practice it does not clearly describe. Consent to processing messages was not consent to scanning them for advertising in Campbell v. Facebook Inc., 77 F. Supp. 3d 836 (N.D. Cal. 2014); consent to one invitation email did not cover two reminders in Perkins v. LinkedIn Corp., 53 F. Supp. 3d 1190 (N.D. Cal. 2014); and consent "should not casually be inferred" under In re Pharmatrak, Inc., 329 F.3d 9 (1st Cir. 2003).
  • Check any subscription or auto-renewal offer on the same screen for express informed consent under the Restore Online Shoppers' Confidence Act, 15 U.S.C. § 8403. See Dark Patterns, Auto-Renewal, and the FTC Click-to-Cancel Rule.

Part 9: Sensitive data, health, biometrics, children, and teens

  • Obtain opt-in consent before processing sensitive data where the law requires it, and in California offer the right to limit if sensitive data is used beyond the permitted purposes. Maryland's law, effective October 1, 2025, limits collection of sensitive data to what is strictly necessary and bans its sale.
  • Treat health-adjacent data as health data: fitness, fertility, mental health, prescription, and symptom data, and inferences drawn from purchases or page visits.
    • Washington's My Health My Data Act requires a separate consumer health data policy linked from the homepage, separate consents to collect and to share, a signed authorization to sell, and no geofencing around health facilities, all enforceable through a private right of action. Nevada's 2023 law follows a similar model.
  • Check whether a health app is covered by the Health Breach Notification Rule, 16 C.F.R. Part 318, as amended in 2024. An unauthorized disclosure to an advertising platform is a "breach of security," as GoodRx learned in the first enforcement action under the rule.
  • Delete any "HIPAA compliant" claim or compliance seal that does not describe a real regulatory status. GoodRx displayed one it had no basis to display.
  • Keep biometric instruments outside the general policy: a publicly available written retention and destruction policy (740 ILCS 14/15(a)) and, before collection, written notice of the specific purpose and length of term plus a written release (740 ILCS 14/15(b)).
  • Decide in a dated audience analysis whether the service is directed to children, and if COPPA applies, prepare its separate instruments: the online notice (16 C.F.R. § 312.4(d)), the direct notice to parents (§ 312.4(b) and (c)), and verifiable parental consent before collection (§ 312.5).
  • Check the teen rules: the CCPA's opt-in before selling or sharing the data of consumers under 16, and the state laws that restrict targeted advertising to known teens.
  • Use a just-in-time notice for precise geolocation, obtain opt-in consent where required, and never sell location data that reveals visits to sensitive places. The FTC's 2024 X-Mode and InMarket orders banned such sales and required consent verification down the supply chain.

Part 10: Retention and security statements

  • Disclose retention by category of data, as a period or as the criteria used to set it.
    • The CCPA requires this at the point of collection (Cal. Civ. Code § 1798.100(a)(3)), the GDPR requires it under Articles 13(2)(a) and 14(2)(a), the amended COPPA Rule requires a written retention policy, and BIPA requires a public destruction schedule. "As long as necessary" is not a period or a criterion.
  • Confirm that the schedule exists and the deletion jobs run, including backup roll-off and deletion by vendors.
  • Describe deletion truthfully: the difference between deactivating and deleting an account, how long backups persist, legal holds, and what de-identified or aggregated data the company keeps.
    • Everalbum promised that deactivation deleted photos; it did not, and the order required deletion of the facial recognition models built from them.
  • Describe security controls, not outcomes. Remove guarantees ("your data is always safe," "bank-level security," "military-grade encryption") and describe what the company actually does.
  • Have the security owner approve the security paragraph and match it to the written information security program.
  • If the policy mentions breach notification, make it match the incident response plan and the law, and do not promise a timeline the company cannot meet. Breach notices themselves are representations, as the FTC's 2024 Blackbaud order shows.

Part 11: Consumer rights and requests

  • List each right the company honors and where it applies (access or know, deletion, correction, portability, opt-out of sale, sharing, targeted advertising, and profiling, the right to limit, and the right to appeal). If the company extends rights to everyone as a business choice, it must then honor them for everyone.
  • Provide the request methods the law requires. The CCPA requires two or more designated methods, including a toll-free number, unless the business operates exclusively online and has a direct relationship with the consumer, in which case an email address suffices (Cal. Civ. Code § 1798.130(a)(1)).
  • Describe identity verification and how authorized agents submit requests, and make sure verification is proportionate. Excessive verification demands for opt-outs were part of the Honda order.
  • Describe the appeal process where state law requires one (Virginia, Colorado, Connecticut, and most of the newer laws), including how to contact the attorney general if an appeal is denied.
  • State the non-discrimination rule and describe any financial incentive separately (Part 12).
  • Publish request metrics if required. A business that buys, receives, sells, or shares the personal information of 10 million or more California consumers in a year must disclose annual request metrics (Cal. Code Regs. tit. 11, § 7102).
  • Test every channel with real requests and confirm the deadlines: 45 days under the CCPA and most state laws (extendable once), and one month under the GDPR (extendable in limited cases).

Part 12: California, multistate, and international sections

  • California privacy policy contents (Cal. Civ. Code § 1798.130(a)(5); Cal. Code Regs. tit. 11, § 7011): categories collected in the preceding 12 months; sources; purposes; categories sold, shared, or disclosed for a business purpose, and to whom; each right and how to exercise it; how opt-out preference signals are processed; whether sensitive personal information is used beyond the permitted purposes; the under-16 statement; contact information; and the date last updated.
  • California notice at collection (Cal. Civ. Code § 1798.100(a); Regs. § 7012): categories of personal and sensitive personal information, purposes, whether each category is sold or shared, retention for each category, the opt-out link if applicable, and a link to the policy.
    • Present it at or before collection: near the form or submit button online; on the form, on a sign, or orally offline. A link to the top of the policy does not qualify; it must go straight to the section with the required elements.
  • Separate California notices for employees, applicants, and independent contractors, whom the CCPA has fully covered since January 1, 2023. See Employee Monitoring and Workplace Privacy: A Practical Guide.
  • Notice of financial incentive before enrollment in any loyalty program or data-linked discount (Cal. Civ. Code § 1798.125(b); Regs. § 7016): material terms, categories of data, how to opt in and withdraw, and a good-faith estimate of the value of the consumer's data with the method used to calculate it (Regs. § 7081 lists acceptable methods).
  • Multistate contents: categories processed, purposes, how to exercise rights and appeal, categories shared, categories of third parties, any sale or targeted advertising with the opt-out method, and a contact method.
    • State additions include Colorado's rules on material-change notice and refreshing consent for sensitive data, Colorado's statutory bar on secondary use without consent, Minnesota's data inventory and profiling rights, the Texas sale notices (Part 6), and Washington's separate health data policy (Part 9).
  • GDPR and UK GDPR contents (Articles 13 and 14): controller identity and, where required, the representative under Article 27; the data protection officer; each purpose with its legal basis and any legitimate interests; recipients; transfers and their safeguards; retention; each right, including withdrawal of consent and complaint to a supervisory authority; whether providing data is required; automated decision-making; and, for data obtained indirectly, its source, provided within one month at most.
  • Present the GDPR right to object clearly and separately from other information, no later than the first communication (Article 21(4)).
  • Obtain prior consent for nonessential cookies from EU and UK users. A pre-ticked box is not consent (the Court of Justice's Planet49 decision, 2019), and French regulators fined Google and Facebook in 2022 for making refusal harder than acceptance.
  • If the policy claims participation in the EU-U.S. Data Privacy Framework, confirm that the certification is current and that the policy contains the statements the Framework requires. The FTC repeatedly sued companies that claimed Privacy Shield certifications they had let lapse. See International Data Transfers After Schrems II: Standard Contractual Clauses and Transfer Impact Assessments.

Part 13: Sector notices and statutory consents that must stay separate

A general privacy policy cannot do the work of these instruments. Cross-reference each one from the policy, but never describe the policy as satisfying it.

Part 14: Words that create liability: a line-by-line review

  • Search the draft for absolutes (never, always, all, any, only, guarantee, completely, secure, safe, private, anonymous, anonymized, encrypted, permanently, delete, certified, compliant, industry-standard, bank-level) and, for each hit, either prove it or rewrite it.
  • Delete reassurance that says nothing ("we take your privacy seriously," "we respect your privacy"). It is quoted back in complaints as the opening line of the deception count.
  • Use "de-identified" only if the data meets the governing definition. California requires reasonable technical measures against re-identification, a public commitment not to re-identify, and contractual commitments from recipients (Cal. Civ. Code § 1798.140(m)).
  • Check every "only." "We use your data only to provide the services" is false if analytics vendors, advertising partners, or model training touch it.
  • Decide deliberately which statements are commitments. Courts have read some policy language as information rather than promises (In re Facebook, Inc. Internet Tracking Litigation, 956 F.3d 589 (9th Cir. 2020); Kuhns v. Scottrade, Inc., 868 F.3d 711 (8th Cir. 2017)) and discretion-laden language as no offer at all (In re Northwest Airlines Privacy Litigation, No. 04-126 (D. Minn. June 6, 2004)), but those readings do not help with the FTC, and the same words can still create the privacy expectation that supports an intrusion claim.
  • Watch narrow definitions. A cramped definition of "personal information" (for example, only information the user voluntarily provides when the company asks for it) can defeat a contract claim, Carlsen v. GameStop, Inc., 833 F.3d 903 (8th Cir. 2016), yet create the misleading net impression the FTC attacks, FTC v. Cyberspace.com LLC, 453 F.3d 1196 (9th Cir. 2006). If the definition excludes device identifiers or hashed emails, say so plainly, and then ask whether the overall presentation is still honest.
  • Treat audience-specific promises as high-risk. A registration page that told parents "HEY GROWN-UPS: We don't collect ANY personal information about your kids" kept an intrusion claim alive in In re Nickelodeon Consumer Privacy Litigation, 827 F.3d 262 (3d Cir. 2016), and public statements about honoring cookie blockers did the same in In re Google Inc. Cookie Placement Consumer Privacy Litigation, 806 F.3d 125 (3d Cir. 2015).
  • Read each sentence as the plaintiff's expert will: next to a network capture, and next to the help-center answer on the same subject.

Part 15: The policy as a contract: incorporation, assent, and the change clause

Part 16: Change management and the retroactive-change rule

  • Define "material change" in a written procedure. Examples: a new category of sensitive data, a new category of recipients, a new purpose (including AI training), the start of selling or sharing, longer retention, and fewer choices.
  • Give advance notice of prospective material changes by a method that reaches existing users, with an effective date after the notice, and obtain consent where the governing law requires it (for example, Colorado's bar on secondary use without consent).
  • Obtain affirmative express consent before applying a material change to data already collected, or keep that data under the old terms.
    • This is the Gateway Learning rule (2004), repeated in the Facebook order (2011) and the 1Health.io/Vitagene order (2023). If consent is not obtainable, segregate the old data by the version under which it was collected.
  • Run the sector change procedures as well: a revised GLBA notice and a new opt-out opportunity before new sharing; a revised HIPAA notice before a material change takes effect; new verifiable parental consent under COPPA before a material change in the collection, use, or disclosure of children's information; and, under GDPR Article 13(3), information to the data subject before processing for a new purpose.
  • For AI training on existing data, assume consent is required unless counsel concludes otherwise in writing. The FTC staff's February 2024 warning was aimed squarely at quietly changed terms, and model deletion is an available remedy.
  • Update every downstream statement at the same time: notices at collection, banners, app store labels, permission prompts, help-center pages, translations, and data processing agreements.
  • Record each change in a change log with the decision on materiality, the notice given, the consent obtained, and the approvals. The toolkit's change-management templates are built for this.

Part 17: Version control, archiving, and evidence

  • Archive every version with its effective date, a redline against the prior version, the approvals, the products and sites it covered, its translations, and screenshots of the collection points, banners, and consent flows it governed.
  • Keep the archive under the company's control, with file hashes or another integrity check. Third-party web archives are useful, but they are not a records program.
  • Be able to answer, for any date: what the policy said, what the user saw at sign-up or checkout, and what consent the user gave.
  • Plan authentication now. Prior versions come in through a witness with knowledge or distinctive characteristics under Fed. R. Evid. 901 or by certification of electronic records under Fed. R. Evid. 902 (paragraphs (13) and (14)); consent logs come in as business records under Fed. R. Evid. 803(6) if kept in the regular course; and courts are divided on taking judicial notice of archived pages under Fed. R. Evid. 201.
  • Make the litigation hold reach the systems that overwrite themselves: tag manager container histories, consent platform configurations, SDK versions, event schemas, and the policy change log. Losing them invites measures under Fed. R. Civ. P. 37(e).

Part 18: The accuracy audit and maintenance calendar

  • Audit at least annually against six sources of truth: the data map; the vendor list and contracts; a fresh network capture in each consent state; the consent platform's behavior, including signal handling; the retention schedule and deletion jobs; and every other public statement about data.
  • Re-review on every trigger: a new vendor, SDK, or tag; a new category of data; a new purpose; a new jurisdiction or product; an acquisition; a regulatory change; a security incident; or a complaint, demand letter, or regulator inquiry.
  • Gate new technology. No tag, SDK, or data partner goes live until someone has asked whether the policy still tells the truth with it in place.
  • Train the people who can make the policy false: web and marketing teams, product managers, data scientists, and customer support.
When Task
Before launch of any product or feature that collects new data Privacy review; update notices at collection and just-in-time notices
Each release Re-test consent gating and signal handling
Quarterly Network capture of top pages and apps; reconcile tags against the inventory
Every 12 months (California requires it) Full accuracy audit; update the policy and its "last updated" date; refresh the applicability memo
By July 1 (large California businesses) Publish prior-year request metrics
On any trigger Change-management review under Part 16

Part 19: Reviewing someone else's policy: plaintiffs, regulators, and acquirers

The same items work in reverse. Whoever reads the policy for inconsistencies puts the questions in Parts 2 through 18 to the company's records instead of their own.

Common mistakes this checklist is designed to catch

  • A policy copied from a competitor, describing the competitor's systems.
  • "We do not sell your data" on a site that runs advertising pixels, with no mention of sharing.
  • A cookie banner that records choices but fires the same tags either way.
  • "We do not respond to browser signals" from a business that must honor Global Privacy Control.
  • Session replay and chat recording that start on page load, with consent "supplied" by a footer link.
  • Retention described as "as long as necessary," with no schedule behind it.
  • A security paragraph that guarantees outcomes instead of describing controls.
  • Statutory consents (TCPA, VPPA, BIPA, HIPAA authorizations, COPPA parental consent) buried inside the policy.
  • A new use of old data, often AI training, applied without consent.
  • A renamed policy that the terms of service no longer incorporate.
  • No archive of prior versions, so nobody can prove what users were told.
  • Help-center pages, app store labels, and sales materials that drifted away from the policy.

Frequently asked questions

How long does a full review take? For a company with a current data map and vendor list, a few weeks. Without them, the fact-gathering in Part 2 takes most of the time, often a quarter or more for a mid-size business with several apps, because the captures and interviews surface practices nobody had written down.

Can we start from a template or a policy generator? For structure, yes. For facts, no. A template cannot know which pixels fire on your checkout page, and the FTC does not care where a false sentence came from.

Do we need a separate California policy? Usually not. One policy with a clearly labeled California section works if the general and California text agree. Separate documents make sense for different audiences (employees, applicants, B2B customers) or where a law requires a standalone document, such as Washington's consumer health data policy.

Is it safer to say less? Only if what remains is true and complete. Silence about a practice consumers would not expect is a deceptive omission, and vague language will not establish consent to a specific practice later. The safest policy is short, precise, and provable.

We found that our policy has been wrong for a while. What now? Stop or fix the practice, then preserve the evidence (tag histories, SDK versions, prior policy versions) before anything is overwritten. Have counsel assess notice duties, such as a "breach of security" under the Health Breach Notification Rule for an unauthorized health data disclosure, and then correct the policy prospectively.

Does posting an updated policy fix past practices? No. The updated policy governs going forward, and only for users who received notice. Past statements remain the measure of past conduct for the FTC, state attorneys general, and private plaintiffs, and applying a new policy to old data requires consent.

Practical takeaways

  • Build the policy from the data map, the vendor contracts, the network capture, and the retention schedule; if those do not exist, start there.
  • Write every sentence so that someone could prove it with a document or a capture.
  • Use the statutory vocabulary ("sale," "sharing," "sensitive," "de-identified") and say exactly what the company does.
  • Make consent banners gate the tags, honor Global Privacy Control, and keep consent records that show what each user saw.
  • Keep sector notices and statutory consents in their own instruments.
  • Treat help-center answers, app store labels, and product notices as part of the policy; the most specific statement controls.
  • Get affirmative consent before applying a material change, including AI training, to data already collected.
  • Archive every version with screenshots, and audit at least every 12 months and on every trigger.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Companion documents in this series

Related Articles and Guides

Related Checklists

Related Toolkits