How to Audit Your Privacy Policy for GDPR: A Step-by-Step Guide

Right now, 25 European data protection authorities are running parallel investigations into how organisations communicate data processing practices to individuals. The EDPB formally designated transparency and information provision — Articles 12, 13, and 14 of GDPR — as its 2026 coordinated enforcement priority. That means every DPA across the EU is checking privacy notices, not as a side activity, but as an assigned compliance campaign.

GDPR fines have surpassed €7.1 billion across more than 1,400 decisions since 2018. The enforcement pattern from early 2026 is clear: regulators aren't just checking whether a privacy policy exists. They're evaluating whether it's actually effective — whether real users can understand what's happening with their data, and whether the notice reflects what the company is actually doing.

If you haven't audited your privacy policy against the specific requirements of Articles 12-14, this guide walks you through exactly how to do it.

What GDPR Actually Requires in a Privacy Notice

The confusion around GDPR privacy policies usually comes from conflating what you should communicate with what you're legally required to include. Articles 12, 13, and 14 are specific. Article 12 sets the standards for how information must be presented. Articles 13 and 14 list exactly what information must be included.

Article 13 applies when you collect data directly from individuals — a contact form, an account signup, a cookie. Article 14 applies when you obtained data from a third party — a data broker, a referral source, a public registry. Most companies only focus on Article 13, but if you enrich user data or purchase marketing lists, Article 14 requirements also apply.

Article 12 sets the format rules: information must be provided in a concise, transparent, intelligible, and easily accessible form, using clear and plain language. That last part is now being actively enforced. A policy written in dense legal prose that requires a law degree to parse doesn't satisfy the "intelligible" standard, even if every required data point is technically present.

The GDPR Privacy Policy Audit Checklist

Run through each item below against your actual privacy policy. The "required" items are non-negotiable under Article 13. The "conditional" items apply depending on how you process data.

Controller Identity and Contact Details

• ✓ Full legal name and registered address of the data controller
• ✓ Contact details for the data controller (not just a generic email)
• ! Name and contact details of the Data Protection Officer — required if you're a public authority, conduct large-scale systematic monitoring, or process special category data at scale
• ! EU representative details — required if you're established outside the EU but target EU residents

Purposes and Legal Basis

This is where most audits find the biggest gaps. Vague statements like "to improve our services" or "for marketing purposes" are no longer acceptable. Article 13(1)(c) requires you to state the specific purpose of processing AND the legal basis for each processing activity.

• ✓ Each processing activity has a stated purpose (specific, not generic)
• ✓ Each processing activity has an identified legal basis: consent, legitimate interests, contract, legal obligation, vital interests, or public task
• ✗ If legitimate interests is the legal basis: the specific legitimate interest is named — not just "our legitimate interests"
• ✗ If consent is the legal basis: the policy makes clear that consent can be withdrawn and how to do so

// FAILS — vague purpose with no legal basis
"We process your data to improve our services and for marketing purposes."

// PASSES — specific purpose + explicit legal basis
"We process your name and email address to send you transactional
order confirmation emails. Legal basis: performance of a contract
(Art. 6(1)(b) GDPR).

We process your email address to send you our monthly newsletter.
Legal basis: consent (Art. 6(1)(a) GDPR). You can withdraw consent
at any time by clicking 'Unsubscribe' in any newsletter email."

Recipients and Third-Party Sharing

• ✓ The policy lists categories of recipients, or names specific recipients, who receive personal data
• ✓ International transfers are disclosed — any transfer to a country outside the EU/EEA is flagged
• ! For international transfers: the transfer mechanism is specified (adequacy decision, Standard Contractual Clauses, Binding Corporate Rules, or derogation)
• ✗ If Standard Contractual Clauses are used: the policy references the 2021 SCCs, not the pre-2021 versions (which are no longer valid)

Retention Periods

Article 13(2)(a) requires you to state how long you'll keep personal data, or if that's not possible, the criteria you use to determine the retention period. "We keep your data as long as necessary" doesn't satisfy this requirement — it's circular and tells the reader nothing.

• ✗ Retention periods are specified for each data category — not a single blanket period for all data
• ! Where a fixed period isn't possible, the criteria for determining the period are explained (e.g., "for the duration of the contract plus 6 years for legal obligation purposes")
• ✓ Backup and archival retention is accounted for if it differs from live data retention

Data Subject Rights

• ✓ Right of access (Article 15) — explained and with a mechanism to exercise it
• ✓ Right to rectification (Article 16)
• ✓ Right to erasure / "right to be forgotten" (Article 17)
• ✓ Right to restrict processing (Article 18)
• ✓ Right to data portability (Article 20) — only required when processing is automated and based on consent or contract
• ✓ Right to object (Article 21) — especially important if you rely on legitimate interests or process for direct marketing
• ! Right to object to automated decision-making (Article 22) — required if you use automated profiling with legal or significant effects
• ✗ The policy explains HOW to exercise rights — not just that they exist. A rights page exists but no contact method is given? That fails.

Supervisory Authority and Complaints

• ✓ The right to lodge a complaint with a supervisory authority is stated
• ! The relevant supervisory authority is named — the DPA in the EU country where you're established, or where affected users are located

Article 12 — Presentation and Accessibility

This is the enforcement focus in 2026. It's not enough to have the right information — it has to be presented in a way real users can actually process.

