# How to write a privacy policy, step by step

> Write a privacy policy from your actual data practices. Follow nine steps covering data, providers, rights, publication, and a final checklist.

Published 2026-10-09 by Jitoma Solutions s.r.o. · 11 min read

Write your privacy policy from a list of the personal data your product actually handles. Explain what you collect, why you use it, who receives it, how long you keep it, and how people can exercise their rights. Then publish it at a public URL and link it where you collect data. The nine steps below take you from that inventory to a policy you can check before publishing.

Canonical URL: https://legalpolicygenerator.com/blog/how-to-write-a-privacy-policy

## Key takeaways

- Start with a data inventory of every form, tool, and provider; your policy can only be as accurate as that list.
- Write specific purposes, recipients, retention periods, and request routes instead of vague catch-all wording.
- Add only the regional sections your audience triggers, such as GDPR, CCPA, CalOPPA, or COPPA.
- Publish at a stable link in your footer, forms, app, and store listings, then review it whenever your product changes.

## Step 1: Inventory the personal information you collect

Create a working list of the personal data your product handles. For each item, record where it comes from, what you use it for, which provider receives it, and when you delete it. Walk through the product as a user, then check the administration screens and integrations for collection that visitors cannot see:

- Forms: contact, sign-up, checkout, support, and job applications
- Accounts: email address, name, password hash, profile photo, and settings
- Automatic collection: server logs with IP addresses, cookies, SDKs, and crash reports
- Third-party inputs: sign-in with Google or Apple, payment confirmations, and advertising audiences
- Content users create: messages, uploads, reviews, and prompts sent to AI features

For each row, record the **data category**, the **source**, and the **tool** that touches it. Do not forget invisible collection: embedded videos, web fonts loaded from a third party, and chat widgets can all transmit IP addresses. If you are unsure what a script does, read the provider's documentation or watch the network tab in your browser's developer tools. This inventory becomes the backbone of every later step, so it is worth an extra hour.

## Step 2: Map each purpose and legal basis

Next, write down **why** you use each data category. Typical purposes are providing the service, managing accounts, processing payments, answering support requests, sending newsletters, measuring usage, preventing fraud, and advertising. Keep purposes specific: “to improve our services” on its own tells a reader very little, while “to see which pages visitors read so we can fix confusing content” is honest and concrete.

If anyone in the European Economic Area or the United Kingdom uses your product, GDPR Article 13 also asks you to state the **legal basis** for each purpose, such as contract, consent, legal obligation, or legitimate interests, and to name the legitimate interests you rely on. A short mapping in your notes keeps the policy consistent:

- Newsletter emails: consent
- Order fulfilment and receipts: contract
- Fraud prevention and security: legitimate interests
- Tax and accounting records: legal obligation

Only list purposes you actually pursue today. A purpose you might add someday belongs in a future update, not in today's notice.

## Step 3: List every provider that receives data

Readers and regulators want to know **who else receives the data**. Go through your inventory and list every service provider: hosting, content delivery, email delivery, analytics, payments, customer support, error tracking, advertising, and AI model providers. For each one, note whether it acts only on your instructions, as a processor or service provider does, or also uses the data for its own purposes, as many advertising networks do.

