Your privacy policy is the most public artifact of your compliance program. It's the first thing a regulator reads, the first thing a data subject checks before filing a complaint, and increasingly, the first thing a business partner reviews during due diligence.
Yet most privacy policies are either copied from templates without customization, written by marketing teams focused on reassurance over accuracy, or so outdated they describe processing activities the organization stopped years ago.
Here's what the GDPR actually requires.
The Legal Foundation: Articles 13 and 14
GDPR Article 13 applies when you collect data directly from the data subject (forms, sign-ups, purchases). Article 14 applies when you receive data from another source (data brokers, public databases, business partners).
Both articles specify mandatory disclosures. Missing any of them is a compliance gap, and regulators have fined organizations specifically for incomplete privacy notices.
Mandatory Elements
1. Controller Identity and Contact Details
State who is responsible for the data:
- Full legal name of the organization
- Physical address
- Contact email or phone number
- Data Protection Officer (DPO) contact details, if you've appointed one
Avoid generic references like "we" without identifying the legal entity. If a group of companies shares data, each controller must be identified.
2. Purposes and Legal Bases
For every type of data you collect, state:
- What you collect (name, email, IP address, payment details, etc.)
- Why you collect it (service delivery, marketing, analytics, legal obligation)
- Which legal basis applies (consent, contract, legitimate interest, legal obligation)
If you rely on legitimate interests, you must describe the specific interest. "Business purposes" is not specific enough.
3. Data Recipients and Transfers
Disclose:
- Categories of third parties who receive personal data (cloud providers, analytics services, payment processors, advertising partners)
- Whether data is transferred outside the EEA
- The safeguard mechanism for international transfers (adequacy decision, standard contractual clauses, binding corporate rules)
You don't need to name every processor, but the categories must be specific enough for a data subject to understand who handles their data.
4. Retention Periods
For each category of data, state how long you keep it. Acceptable approaches:
- Specific time periods: "We retain account data for 2 years after account closure"
- Criteria for determining the period: "We retain transaction records for the duration required by tax law in your jurisdiction"
"We retain data as long as necessary" without further specificity fails the transparency requirement.
5. Data Subject Rights
List all applicable rights:
- Right of access (Article 15)
- Right to rectification (Article 16)
- Right to erasure (Article 17)
- Right to restriction of processing (Article 18)
- Right to data portability (Article 20)
- Right to object (Article 21)
- Rights related to automated decision-making (Article 22)
- Right to withdraw consent (Article 7(3))
For each right, explain how to exercise it. A dedicated email address or request form is standard. State the expected response time (one calendar month under GDPR).
6. Consent Withdrawal
If any processing is based on consent, explain that consent can be withdrawn at any time, without affecting the lawfulness of processing before withdrawal. Withdrawal must be as easy as giving consent — if consent was a single click, withdrawal should be too.
7. Right to Complain
Data subjects have the right to lodge a complaint with a supervisory authority. Identify the relevant authority, or at minimum, state that they can complain to the authority in their country of residence.
8. Automated Decision-Making
If you use automated processing that produces legal or similarly significant effects (credit scoring, automated hiring decisions, insurance risk assessment), disclose:
- The existence of such processing
- Meaningful information about the logic involved
- The significance and envisaged consequences
- The right to human intervention
9. Source of Data (Article 14 Only)
When data wasn't collected from the individual directly, disclose where it came from and whether it came from publicly accessible sources.
10. Obligation to Provide Data
State whether providing personal data is a statutory or contractual requirement, and the consequences of not providing it. For example: "You must provide your email address to create an account. Without it, we cannot provide the service."
Common Mistakes Regulators Flag
Vague Language
"We may share your data with partners" — who? For what purpose? Under what legal basis? Vague statements invite complaints and enforcement.
Missing Cookie Disclosures
Your privacy policy must cover cookies and tracking technologies, including analytics and advertising cookies, with reference to how to manage consent. Many organizations have a separate cookie policy — fine, but it must be linked from the main privacy policy.
Out-of-Date Information
A privacy policy that references a system you stopped using or a processor you terminated two years ago undermines credibility. Review and update annually at minimum.
Inaccessible Language
The GDPR requires privacy notices to be "in a concise, transparent, intelligible and easily accessible form, using clear and plain language." Legal jargon that requires a law degree to parse fails this standard.
Single Policy for Everything
Employee data, customer data, and website visitor data have different processing activities, legal bases, and retention periods. A single undifferentiated policy for all audiences is difficult to make compliant. Consider separate notices for distinct audiences.
Structuring Your Privacy Policy
A well-organized privacy policy typically follows this structure:
- Who we are — Controller identity, DPO contact
- What we collect and why — Data categories, purposes, legal bases (table format works well)
- Who we share it with — Processor categories, third-party recipients
- International transfers — Countries, safeguard mechanisms
- How long we keep it — Retention periods per data category
- Your rights — List of rights with exercise instructions
- Security — High-level description of protective measures
- Cookies — Overview or link to cookie policy
- Updates — How changes are communicated, effective date
- Contact and complaints — DPO, supervisory authority
Keeping It Current
A privacy policy that was accurate when written but hasn't been updated in a year is a liability. Build a review process:
- Annual review: Check every section against current practices
- Trigger-based updates: New system, new processor, new data type, new jurisdiction — update the policy
- Version tracking: Maintain a record of when changes were made and what changed
- Notification: If material changes affect data subjects, notify them proactively
The point isn't to have a perfect document. It's to have an accurate one that reflects what you actually do with personal data. Regulators can tolerate imperfect language. They cannot tolerate misrepresentation.