Introduction
A privacy policy is the cornerstone document that tells website visitors exactly how you collect, use, store, and share their personal data. Under GDPR Articles 13 and 14, this is not optional for any website that processes personal data from individuals in the European Union—and virtually every public website does, even if only through server logs and contact forms.
The UK GDPR, the ePrivacy Directive, and an expanding array of national implementations all build on the same core transparency obligation: give people meaningful information about what happens to their data at the point you collect it. A privacy policy achieves this by translating your actual data processing operations into plain language that ordinary users can understand.
Yet most privacy policies fail this test. Generic templates downloaded from the internet describe how a fictional company processes data, not how your stack of marketing tools, analytics platforms, payment processors, and hosting providers actually behaves. When policy language diverges from observable website behavior, regulators treat the notice as misleading rather than absent—which can be worse.
This guide covers every section GDPR demands in a privacy notice, explains the transparency rules that shape how you write them, identifies the common errors that invite enforcement, and shows practical examples of how compliant policies handle the hardest sections. Run a free scan on your site to see which signals your live privacy policy currently emits.
What a GDPR Privacy Policy Must Include
Article 13 GDPR lists the information you must provide when you collect personal data directly from the individual—which is the standard web scenario. Article 14 covers situations where you obtain data indirectly, such as purchasing marketing lists. The required elements are largely the same.
Think of the required elements not as a checklist to satisfy once but as a live inventory of your processing activities. Every time you add an analytics tag, switch email providers, or integrate a new ad platform, your policy must reflect the change before or at the same time the new processing begins.
- Controller identity and contact details: your company name, registration number, registered address, primary contact email, and a named data controller if different from the business entity. If you are required to appoint a Data Protection Officer or EU Representative, include their contact details here. Users need a real person or reachable address, not a contact form that routes to an unmonitored queue.
- Purposes of processing: a complete list of why you process data. Marketing analytics, user account management, fraud prevention, customer support, transaction processing, legal compliance, A/B testing, ad targeting—each distinct purpose requires its own disclosure. Do not bundle unrelated purposes under vague language like 'improving our services.'
- Lawful bases for each purpose: map each purpose to one of the six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interests). Marketing cookies and ad pixels almost always require consent. Account management and purchases use contract. Fraud detection often qualifies for legitimate interests with a documented balancing test.
- Categories of personal data: specify what types of data you actually collect—name, email, IP address, device identifiers, location data, payment card details, browsing history on your site, support conversation transcripts. Be specific enough that users understand the scope when they submit a form or load a page.
- Recipients and categories of recipients: name the third parties that receive personal data. This includes cloud hosting providers, email marketing platforms, analytics vendors, advertising networks, payment gateways, customer support tools, CRM systems, and subprocessors. Where naming specific vendors is impractical, describe categories and commit to keeping a processor list available on request.
- International transfers: if any recipient is based outside the EEA—and most US SaaS vendors are—disclose the transfer, identify the legal mechanism (Standard Contractual Clauses, adequacy decision, Binding Corporate Rules), and explain how users can obtain copies of the relevant safeguards. Google Analytics, Mailchimp, HubSpot, Salesforce, AWS US regions, and Stripe all trigger this section.
- Retention periods: state how long you keep each category of personal data, or the criteria used to determine retention. 'We keep data as long as necessary' without explanation does not satisfy Article 13. Acceptable alternatives: 'server logs deleted after 90 days,' 'account data deleted 30 days after subscription cancellation,' 'email list records deleted 12 months after last engagement.'
- Individual rights and how to exercise them: explain the rights to access, rectification, erasure, restriction of processing, data portability, objection, and withdrawal of consent. Provide a concrete mechanism—an email address, a support ticket form, or an in-product privacy dashboard. Include the right to lodge a complaint with a supervisory authority, and name the relevant national DPA.
- Automated decision-making and profiling: state whether you use any automated decisions with legal or significant effects. Many marketing sites can truthfully say none, but if you use scoring models, automated credit checks, or personalization algorithms that affect what users can access, disclose this under Article 22.
- Cookie and similar technology disclosures: if you use cookies, pixel tags, local storage, or device fingerprinting, describe the categories, purposes, and how users can control them. This section may cross-link to a dedicated cookie policy for detail on individual cookies and durations.
The GDPR Transparency Standard
Article 5(1)(a) requires personal data to be processed lawfully, fairly, and transparently. Transparency is an independent obligation—it is not satisfied by merely having consent or another lawful basis. A site running Google Analytics under consent is still non-compliant if the privacy policy does not mention Google Analytics.
The transparency standard under Recital 39 and Articles 12–14 has three layers:
Layer 1 — Clarity
Concise, transparent, intelligible: information must be given in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. Legalese that accurately describes your processing but is incomprehensible to an ordinary user fails this standard.
Layer 2 — Timing
Timely delivery: information must be provided at the time data is collected, not buried in a sign-up confirmation email or accessible only through a support ticket. A footer link to the privacy policy satisfies this for general website tracking because the policy is accessible before and during the session.
Layer 3 — Accuracy
Accuracy: the policy must describe what you actually do, not what you might do, what you used to do, or what an aspirational version of your company does. Listing vendors you removed three years ago, or omitting a pixel you added last month, both fail the accuracy requirement.
The practical implication is that transparency compliance is an ongoing operational task. Your privacy policy is essentially a public data flow diagram—every tool that touches personal data from your site needs to appear in it, and that list changes whenever your marketing stack, analytics configuration, or hosting setup changes.
Enforcement bodies have cited outdated or inaccurate privacy notices in cases where consent banners appeared technically correct but the supporting documentation was stale. An auditable update history—showing last-reviewed date alongside the last-updated date—signals operational diligence.
Required Sections: A Practical Template
The following structure covers all Article 13/14 requirements and is organized in the order users expect. Each section heading is paired with guidance on what specific language regulators scrutinize.
- Who we are (Controller Identity): Start with your legal entity name, trading name if different, company registration number, registered address, country of incorporation, and a privacy-specific contact email. If you have an EU Representative (required for non-EU controllers who must designate one under Article 27), list them separately with their contact details. Example: 'The data controller is Example Ltd, registered in England and Wales (No. 12345678), 1 High Street, London, EC1A 1AA. Privacy enquiries: privacy@example.com'
- What data we collect and why (Purposes and Lawful Bases): Use a structured format—a table works well—mapping each processing activity to the categories of data involved, the purpose, and the lawful basis. Separate marketing analytics (consent) from service delivery (contract) from fraud prevention (legitimate interests). Avoid umbrella statements.
- How long we keep your data (Retention): List retention periods by data category. Use concrete durations wherever possible. Where you rely on criteria rather than fixed periods, explain the criteria. Example: 'Transaction records: 7 years for accounting compliance. Abandoned shopping cart data: 30 days. Marketing contact records: 3 years from last engagement or until deletion requested.'
- Who we share data with (Recipients): List processors and controllers who receive data from your site. Group by category if needed. For advertising networks where the recipient list is dynamic, describe the categories and commit to maintaining a current sub-processor list. For each recipient, note whether they receive data as a processor (under your instructions) or as a controller in their own right.
- International transfers: For each recipient outside the EEA, name the country, state the transfer mechanism, and provide a link to the relevant Standard Contractual Clauses or adequacy decision. A single paragraph covering 'our US-based SaaS providers' with a link to the European Commission's SCC page satisfies the disclosure requirement even if it lacks granular vendor-by-vendor breakdown.
- Your rights (Data Subject Rights): List all eight rights, explain any applicable limitations (for example, the right to portability applies only to consent-based or contract-based processing), and give a single clear method of exercising each. State the response timeline—typically one month with a possible two-month extension—and include the supervisory authority complaint route.
- Cookie information: Even if you have a separate cookie policy, include at least a summary here. Describe cookie categories (strictly necessary, analytics, marketing), that you use a consent management platform, that users can withdraw consent at any time through the banner or preferences link, and cross-link to the full cookie policy.
- Changes to this policy: State how you will notify users of material changes. Common approaches: email notification to registered users for significant changes; a prominent banner on the updated policy page; version history section. Avoid language implying that continued use of the site constitutes acceptance of policy changes—this is a dark pattern under GDPR.
A privacy policy structured this way will satisfy Article 13 requirements for most standard website scenarios. Complex processing activities—employee monitoring, large-scale profiling, sensitive health data—require additional detail and specialist review.
Common Mistakes That Invite Enforcement
Regulators across EU member states have identified recurring patterns in privacy policy failures. These are the mistakes that appear most frequently in formal decisions, warning letters, and reprimands.
- Using a US-law template without GDPR adaptation: California CCPA templates and generic American privacy policies do not include lawful bases, DPO contact requirements, EU supervisory authority information, or Article 22 profiling disclosures. They describe rights under US law, not GDPR rights. Starting from a US template and adding GDPR sections often produces contradictory documents.
- Claiming only 'necessary cookies' are used while ad pixels fire pre-consent: this is the most commonly cited mismatch. Scanners load the page as a new visitor and record network requests. A policy saying we only use cookies necessary for the functioning of this site while Google Ads conversion pixels fire on page load is a materially false statement. Fix the policy or—preferably—fix the tracking.
- Listing the company entity while dozens of ad tech vendors receive data: stating 'we do not sell your data' while sending identifiers to dozens of real-time bidding participants does not meet transparency requirements. Disclosure of recipients must cover the actual recipients, including advertising supply chain intermediaries.
- Missing or unreachable contact details: a privacy form that requires a user account to submit, a support@domain email shared with general support, or a DPO email that auto-replies with ticket creation and no substantive response within 30 days all fail the accessibility requirement.
- No international transfer section despite using standard SaaS tools: almost every company using US-hosted Google Workspace, AWS, Mailchimp, HubSpot, or Stripe transfers data to the US. Omitting the transfer section when these tools are active is a straightforward compliance gap.
- Generic retention language: 'we retain data for as long as necessary for the purposes described' without specifying those purposes and their retention criteria is insufficient. Regulators have found this language provides no meaningful transparency.
- Outdated policy not reflecting current tools: a policy with a 2021 last-updated date that does not mention ChatGPT-powered customer support, a recently integrated Intercom widget, or a Facebook Pixel added during a campaign launch is factually inaccurate.
- No process behind the published rights mechanism: listing privacy@yourdomain as the contact for erasure requests but having no internal workflow to act on those requests creates liability when the first request arrives. The policy is the public face of an obligation that requires operational infrastructure.
- Failing to distinguish processors from controllers in the recipients section: your email marketing platform acting under your instructions is a processor; a data broker you share data with for their own marketing is a joint controller or separate controller. The legal relationship affects whether you need a DPA and what rights users have against each party.
- Burying the policy or breaking the footer link after a site redesign: the policy must be easily accessible. A broken link detected by a compliance scanner fails the visibility test even if the policy itself is excellent.
How Compliant Websites Handle Difficult Sections
Certain sections of privacy policies are consistently written poorly because the underlying legal analysis is genuinely difficult or because the accurate disclosure would be commercially uncomfortable. Here is how leading-practice sites handle them.
Analytics tools — what good looks like
Rather than a vague 'analytics' entry, map the tool specifically: 'We use Google Analytics 4, operated by Google LLC (US). Legal basis: consent. Data collected: page views, session duration, approximate location (city-level), device type, IP address (anonymized). Retention: 14 months in GA4. Transfer mechanism: Standard Contractual Clauses. Users can withdraw consent via the cookie preferences link in the footer.' This level of specificity satisfies Article 13 requirements and gives users actionable information.
Advertising and retargeting — what good looks like
Advertising retargeting is the hardest section to write honestly because the recipient list includes dynamic ad exchanges. A practical approach: 'We work with advertising partners including Meta Platforms and Google to show relevant advertisements. These partners may set cookies and receive identifiers that enable cross-site tracking for advertising purposes. This processing requires your consent. You can opt out or manage preferences in the cookie settings below or through [link]. A current list of our advertising partners is available at [link].' The commitment to a live partner list with a real URL handles the dynamic-recipient problem.
International transfers — what good looks like
For a typical bootstrapped SaaS: 'We transfer personal data to the United States in connection with the following services: email (Mailchimp, operating under SCCs), payments (Stripe, operating under SCCs and participating in the EU-US Data Privacy Framework), infrastructure (AWS us-east-1, operating under SCCs). Where Standard Contractual Clauses are the transfer mechanism, you can obtain a copy by contacting privacy@example.com.' This disclosure covers all transfers in three sentences.
Retention periods — what good looks like
Avoid language like 'we keep your data for as long as necessary.' Instead: 'We retain your account data for the duration of your active subscription plus 60 days following cancellation to enable account recovery, then delete it permanently except for financial transaction records required by tax law (7 years). Email marketing list data is deleted 24 months after your last click or open, or immediately upon unsubscribe.' Specific periods reduce uncertainty and set measurable internal obligations.
The common thread in compliant disclosures is specificity. Vague language often feels safer to legal teams because it commits to less, but under GDPR, vagueness is a failure mode, not a safe harbor. Transparent specificity builds user trust and reduces the risk that a regulator characterizes your notice as inadequate.
How GDPRChecker Helps With Privacy Policy Compliance
GDPRChecker approaches privacy policy compliance from both directions: what your policy says, and what your live site actually does.
The public compliance scanner detects whether a privacy policy link is present on your homepage and flags its absence in scan reports. It also checks whether the link is accessible, correctly labeled, and not broken—the three most common visibility failures that appear in regulatory complaints.
When you manage a site through GDPRChecker's dashboard, the legal pages workflow lets you configure and host your privacy policy URL, verify that the live site exposes the link you declared, and keep Article 13 visibility tied to your setup progress. This closes the gap between what you publish and what visitors can reach.
The compliance score reflects policy visibility as one of its weighted signals. A missing or inaccessible privacy policy link will suppress your score regardless of how well your consent banner performs—because transparency is an independent requirement, not a subset of consent.
Beyond link detection, the scanner identifies the tracking technologies active on your site—including ad pixels, analytics tags, and third-party embeds—and surfaces discrepancies between observed behavior and what a standard privacy notice would need to disclose. If your site loads five advertising pixels but your policy mentions only analytics, the gap is visible in scan findings.
When runtime protection and consent categories change, re-running scans keeps your compliance score and policy discovery status aligned with what visitors actually experience. Operational programs that scan after each marketing or deployment change catch policy drift before complaints do.