Your policy should describe the categories of recipients and, where it helps the reader, name the providers themselves. Some provider contracts expect specific wording. The Google Analytics terms, for example, require you to post a privacy policy that discloses your use of Google Analytics and how it collects and processes data, and the [analytics disclosure guide](https://legalpolicygenerator.com/resources/analytics-privacy-disclosures) explains what that section usually covers.

Also record **where** each provider processes data. If information leaves the European Economic Area or the UK, the GDPR expects you to mention the transfer and the safeguard relied on, such as an adequacy decision or standard contractual clauses.

## Step 4: Decide retention periods and security wording

Two questions trip up many first drafts: **how long** you keep data and **how** you protect it. For retention, the GDPR accepts either a fixed period or the criteria you use to decide one. Practical examples look like this:

- Account data: kept while the account is open and deleted within a set period after closure
- Billing records: kept for the period tax and accounting law requires
- Support emails: kept for a defined period after the ticket closes
- Analytics data: kept for the retention period configured in your analytics tool

For security, describe your real measures in general terms, such as encryption in transit, restricted staff access, and prompt software updates. Avoid absolute promises like “your data is completely safe”. No system is immune to breaches, and an overstated security claim is exactly the kind of statement that becomes a deceptive practice if something goes wrong. Write what you do, not what you hope to do.

## Step 5: Work out which privacy laws apply to you

Your audience, not only your company's location, decides most of the regional content. Ask three questions: where are your users, what do you collect, and how large is your business?

- **EU or UK users**: GDPR and UK GDPR transparency items, including legal bases, transfers, and the right to complain to a supervisory authority. The [GDPR privacy policy guide](https://legalpolicygenerator.com/laws/gdpr-privacy-policy) lists them.
- **California visitors**: CalOPPA requires a conspicuously posted policy from any commercial website or online service that collects personally identifiable information from California residents, with no size threshold. The CCPA adds detailed disclosures for businesses that meet its thresholds; the [CCPA and CPRA guide](https://legalpolicygenerator.com/laws/ccpa-cpra-privacy-policy) walks through them.
- **Other US states**: comprehensive privacy laws now exist in many states, each with its own thresholds and opt-out rights.
- **Children**: a service directed to children under 13 in the United States triggers COPPA notice and parental consent rules.
- **Canada, Brazil, Australia, New Zealand**: each has its own openness or transparency duties.

Include only the modules that apply. Adding every law “just in case” creates contradictions, such as promising request processes you do not actually run.

## Step 6: Explain privacy rights and how to use them

A privacy policy is also an instruction manual for people who want to **exercise their rights**. For each region you serve, list the rights that apply and explain exactly how to use them: an email address that someone monitors, a web form, or an in-app setting.

Under the GDPR that includes access, rectification, erasure, restriction, portability, objection, withdrawing consent, and complaining to a supervisory authority. Californians dealing with a business covered by the CCPA have the rights to know, delete, correct, opt out of the sale or sharing of personal information, and limit the use of sensitive personal information, and the CCPA regulations ask for a general description of how you verify requests.

**Test the route before you publish.** Send a request to your own privacy address, check that it arrives, and decide who answers it and how quickly. A rights section that points to an unmonitored inbox is worse than useless, because it tells readers the policy is not maintained and leaves real requests unanswered.

## Step 7: Write in plain language people can scan

GDPR Article 12 asks for information in a **concise, transparent, intelligible and easily accessible form, using clear and plain language**. That is good advice for every audience, and a few habits make even a long policy readable:

- Start with a short summary of the most important points
- Use descriptive headings people can scan, such as “Who we share data with”
- Prefer “we” and “you” to “the Company” and “the Data Subject”
- Replace vague words like “may” and “certain” with specifics wherever you can
- Use lists for data categories and a table for retention periods
- Add a table of contents with anchor links when the policy is long

Read the draft aloud. If a sentence needs a second pass to understand, rewrite it. Plain language is not about being casual; it is about making sure a reader leaves knowing what actually happens to their information. For real wording patterns, the [privacy policy examples guide](https://legalpolicygenerator.com/blog/privacy-policy-examples) walks through annotated snippets section by section.

## Step 8: Publish the policy where people expect it

Publish the policy on a **stable, public URL** and link it wherever people make decisions about their data. Common locations include:

- The footer of every page of your website
- Sign-up, checkout, and newsletter forms
- The settings or about screen inside your app
- Your App Store Connect and Google Play Console listings

App stores have specific rules. Apple guideline 5.1.1(i) requires a privacy policy link in the App Store Connect metadata field and within the app in an easily accessible manner. Google Play requires a link in Play Console and inside the app, on an active, publicly accessible, non-geofenced URL, and it does not accept PDFs. CalOPPA requires the policy to be conspicuously posted, and the CCPA regulations expect a conspicuous link that uses the word “privacy” on your homepage or app download page. For layouts that work on real sites, see [where to put a privacy policy link](https://legalpolicygenerator.com/blog/where-to-put-a-privacy-policy-link).

## Step 9: Keep the policy accurate after launch

A privacy policy is a living document. Show an **effective date** at the top, which CalOPPA requires, and keep a copy of every version you publish so you can show what users saw at any point. Review the policy whenever you:

- Add or remove a tool, SDK, or provider
- Start collecting a new data category or using data for a new purpose
- Launch in a new country or US state
- Add AI features, advertising, or payments
- Change how users exercise their rights

Businesses covered by the CCPA must update the required California information at least once every 12 months under Civil Code section 1798.130(a)(5), so put an annual review in your calendar even if nothing seems to have changed. For material changes, tell users directly instead of quietly editing the page. The full process, including notice wording, is in [how often you should update your privacy policy](https://legalpolicygenerator.com/blog/how-often-should-you-update-your-privacy-policy).

## Privacy policy checklist before you publish

Run through this checklist before the policy goes live:

1. The operator's legal name, contact email, and postal address where required are correct
2. Every data category in your inventory appears in the policy, and nothing extra does
3. Every purpose is specific, with a legal basis if EU or UK users are in scope
4. Every recipient category is listed, including analytics and advertising tools
5. International transfers and their safeguards are described where relevant
6. Retention periods or the criteria for them are stated
7. Rights, request methods, and verification are explained for each region you serve
8. Cookie and tracking choices match what your consent banner actually does
9. Children's data, sensitive data, and AI features are addressed if present
10. The effective date is set and previous versions are archived
11. The link appears in your footer, forms, app settings, and store listings

If you would rather not assemble all of this by hand, the [Legal Policy Generator](https://legalpolicygenerator.com/privacy-policy-generator) asks these questions in plain language and selects versioned clauses based on your answers. The questionnaire and full preview are free and need no account, so you can compare its output with your own checklist.

## Common questions

### Can I write my own privacy policy?

Yes. No law requires a lawyer to draft a privacy policy, and many small businesses write their own from a careful data inventory. What matters is that it is accurate and covers the items required by the laws that apply to you. For high-risk processing, such as health data, children's services, or large-scale tracking, have a qualified lawyer review the final text.

### How long should a privacy policy be?

As long as it takes to describe your actual processing and no longer. A simple brochure site might need a page or two, while an app with accounts, payments, analytics, and advertising needs considerably more. Use a short summary, clear headings, and a table of contents so readers can jump straight to the part they care about.

### What is the difference between a privacy policy and a privacy notice?

In everyday use they mean the same public document. Some regulators and lawyers use “privacy notice” for the explanation given to users and “privacy policy” for internal rules on handling data. What counts is the content: the public text must explain what you collect, why, who receives it, how long you keep it, and what rights people have.

### Do I need a privacy policy if I only use Google Analytics?

Usually yes. The Google Analytics terms require you to post a privacy policy that discloses your use of Google Analytics and of cookies, mobile identifiers, or similar technology. Online identifiers can be personal data under the GDPR, and CalOPPA applies when a commercial site collects personally identifiable information from California residents.

### Is a privacy policy generator good enough?

A generator is a solid starting point when it asks about your real practices and only includes clauses that match them. Legal Policy Generator, for example, selects versioned clauses deterministically from your answers. It is not legal advice, so complex or high-risk processing still benefits from a lawyer's review. See [are free privacy policy generators safe](https://legalpolicygenerator.com/blog/are-free-privacy-policy-generators-safe) for what to check.

## Official sources

- [Regulation (EU) 2016/679 (GDPR), official EUR-Lex text](https://eur-lex.europa.eu/eli/reg/2016/679/oj)
- [ICO: What privacy information should we provide?](https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/the-right-to-be-informed/what-privacy-information-should-we-provide/)
- [California Business and Professions Code § 22575 (CalOPPA)](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=BPC&sectionNum=22575)
- [California Civil Code § 1798.130 privacy policy disclosures](https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?lawCode=CIV&sectionNum=1798.130.)
- [Apple App Review Guidelines, 5.1.1 Data Collection and Storage](https://developer.apple.com/app-store/review/guidelines/#privacy)
- [Google Play User Data policy](https://support.google.com/googleplay/android-developer/answer/10144311?hl=en)
- [Google Analytics Terms of Service](https://marketingplatform.google.com/about/analytics/terms/us/)

Generated wording reflects supplied facts. It is not legal advice or a guarantee of compliance or enforceability.