Privacy Policy Requirements: What Your Policy Must Disclose (Guide)

A privacy policy must disclose who you are and how to contact you, what personal data you collect, why you collect it, who receives it, how long you keep it, what rights people have over it and how to exercise them, and how and when the policy changes. The exact item list comes from the laws that bind you.

Regulators consider the privacy policy to be more than just paperwork. They look at whether what a company says matches what its website and data practices actually do. The FTC extracted $7.8 million from BetterHelp and $16.5 million from Avast because they had said one thing but had done another.

California took a similar approach with Sephora. In 2022, the Attorney General fined Sephora $1.2 million because their website claimed “we do not sell personally identifiable information,” but third-party trackers were selling customer data. It also failed to honor Global Privacy Control signals.

A compliant privacy policy must do more than exist. It must include required disclosures and reflect your actual data practices.

This guide includes all the disclosure requirements that businesses must follow in 2026. It also addresses a key issue many overlook: how detailed your policy should be and how to keep it accurate.

Is a privacy policy legally required? 

No single US federal law requires every website to have a privacy policy. Instead, requirements come from state laws, industry-specific rules, the GDPR if you handle data from EU residents, and contracts with app stores or analytics providers. Even if none apply, any policy you publish can still be enforced as a promise to your users.

One more layer binds businesses no statute touches. Under Section 5 of the FTC Act, “unfair or deceptive acts or practices in or affecting commerce” are unlawful, and the FTC reads a published policy as public promises: diverge from it, and the policy itself becomes the deception. The enforcement record in the second half of this guide runs on that theory. Samuel Levine, Director of the FTC’s Bureau of Consumer Protection, put it plainly in the Avast case:

 “Avast’s bait-and-switch surveillance tactics compromised consumers’ privacy and broke the law.”

(FTC press release, February 22, 2024).

A terminology note before the item lists. US state statutes say “privacy notice,” older and sectoral laws say “privacy policy,” and California’s regulations require the homepage link to include the word “privacy.” The terms describe the same public document; this guide flags the few places where an instrument prescribes the label.

What must every privacy policy contain?

Most regimes ask for the same core elements. What changes is the level of detail, not the basic structure. Build the first draft around that shared structure, then add the requirements unique to each regime.

One correction belongs here because it is a common misinclusion: California’s Age-Appropriate Design Code Act is a DPIA duty, not a policy-disclosure duty, and the Ninth Circuit left it partially enjoined in NetChoice v. Bonta (March 12, 2026). Keep it off the policy checklist.

Two things are as important as the list of required items. The first is specificity: California’s rules require you to explain your reasons for collecting information clearly enough that consumers truly understand why you need their data. Vague or generic explanations are not enough.

The second is plain language: GDPR Article 12 says your policy must be easy to read and understand. Research shows why this matters. One study found the average privacy policy is about 2,514 words long, and reading every policy you see in a year would take around 244 hours. Lorrie Cranor believes this number has probably increased since then:

“It might even be worse now, because now we see this real proliferation of third-party content embedded in websites.”

(Princeton Engineering interview, November 2021).

A template or generator can help you create the basic structure of a privacy policy, but that’s all it does. It can’t know which trackers your website uses or which vendors get your form data. The accuracy of your policy depends on what you actually observe on your site.

What does the GDPR add to privacy policy requirements?

The GDPR is the most itemized disclosure regime in force anywhere, and it sets both the form and the content: Article 12 requires the information to be concise, transparent, intelligible, easily accessible, and in clear and plain language, free of charge. The content list is split by where the data came from.

Legal basis per purpose is uniquely GDPR (and UK GDPR); US regimes ask for purposes, never the legal theory beneath each one. And Article 14’s one-month clock gives a business buying or receiving data an affirmative duty to go find the data subjects, a duty with no US equivalent. Penalties for transparency violations sit in the GDPR’s top tier: up to €20 million or 4 percent of global annual turnover under Article 83(5)(b). 

For the broader framework, see our GDPR explainer.

What does CCPA/CPRA add?

California’s is the most prescriptive US regime: it dictates not just the policy’s contents but its update cadence, its link text, and even a duty to disclose what you don’t do. The policy obligations sit in Cal. Civ. Code § 1798.130(a)(5) and 11 CCR § 7011.

