Compliance guide
What Should a Privacy Policy Include?
A complete, enforceable privacy policy covers 9 specific areas. Most boilerplate misses three of them — and a policy that doesn't match your actual data practices creates more liability than having no policy at all.
- The 9 required sections
- Which laws require what
- Common mistakes that create liability
- Generate yours free
- FAQ
The 9 sections a privacy policy must cover
The intersection of GDPR (EU/UK), CCPA/CPRA (California), and CalOPPA (California, broader scope than CCPA) gives you the most demanding checklist you need to meet. Satisfy all three and you've covered the requirements most likely to apply to any public website with a global audience.
What personal data you collect
List the specific categories of personal information your site processes — not vague buckets like "usage data," but the actual types: email addresses, IP addresses, cookie identifiers, names, billing information, device type, browser type, pages visited, form inputs, payment details.
Be granular and accurate. If you use Google Analytics, you collect IP addresses and cookie identifiers regardless of whether you explicitly ask for them. If you have server-side logging (Vercel, Netlify, Render, most hosts), you log every request's IP address and user-agent. Omitting implicit collection is the most common accuracy problem in small-site policies.
Why you collect it — purpose and legal basis
For each category of personal data, explain the specific purpose: "email addresses to send transactional account notifications," "IP addresses and cookie identifiers to measure traffic using Google Analytics," "billing name and email from our payment processor to fulfill your order."
Under GDPR, you must also state the lawful basis for each processing activity. The bases most relevant to websites: contract performance (processing necessary to deliver what the user signed up for), legitimate interests (analytics, security logging — must be balanced against user rights), and consent (marketing email, non-essential cookies). Vague language like "to improve our services" is not a purpose — it is the output of a purpose, and it doesn't state a lawful basis.
Who you share it with — third-party processors
Name the specific third parties that receive personal data from your site and describe what they do with it. This section is the most frequently incomplete in boilerplate policies.
Common third parties that nearly every site has but many policies don't name: Google Analytics (or GA4, Plausible, Fathom, etc. — analytics provider), Stripe / PayPal / Lemon Squeezy (payment processor), Mailchimp / ConvertKit / Resend (email service), Vercel / Netlify / AWS (hosting provider who receives server logs), Intercom / Crisp / Tawk.to (live chat, sets cookies independently). Under CPRA (the 2023 update to CCPA), you must also disclose any "sharing" of personal data for cross-context behavioral advertising — which includes running Google AdSense or Facebook Pixel.
How long you keep it — retention periods
This is the section most commonly absent from small-site policies. GDPR Article 13(2)(a) explicitly requires you to specify the storage period for each category of personal data, or "where that is not possible, the criteria used to determine that period."
Practical examples of what this section should say: account data retained until the user requests deletion, server access logs retained for 90 days then automatically purged, marketing email addresses retained until the subscriber unsubscribes, support tickets retained for 3 years. Vague language like "as long as necessary" doesn't satisfy Art. 13(2)(a) — you need a specific period or a specific criterion tied to a business purpose.
User rights and how to exercise them
Privacy laws grant individuals specific rights over their personal data. Your policy must list the rights that apply and give users a clear method to invoke them — typically an email address for data requests.
Under GDPR, the rights are: access (receive a copy of your data), rectification (correct inaccurate data), erasure (the "right to be forgotten"), restriction of processing, data portability (receive your data in a machine-readable format), and objection to processing based on legitimate interests. Under CCPA/CPRA, the rights are: know, delete, correct, opt out of data selling or sharing, and limit use of sensitive personal information. You don't need to describe each right in legal prose — a short sentence per right and a contact email for requests is adequate for most small sites.
Cookie disclosure
If your site sets cookies — and virtually every site does, through analytics, login sessions, consent banners, or embedded third-party scripts — your privacy policy must disclose this. A separate cookie policy or cookie notice is common practice, but the main privacy policy must at minimum reference the cookie use and the types of cookies set (session, analytics, advertising, functional).
The ePrivacy Directive (EU) and UK PECR require informed consent before setting non-essential cookies — analytics and advertising cookies require an opt-in from EU/UK visitors, not just disclosure. This consent mechanism (a cookie banner with genuine choice, not a notice-only banner) is distinct from the privacy policy itself, but both are required. Your privacy policy should describe what cookies you set and link to or incorporate your cookie notice.
Contact information for the data controller
Your name (or company name) and a reachable contact method — typically an email address — for privacy inquiries and data requests. This is required under GDPR Art. 13(1)(a) as the identity of the data controller, and under CalOPPA as a mechanism for California residents to contact you about data practices.
GDPR also requires a Data Protection Officer for public authorities and for organizations whose core activities involve large-scale systematic monitoring or processing of special categories of data. Most small sites and indie apps are exempt from the DPO requirement, but the controller contact information is universally required. An email alias like privacy@yoursite.com is better practice than a personal email — it survives team changes and signals that you take privacy inquiries seriously.
Children's data statement
Your policy must state your site's relationship to data from children under 13 (COPPA, US) or under 16 (GDPR, though member states can lower this). The minimum statement for a site not targeting children is: "Our service is not directed to individuals under 13. We do not knowingly collect personal information from children. If we learn we have collected data from a child, we will delete it."
If your site could attract children or is directed at a general audience (not restricted to adults by design), this statement is legally required by COPPA and expected by both Apple and Google as part of app store submission requirements. A policy that omits any mention of children is incomplete for any site with a general-audience registration or public-facing content.
Last updated date and change notification
CalOPPA explicitly requires your privacy policy to include a date indicating when it was last updated, and to describe how you will notify users of material changes. Most policies satisfy this with a "Last updated: [date]" line at the top or bottom and a sentence like "We will notify registered users of material changes by email."
The date must be current — a policy last updated at launch while your site has since added analytics, a payment system, or user accounts is materially inaccurate. Update the date every time your data practices change, not just annually. GDPR Art. 13 implies the same obligation under the accuracy principle: a policy that was accurate at publication but is no longer accurate because practices changed is a transparency failure.
Which laws require which sections
Not all sections come from all frameworks — but if your site has any global traffic, both GDPR and CalOPPA/CCPA apply simultaneously. The table below shows which sections each framework requires:
| Section | GDPR (EU/UK) | CCPA/CPRA (CA) | CalOPPA (CA) | COPPA (US) |
|---|---|---|---|---|
| 1 · Data collected | ✓ Required | ✓ Required | ✓ Required | ✓ Required |
| 2 · Purpose & legal basis | ✓ Required | Partial (purpose only) | Partial (purpose only) | — |
| 3 · Third-party processors | ✓ Required | ✓ Required | ✓ Required | ✓ Required |
| 4 · Retention periods | ✓ Required | — (not explicit) | — (not explicit) | — |
| 5 · User rights | ✓ Required | ✓ Required | — (not explicit) | Partial (parental access) |
| 6 · Cookie disclosure | ✓ Required | Partial (if cookie data sold) | ✓ Required | ✓ Required |
| 7 · Contact information | ✓ Required | ✓ Required | ✓ Required | ✓ Required |
| 8 · Children's statement | If applicable | If applicable | If applicable | ✓ Required |
| 9 · Last updated date | Implied by accuracy | — | ✓ Required | — |
Common mistakes that create liability
A privacy policy that doesn't match your real data practices is legally worse than no policy at all — it adds a false representation claim on top of the underlying compliance failure. These are the errors that cause that mismatch:
- Copying a template without reviewing it against your actual integrations A boilerplate that says "we do not share personal data with third parties" becomes a false statement the moment you add Google Analytics, Stripe, or any third-party service. Audit every third-party script on your site before publishing. The browser Network tab and a tool like uBlock Origin's logger will show you everything loading on page.
- Omitting implicit data collection Most sites collect data they don't think of as "collection." Server-side logs from Vercel, Netlify, or AWS record every request's IP address and user-agent. Google Fonts makes a request to Google's servers, sending the visitor's IP. Third-party chat widgets set their own cookies. If it's on your page, it's your data processing obligation to disclose.
- Vague purpose language "To improve your experience" and "to provide our services" are not purposes under GDPR — they are outputs. A purpose specifies what processing achieves a specific goal: "to authenticate your identity when you log in," "to count page views and understand which features are used" (analytics). Vague language signals to regulators that you haven't actually thought through your data practices.
- Never updating the policy after launch A privacy policy dated at launch that has never changed while the site added user accounts, switched analytics tools, integrated a payment processor, or launched a newsletter is inaccurate. CalOPPA requires updates when data practices change. A "last updated" date more than 18 months old on a site that has clearly evolved is a red flag during enforcement and in due diligence reviews.
- Burying or hiding the policy link CalOPPA requires a "conspicuous" link to the privacy policy. A link in a sub-menu, an about page, or inside the legal section of a dropdown does not meet this standard. The policy must be linked from the footer of every page — this is the standard location, the one regulators look for, and the one users expect. Contact forms and signup forms must also link to the policy adjacent to the submit button.
Generate a policy that covers all 9 sections
ComplyKit generates a privacy policy from a short questionnaire that maps directly to the 9 sections above. You toggle on what your site actually does — which analytics tool you use, whether you have user accounts, which payment processor, which regions you serve — and each relevant clause is written in automatically. Sections that don't apply to your setup are excluded rather than left vague.
Every generated policy includes: data categories (pre-populated from your toggles), purpose and lawful basis per category, named third-party processors based on what you selected, retention guidance, a user-rights section for GDPR and CCPA/CPRA, cookie disclosure, your contact email, a children's data statement, and a last-updated date. Nothing is sent to a server — the entire document is built and downloaded in your browser.
Generate my privacy policy free →
Frequently asked questions
Does a privacy policy need to be written by a lawyer?
For most indie apps, side projects, and small business websites, a well-generated template that accurately reflects your actual data practices is a legitimate starting point — and what regulators primarily check is accuracy, not authorship. The risk is a mismatch: a template that says you don't use analytics when you have Google Analytics installed creates more liability than it removes. For complex situations — multiple regulated jurisdictions, sensitive data categories, regulated industries like healthcare or finance — have a qualified lawyer review before you publish.
What is the most commonly missing section in privacy policies?
Data retention periods. Most generated and boilerplate policies cover what data is collected and why, but omit specific retention timelines. GDPR requires you to specify how long each category of personal data is kept — or the criteria used to determine that period. Vague language like "we keep data as long as necessary" doesn't satisfy Article 13(2)(a). The other frequently missing section is the named third-party processors — a policy that describes data collection but doesn't list the specific tools in use is materially incomplete.
Can I use a privacy policy from another site or a template I found online?
Only if it accurately describes what your site actually does — which it almost certainly doesn't without modification. A policy copied from another site describes that site's data practices. If your site uses different analytics, payment processors, or collects different data, every discrepancy becomes a potential false representation. "We do not share personal data with third parties" copied from a minimalist site becomes legally dangerous the moment you add Google Analytics. Generate from your real data practices, not from someone else's.
What does "legal basis for processing" mean and do I need to include it?
Under GDPR Article 13, you must state the lawful basis for each type of data processing. The six bases are: consent, contract performance, legal obligation, vital interests, public task, and legitimate interests. For most websites: analytics typically relies on legitimate interests or consent (if using a consent banner); transactional email relies on contract performance; marketing email relies on consent. If your site has EU or UK visitors, you need to specify these. CCPA/CalOPPA don't require a "legal basis" per se, but they do require the "business or commercial purpose" for each data category — a closely related concept.
Do I need a "Do Not Sell My Personal Information" link?
Only if you "sell" or "share" personal data under CCPA/CPRA's definitions. For most small sites without third-party advertising, the answer is no. However, using Google AdSense, Facebook Pixel, or similar ad-network code can qualify as "sharing" personal data for cross-context behavioral advertising under CPRA — which requires an opt-out mechanism for California residents. If you run any third-party advertising, the safer approach is to include a "Do Not Sell or Share My Personal Information" link in your site footer.
How often does a privacy policy need to be updated?
Whenever your data practices change — adding a new analytics tool, switching payment processors, adding user accounts, expanding into a new region, or running ads for the first time. CalOPPA explicitly requires you to update the "Last updated" date whenever material changes are made, and many frameworks require notifying existing registered users of significant changes. The "last updated" date must reflect your current practices. A policy with a two-year-old update date on an actively evolving site is a red flag during enforcement reviews and legal due diligence.
Also in the Copper Bay Labs ship-safety suite
A complete privacy policy is one part of shipping safely. These free tools check for accessibility gaps, exposed secrets, and missing security headers — the other common pre-launch failure modes:
Checks your live site for accessibility and privacy-law gaps that attract ADA demand letters.
Secret scanning LeakCheckPaste code or a config file and see exposed API keys and tokens flagged before they reach the repo.
Security headers HardenCheckScan your live site's HTTP headers for missing CSP, HSTS, and other security hardening flags.
Post-deploy ExposureCheckScan your live URL for exposed .env files, .git directories, and bundled secrets.