Privacy policy examples, annotated section by section

Start with the sample closest to your product. A store’s payment and order disclosures will not answer every question about a mobile app’s SDKs, permissions, or account deletion. These complete samples use fictional answers and show how the sections fit together. After choosing one, use the annotated wording below to check your own draft:

• Website privacy policy sample: a fictional content website with Google Analytics, a newsletter, consent, and EU and UK rights
• Mobile app privacy policy sample: a fictional app with accounts, Firebase analytics, in-app subscriptions, and California disclosures
• E-commerce privacy policy sample: a fictional online store with Stripe payments, a newsletter, Meta Pixel advertising, and EU and Canada rights
• AI SaaS privacy policy sample: a fictional AI writing product with model providers, stored prompts, no training, and GDPR rights

Use them to understand structure and level of detail, not as text to copy. Each one describes a fictional business's practices. When you are ready, the privacy policy template page explains how the same structure adapts to your own answers.

Strong privacy policies look different on the surface, but they share a handful of traits you can recognise in seconds:

• Specific, not generic: they name real data categories, tools, and providers instead of “certain information” and “trusted partners”
• Purpose-led: each use of data is tied to a reason a reader understands
• Scannable: clear headings, short paragraphs, lists, and often a summary at the top
• Actionable: they explain how to exercise rights, with a working contact route
• Honest about limits: they describe security measures without promising perfect safety
• Dated: they show an effective date and explain how changes are announced

The UK ICO's list of privacy information and GDPR Article 13 describe the content; plain language makes it usable. The examples below use a fictional business, Harbor Lane Ceramics, an online pottery shop in Ireland that sells to customers in the EU and the UK, uses a payment processor, sends a newsletter, and runs analytics with consent. The snippets are illustrative only. Your own wording must describe your own practices, which is why copying is a bad idea, as explained in can I copy a privacy policy.

Example wording: “Harbor Lane Ceramics Ltd (fictional), 1 Example Street, Example City, Ireland, is responsible for the personal information described in this policy. You can contact us about privacy at [email protected]. We aim to reply within five working days.”

Why it works:

• It names the legal entity, not just the brand, which is what GDPR Article 13 asks for when it requires the controller's identity and contact details
• It gives a dedicated privacy contact that someone monitors
• It sets a realistic expectation for replies

If you have appointed a data protection officer, or an EU or UK representative because you are based outside those regions, their contact details belong here too. Avoid generic “contact us through our website” wording when you can give a direct route.

A common weakness in policies found online is naming only a brand or a website address. Readers, regulators, and app store reviewers want to know which company is actually accountable, and Google Play's User Data policy explicitly asks for developer information and a privacy point of contact.

Example wording: “We collect:

• Order details you give us at checkout: name, email address, delivery address, and phone number
• Payment confirmation from our payment processor; we do not see or store your full card number
• Newsletter details: your email address and which emails you open, if you subscribe
• Usage information collected automatically with your consent: pages viewed, device type, and approximate location derived from your IP address
• Messages you send us by email or through our contact form”

Why it works: each category is concrete and tied to where it comes from: you, automatic collection, or a third party. A reader can match every item to something they have done on the site. Notice the explicit statement about card numbers; it answers a question many shoppers have and is only true because the shop uses a hosted checkout.

The weak version of this section reads “We may collect personal information such as your name, email, and other information.” It tells the reader nothing about what actually happens, and it would not satisfy laws that require categories and sources.

Example wording: “We use your information to:

• Process and deliver your orders and handle returns (legal basis: performance of a contract)
• Send order confirmations and delivery updates (contract)
• Send our newsletter if you subscribe (consent, which you can withdraw at any time)
• Understand how visitors use our site so we can improve it (consent through our cookie settings)
• Keep the accounting records that tax law requires (legal obligation)
• Prevent fraud and keep our shop secure (our legitimate interest in protecting our business and customers)”

Why it works: each purpose is paired with a legal basis, which GDPR Article 13 requires, and the legitimate interest is named rather than left vague. The purposes are written in everyday language that matches what the shop visibly does.