One caution on the word “sale”: the California Consumer Privacy Act defines it as an exchange for monetary or other valuable consideration, which is how routine advertising analytics became “sales”. 

Penalties adjust for inflation: as of January 1, 2025, $2,663 per violation and $7,988 per intentional violation or one involving known minors, plus statutory damages of $107 to $799 per consumer per incident in private breach actions (CPPA adjustment notice; next adjustment is January 2027). 

For applicability thresholds, rights mechanics, and enforcement details, see What is CCPA? and the compliance guide.

What do the other state laws add?

Twenty states have relevant data privacy laws in force as of September 2026, and four more (Alabama, Louisiana, Oklahoma, Vermont) are enacted with future effective dates, per the IAPP state privacy legislation tracker. 

Read this table as deltas, not entries: nearly all these laws demand the same baseline notice, and only a few add genuine extras. The baseline is a reasonably accessible, clear, and meaningful privacy notice disclosing personal data categories processed, purposes, consumer rights and how to exercise them (including appeal), categories of data shared with third parties, and categories of those third parties. Texas’s § 541.102(a) is a verbatim example of the pattern.

Everything else the state wave adds (opt-out preference signals, sensitive-data consent, data-protection assessments) binds your data handling practices more than your policy text. The notice contents stay close to the baseline. 

There are two practical takeaways. First, most businesses use one main privacy policy with an extra section for state-specific rights, especially California. Second, the list of state laws changes often, so any count of “how many states” have privacy laws will quickly become outdated.

What do sectoral laws and non-US regimes add?

If you operate in a regulated sector, a second disclosure layer sits on top of general laws. Each row below is the delta that matters for your policy, not the whole statute.

One disambiguation worth printing: “the Privacy Act” means different things in different countries. In the US, it is the 1974 statute governing federal agencies; it doesn’t apply to your business. In Australia, the Privacy Act 1988 is the main private-sector law, and its APP 1 is a genuine policy mandate (below). Same name, opposite relevance.

And the non-US regimes, one row each:

The pattern across all five: the spine travels. Identity, purposes, categories, recipients, retention, rights. What changes per jurisdiction is granularity and timing.

Do you have to name every recipient, or are categories enough?

In most cases, listing categories of recipients is enough for your privacy policy. You only need to name specific recipients in certain situations. For example, Oregon’s law is often misunderstood: you only have to provide a list of specific third parties if someone asks, not in your published policy.

What the GDPR actually says

Article 13(1)(e) requires “the recipients or categories of recipients.” That “or” is a real choice at the policy level: a well-defined category is compliant. The confusion starts at the access right. In January 2023, the Court of Justice of the EU ruled in C-154/21 (RW v Österreichische Post) that on an access request, the controller must disclose the actual identity of the recipients whenever that is possible. 

Categories suffice only where identification is impossible, or the request is manifestly unfounded or excessive, and the choice belongs to the data subject, not the controller. The court did not rewrite Article 13: your policy may still say “categories,” but your access-request answer may have to say names. A controller that cannot name its recipients cannot comply. That is the ruling’s operational bite.

What US state laws actually say

Every comprehensive US state law writes its proactive notice duty in categories: categories of personal data shared, and categories of third parties receiving it. None requires the published policy to enumerate recipients by name. This is a categories-based system by design.

The Oregon exception

Oregon’s Consumer Privacy Act gives a consumer the right to obtain, “at the controller’s option, a list of specific third parties, other than natural persons, to which the controller has disclosed” either that consumer’s data or any consumer’s data (ORS 646A.574(1)(a)(B)). Minnesota’s law grants the same right in nearly identical words (Minn. Stat. § 325M.14, subd. 1(h)). It is a response duty: it activates when someone asks, not when you publish. The controller chooses which list to give: your recipients or its full recipient list. 

Where naming is compulsory anyway