• ✗ Plain language test: Could a non-lawyer understand this policy? The EDPB's 2026 enforcement action is specifically targeting policies that bury required disclosures in legalese.
• ✓ Conciseness: The policy doesn't pad required disclosures with repetitive legalese that obscures key information
• ✓ Accessibility: The policy is reachable in one click from every page that collects data — not buried in a footer link that goes to a 404
• ! Layered notice: For complex processing, a layered approach (short version + full version) is recommended by the EDPB to satisfy both conciseness and completeness simultaneously
• ✗ Date: The policy has a "last updated" date. Undated policies are a red flag in audits — they signal the policy hasn't been maintained.

Common Gaps That Trigger Enforcement

Based on the EDPB's published enforcement decisions and the pattern of fines issued in 2025 and early 2026, these are the gaps most likely to attract regulatory attention:

1. Vague or Generic Legal Bases

Claiming "legitimate interests" for every processing activity without explaining what the interest is, or using "consent" as a basis when users have no real choice, are both enforcement targets. The EDPB has been explicit that a legal basis must be specific to the processing activity.

2. Missing or Hollow Retention Periods

"We keep data for as long as necessary" appears in the vast majority of privacy policies that fail GDPR audits. It's circular. Regulators want to see actual periods — "3 years from last login," "7 years for financial records," "until you withdraw consent."

3. International Transfer Mechanism Not Specified

Using US-based SaaS tools — AWS, Google Analytics, Stripe, HubSpot, Intercom — means you're transferring EU personal data internationally. Each transfer needs a mechanism. Standard Contractual Clauses are the most common mechanism, but you need to name them. "We may transfer data internationally" without naming the safeguard is a gap.

4. Rights Stated But Not Actionable

A policy that lists the eight data subject rights but provides no email address, no web form, and no process for exercising them fails the effectiveness test. Article 12(2) requires you to facilitate the exercise of rights — not just acknowledge they exist.

5. The Policy Doesn't Match Actual Practice

This is the most serious gap. A privacy policy that claims you don't sell data when you use advertising pixels that technically share data with ad networks. A policy that says you retain data for 12 months when your database backups preserve it for 7 years. Regulators cross-reference privacy policies against actual data flows, and discrepancies are treated as evidence of bad faith.

The Audit Process: Step by Step

Here's the practical sequence for a manual GDPR privacy policy audit. Budget 3-6 hours for a first pass, depending on the complexity of your processing activities.

Step 1: Map Your Data Before Reading Your Policy

The most common mistake is auditing the policy in isolation. Start by mapping what personal data you actually collect, from whom, for what purposes, and who you share it with. Payments data, analytics cookies, support ticket data, newsletter subscribers, API authentication tokens — get it all on paper first.

Then read your policy against that map. Every data category and every processing activity in the map needs a corresponding disclosure in the policy. Anything in the policy that doesn't match your map is either fiction or outdated — both are problems.

Step 2: Check Each Article 13 Element Against the Checklist

Work through the checklist in this guide systematically. Don't scan; read every sentence. Pay particular attention to: legal bases (are they specific?), retention periods (are they real numbers?), international transfers (are the mechanisms named?), and rights (is there a way to exercise them?).

Step 3: Apply the Plain Language Test

Read the policy as if you're a customer who received a data breach notification and wants to understand what data you hold about them. Can they find it? Can they understand it? If the answer is no, the Article 12 standard isn't met, regardless of what's technically disclosed.

Sentence length:  Target <25 words average
Passive voice:    Flag "data may be processed" → who processes it?
Defined terms:   Define "we", "our", "the service" clearly at top
Nested clauses:  More than 2 levels of nesting → rewrite
Jargon check:   "Sub-processor" without definition → explain it
Headers:         Each Article 13 requirement should be findable in <30 seconds

Step 4: Check Accessibility

Navigate to your website as an unauthenticated user. Click "Sign up" or fill in any form that collects personal data. Count the clicks to your privacy policy. If it takes more than one click from the point of data collection, you have an accessibility problem under Article 12(1).

Check that the link in the signup flow goes to the current version of your policy, not a cached or outdated version. Verify the link doesn't 404 on mobile. These are basic checks that regulators do run.

Step 5: Document the Audit

Under Article 5(2), GDPR's accountability principle, you need to be able to demonstrate compliance. That means keeping a record of when you audited your privacy policy, what gaps you found, what you remediated, and who approved the changes. An undocumented audit is nearly as problematic as no audit at all when regulators come asking.

What's Different for US Companies Operating in the EU

If you're a US-based company with EU users, the same GDPR obligations apply — with a few additions. You need to appoint an EU representative (Article 27) if you're not established in the EU but process EU residents' data at scale or monitor their behavior. The representative's contact details go in the privacy policy.

You also need to ensure every tool in your stack that touches EU data has current SCCs or another valid transfer mechanism. "We use AWS EU-West" partially covers it — but your Intercom support chat, Stripe payments integration, HubSpot CRM, and any third-party analytics or advertising tools are also international transfers that need to be disclosed and covered.

The State Department's track record on maintaining Privacy Shield variants has been unstable. SCCs are the reliable mechanism — make sure your vendor agreements include the 2021 version.

Running the Audit Automatically

A manual audit following the steps above will catch the major gaps. For teams that need to run audits regularly — or who are checking compliance after a policy update, a new product feature, or entry into a new market — automating the process makes more sense.

PolicyAudit scans your privacy policy document against all GDPR Articles 12-14 requirements and returns a structured gap report with specific article references and remediation notes. It covers not just GDPR but CCPA, HIPAA, and other frameworks simultaneously — so you can check a single document against multiple applicable frameworks in one pass. The free tier is sufficient for most solo founders and small teams doing an initial assessment.

For organisations running formal compliance programs, tools like Drata provide continuous monitoring across your entire compliance posture — not just document auditing, but evidence collection, control testing, and audit preparation for SOC 2 and ISO 27001.