Policies for audiences outside Europe often present purposes without legal bases, which is fine where no such requirement applies. If you serve EU or UK users, however, this pairing is one of the most frequently missing elements in policies built from generic templates. The GDPR privacy policy guide explains each basis.

Example wording: “We share information only with providers that help us run the shop:

• Our payment processor, to take payments and prevent fraud
• Our e-commerce platform, which hosts the shop and stores order records
• Our email provider, to send order emails and our newsletter
• Our analytics provider, if you consent to analytics cookies
• Couriers, to deliver your parcel

We do not sell your personal information. Some providers are based in the United States; where information is transferred outside the European Economic Area, we rely on the European Commission's standard contractual clauses or another lawful safeguard.”

Why it works: recipients are grouped by role, and each has a reason. The transfer statement names the safeguard, which the GDPR requires when data leaves the region. Many real policies name each provider individually; that is helpful when readers may want to read the provider's own policy.

The weak version, “We may share data with trusted third parties”, is one of the most common phrases in poor policies. It answers none of the questions a reader or regulator would ask.

Example wording: “We use essential cookies to run the basket and checkout. With your consent, we also use analytics cookies to measure which pages are visited. You can accept or reject analytics cookies in the banner when you first visit and change your choice at any time using the Cookie settings link in the footer.”

Why it works: it separates essential from optional cookies, states that optional ones depend on consent, and tells users exactly where to change their choice. Most importantly, it matches what the consent banner actually does. A policy that says analytics runs only with consent, on a site where analytics loads immediately, is a contradiction regulators and users can spot.

If you use many tracking technologies, a table listing each cookie, its provider, purpose, and duration can sit in this section or in a separate cookie policy linked from it. Some tools also have contract requirements; the Google Analytics terms, for example, ask you to disclose your use of the service. For analytics-specific wording topics, see the analytics privacy disclosures guide.

Example wording: “We keep:

• Order and invoice records for six years, to meet our tax record-keeping obligations
• Newsletter details until you unsubscribe
• Customer service emails for two years after your last message
• Analytics data for 14 months, after which it is deleted automatically”

Why it works: the GDPR requires either a retention period or the criteria used to set one, and this example gives specific periods with reasons. Readers can see that nothing is kept indefinitely, and the shop has a clear rule to follow internally.

The numbers in the example are illustrative for a fictional shop. Your own periods should come from your actual legal obligations, your provider settings, and your business needs. Where a fixed period is not possible, describe the criteria instead, such as “for as long as your account is open and for a limited period afterwards to resolve disputes.”

A weak retention section says “We keep data as long as necessary.” Without criteria, that sentence does not tell anyone anything and does not meet the GDPR's requirement.

Example wording: “You have the right to access, correct, or delete your personal information, to object to or restrict certain processing, to receive your information in a portable format, and to withdraw consent at any time. To make a request, email [email protected]. We may ask you to confirm your identity before we act. You also have the right to complain to the Data Protection Commission in Ireland or the data protection authority where you live.”

Why it works: it lists the rights that apply to the shop's audience, gives one simple route to use them, explains verification, and names the supervisory authority, which the GDPR requires.

If your audience includes Californians and your business meets the CCPA thresholds, this section expands to cover the rights to know, delete, correct, opt out of sale or sharing, and limit the use of sensitive personal information, plus how you handle opt-out preference signals and authorized agents. The CCPA regulations list each required element. Other regions add their own rights, which is why a Privacy Policy generator that selects regional modules from your answers can save time compared with editing a fixed template.

Example wording: “Our shop is intended for adults. We do not knowingly collect personal information from children. If you believe a child has given us information, contact us and we will delete it.

We will update this policy when our practices change. If we make significant changes, we will email customers and newsletter subscribers before the changes take effect.

Effective date: 1 March 2026. Last updated: 1 March 2026.”

Why it works: the audience statement is short and honest, the change process describes direct notice rather than asking people to check back regularly, and both dates are shown. CalOPPA requires an effective date and a description of how users are notified of material changes, and the CCPA regulations require the date the policy was last updated.

If your service is directed to children under 13 in the United States, this short statement is not enough; COPPA requires a dedicated notice with specific content. For guidance on when and how to announce updates, see how often you should update your privacy policy.