• Children’s services. COPPA’s online notice must state the “identities and specific categories” of third parties, one of the only name-required policy duties in US law.
• China. PIPL Article 23 requires notifying individuals of the recipient’s name and obtaining separate consent before providing data to another handler. Article 39 does the same for cross-border provision. Categories don’t satisfy it.
• Consent integrity. Brazil’s LGPD voids consent built on misleading or incomplete disclosure (Art. 9 § 1), which makes vague recipient language a consent problem, not just a notice problem.
• Contract and platform layers. Google Play’s policy must state the parties data is shared with, and GDPR Article 28 processor contracts make the controller-processor chain documentary even where the public policy stays categorical.

Policy vs request vs record: the three-records separation

So: do jurisdictions actually conflict? Rarely, and not here. What looks like conflict is granularity difference plus one timing difference: some duties attach to the document, others to the request. The real tensions are practical, not legal. 

Naming every subprocessor in a public policy collides with readability and goes stale within weeks. Categories stay true longer but answer less. A naming promise you cannot fulfill because you have never observed where the data goes is worse than an honest category. You cannot disclose recipients you have not mapped, which is why tracing what your site actually sends must precede writing.

What happens when the privacy policy meets reality? 

A privacy policy is judged against what your site actually does. The gap between the two is now the single most productive enforcement theory in US privacy law. These are the mistakes regulators and plaintiffs keep citing:

1. The flatly false sentence. Sephora’s site said “we do not sell personal information” while its trackers sold customer data. The Attorney General’s case led with that sentence.
2. The stale policy. Tractor Supply’s policy had not been updated in four years and no longer notified consumers of their rights. The CPPA made it the largest fine in its history.
3. Categories that no longer match the vendors. A new tag, agency pixel, or AI vendor silently widens the gap between disclosed categories and the real recipient list.
4. Generic purposes. “To improve our services” fails California’s meaningful-understanding standard and tells the reader nothing.
5. Missing negative disclosures. California requires you to say prominently when you do not sell or share; silence reads as concealment.
6. Opt-outs that exist on paper only. Disney’s $2.75 million settlement (2026) punished opt-out toggles that did not apply across services and devices. The policy promised a control the product did not deliver.

“There are no more excuses,” California AG Rob Bonta said when announcing the Sephora settlement: 

“Follow the law, do right by consumers, and process opt-out requests made via user-enabled global privacy controls”

(press release).

Keeping your privacy policy accurate is an ongoing responsibility. Several laws make this clear:

California’s twelve-month duty is the only hard calendar in US law, but every regime treats an inaccurate policy as a current violation, so “reviewed when someone remembers” is non-compliant everywhere in effect. The triggers are operational. A new vendor, tag, form field, purpose, or state law taking effect can falsify the document overnight. 

How does MELURNA help?

Everything above assumes you know what your site actually sends. That assumption is what the cases above broke on: disclosures are written from the vendor register and contract file, while the real recipient list lives in the tag container, form handler, and fourth-party scripts your vendors load.

MELURNA is built on the observed side of that gap. It tracks data flows from the moment data enters your site through all the third parties and beyond, showing exactly what information is shared and with whom. 

MELURNA compares what your policy promises with what actually happens, just like regulators do. It also checks if user choices, like opt-outs or Global Privacy Control signals, really change who gets the data. Continuous monitoring helps you spot changes, like new tags or vendors, that could make your policy inaccurate between reviews. All findings are mapped to over 30 compliance frameworks and come with timestamped evidence for your legal team.

What MELURNA does not do is write your privacy policy or provide legal advice. You and your legal team are responsible for drafting the policy. What it does is give you the evidence you need, so you know where your regulated data goes before a regulator or a plaintiff’s expert finds out.

Request a demo to see how data moves through your own website.

Next steps

Audit your current policy against the disclosure spine above and mark every element your regimes require but the document lacks. Then close the evidence gap. See what your site actually sends, and to whom, before a regulator runs the same comparison for you. If California is your binding regime, continue with What is CCPA? and the CCPA compliance guide; if your immediate problem is tracking coverage, start with how data privacy risk actually happens.

FAQs

DISCLAIMER: This guide is for general informational purposes only and does not constitute legal advice. While we strive for accuracy, we make no warranties about the completeness or reliability of this information, and are not liable for any errors, omissions, or actions taken based on its contents. Consult a licensed attorney for guidance specific to your business.