To create a GDPR compliant privacy policy, write a privacy notice that truthfully describes how your website processes personal data end to end. Start by listing every data-collection point and every vendor that touches that data, then align your policy with your consent experience, recipients, retention approach, and a clear path for privacy requests. Update it whenever your tools, purposes, or tracking change.
A GDPR-ready privacy notice (often called a "privacy policy") is defensible only when it accurately describes how you actually process personal data from end to end. Drop the checkbox mindset. Treat the notice as a public statement of operational truth you can prove with screenshots, settings, and records.
A privacy notice is a public document that explains how an organization processes personal data. Transparency - plainly telling people what you do with their data - sits at the core of GDPR. Articles 12, 13, and 14 spell out how that notice should work.
Before you start: open your website, list every place you collect data (forms, email capture, checkout), and every third party that touches it (analytics, CRM, payments). If you handle personal data of people in the EU, GDPR applies regardless of where you're based.
Step 1: Define responsibilities. Get clear on what you decide internally versus what vendors do on your behalf before you write. This is where generator outputs often drift.
Step 2: Make the notice match reality. Your data collection list, your vendor list, and your consent experience should tell the same story. If the banner offers choices but the notice reads like unconditional tracking, you have built a trust trap.
Step 3: Pressure-test defensibility. Use this quick gut-check:
| If your policy says... | You must be able to show... |
|---|---|
| "We collect X for Y." | The exact form fields/events and the purpose. |
| "We share with vendors." | Who receives it and why (no vague buckets). |
| "We respect your rights." | A real request path and who handles it. |
Keep the stakes in view: GDPR fines can reach €20 million or up to 4% of global revenue (whichever is higher). Your goal is not perfection. It is alignment you can defend.
If you want a deeper dive, read GDPR for Freelancers: A Step-by-Step Compliance Checklist for EU Clients.
Do a fast routing test: match each tool on your site to the right document so your privacy notice describes reality instead of guesswork. This keeps you from stuffing every promise into one page, then forgetting which promises you made.
Step 1: Separate the stack. These documents can all touch privacy, but they do not do the same job.
| Artifact | What it does | What it should cover |
|---|---|---|
| Privacy notice | Explains how you process personal data | Your data collection, purposes, recipients, user rights pathways |
| Cookie consent banner / cookie policy | Manages and explains tracking choices | What tracking exists and what choices users can make |
| Terms of Service | Sets the contract rules | Payment terms, refunds, liability, acceptable use |
Step 2: Confirm scope in plain English. Use your tool list to decide whether you touch EU personal data. If you do, stop treating GDPR as theoretical - treat it as operational.
Step 3: List your modules (the stuff that creates obligations). Do not start drafting until you can point to each module on your site:
Step 4: Output a clause plan you can execute. Write one line per module: tool → what data → why → who receives it → what the user can do about it. Examples:
Verification point: you should be able to trace every sentence in your privacy notice back to a real module or vendor. If you cannot, delete the sentence.
Build your inputs first - inventory, vendors, and retention, because your notice cannot stay truthful without a system behind it. This step turns your site map into records you can maintain when tools and workflows change.
| Retention criterion | Example from the article |
|---|---|
| Default rule | no longer than reasonably necessary for the purpose |
| Purpose completion | until the purpose completes |
| Account status | until account closes |
| User action | until the user unsubscribes |
| Legal requirement | as required for tax/legal obligations |
Before you start: treat every system that holds names, emails, identifiers, or logs as personal data territory.
Most people try to write the document first and then reverse-engineer the facts to match. Flip that. When your inputs are right, the writing gets easier, shorter, and more consistent because you are not reinventing your data story in every paragraph.
Step 1: Create a data inventory you can actually run. Do not aim for perfect coverage on day one. Aim for traceability. You should be able to answer: where did we get this, why do we still have it, and how do we delete it?
| Data touchpoint | Purpose | System of record | Who can access | Deletion trigger |
|---|---|---|---|---|
| Contact form | Reply + qualify | Email inbox / CRM | You (+ delegated admin) | Request resolved + no follow-up need |
| Newsletter signup | Send updates | Email platform | You | Unsubscribe request |
| Booking form | Schedule calls | Booking tool | You | Booking completes + no further need |
If you keep this inventory lightweight, you will actually use it. If it turns into a compliance artifact that lives in a folder nobody opens, your notice will drift the next time you add a tool.
Step 2: Create a vendor register (so you stop guessing in disclosures). List each vendor you use - analytics, email, payments, forms, embeds - and record:
The point is not to sound sophisticated in your public language. The point is that, internally, you have one place to look when you need to update the recipients section, the transfers paragraph, or your cookie disclosure.
Step 3: Decide "who's responsible for what" per activity. Your role can change depending on the workflow and jurisdiction. Sometimes you decide the purpose and how the data is used. Other times you handle data on someone else's instructions.
Write the decision down for each workflow so your legal documents stay consistent. This also helps you avoid contradictory language like calling yourself a processor in one paragraph and writing like a controller everywhere else.
Step 4: Draft a retention schedule with safe, defensible logic. Use "no longer than reasonably necessary for the purpose" as your default. If you fall under regimes that require retention disclosure, you may need to publish either the retention length or the criteria you use to determine it.
Write criteria you can defend (e.g., "until the purpose completes," "until account closes," "until the user unsubscribes," "as required for tax/legal obligations"). The retention schedule is not just a sentence for the notice. It is your internal rulebook for when you delete, archive, or restrict access.
Verification point: pick one tool, like your email platform or CRM, and prove you can (1) find the data, (2) explain why you have it, and (3) delete it when the purpose ends.
Related: Data Controller vs. Data Processor: What's the Difference for a Freelancer?.
Articles 12-14 tell you how to disclose. Use them as a clause stack: one tight set of statements you can reuse across every data-collection path on your site. This is how your notice becomes coherent instead of copy-pasted.
The operator move is to write once, then reuse with discipline. If you have ten modules on your site, you do not want ten different ways of describing the same vendor, the same purpose, or the same rights pathway.
Step 1: Write an identity block that removes ambiguity. Make it obvious who runs the operation and how to reach you.
Step 2: Build a purpose-by-purpose disclosure table. Do not bury the truth in paragraphs. Use a table you can maintain, and treat it as the source of truth for the rest of the document.
| Purpose | Personal data category | Where it lives | Recipients (vendors) | Retention approach | Contact / questions |
|---|---|---|---|---|---|
| Reply to inquiries | Contact details, message content | Inbox / CRM | Email provider, CRM | "No longer than necessary" criteria | How to reach you about privacy |
| Send newsletter | Email address, preferences | Email platform | Email vendor + listed subprocessors | Until unsubscribe (plus suppression logic) | How to reach you about privacy |
| Deliver services | Client contact + project data | Client files / tools | Required service vendors | Contract + business need criteria | How to reach you about privacy |
Step 3: Include (or at least clearly surface) the complaint pathway. Tell people how they can raise a concern.
Under GDPR, a data subject has the right to lodge a complaint with a supervisory authority if they consider processing infringes the GDPR, including in the Member State of habitual residence, place of work, or place of the alleged infringement. The authority must inform the complainant about the progress and outcome.
Step 4: Add a security statement without bravado. Describe protections you actually run (access control, account hygiene, sensible encryption where appropriate). Avoid sweeping claims you cannot prove.
Verification point: a stranger should understand what you do with their data in one pass. Your table should match your vendor register line-for-line.
Pick a clear legal basis per purpose, then keep the proof you'd want if someone challenged it. This anchors why you're allowed to do it so your notice reads like a system, not a collage of legal phrases.
Start with your purpose list, then choose the basis that matches how your business actually runs.
| Purpose (plain English) | Common operator default | What "proof" looks like in practice |
|---|---|---|
| Deliver the service | Contract | Signed agreement + scope + onboarding emails |
| Send a newsletter | Consent (often used; basis depends on your setup) | Subscribe flow description + unsubscribe path |
| Keep tax/accounting records | Legal obligation (where applicable) | Invoice trail + retention notes |
| Security + basic admin | Legitimate interest | A short note explaining why you need it + what you do with the data |
Definition: Consent is only one of six GDPR legal bases. Contract, legal obligations, vital interests, public interest, and legitimate interest exist for a reason. Use them.
If you rely on legitimate interest, add one row you can defend:
| Element | What to include |
|---|---|
| Interest | what you're protecting or improving (security, fraud prevention, basic administration) |
| Impact | what data you touch and how intrusive it feels |
| Choice | how someone can reach you if they have concerns or requests |
| Balance | why your interest outweighs the impact in your setup |
You do not need a perfect paragraph. You do need to be able to explain, out loud, why you chose this basis for this purpose in your specific setup.
For anything you run on consent (a common approach for newsletters/marketing), describe the user experience in human terms:
Avoid vague lines like "you can withdraw anytime" if you have not actually built a withdrawal path that works. Your notice should describe the mechanics you have, not the mechanics you intend to build later.
If you use tracking or retargeting tools, do not bury that. Describe what you use in plain language. Explain what it means for data collection.
Verification point: if you cannot explain the purpose → basis → proof chain in 30 seconds, your legal documents are not operational yet.
Treat your cookie banner as an operational gate: it should inform users and capture valid consent before you set non-essential cookies. This is where site compliance usually breaks, because the UI says one thing and the tags do another.
Choose the simplest setup you can live with, then align your tags and disclosures to that choice.
| Analytics lane | What you do | What your policy must match |
|---|---|---|
| Minimal measurement | Use low-data, aggregate metrics | A plain statement of what you collect and why |
| Full analytics | Use a strong analytics stack | Clear disclosure of tracking and consent handling |
| No analytics | Don't run analytics tags | Say you don't use analytics cookies (if true) |
A cookie banner is the visible part of a broader consent setup. Treat it like a switchboard that routes tracking on purpose, not by accident:
Keep your cookie list tight. Do not promise categories or controls you do not enforce.
In one short block, connect the dots:
If you maintain a separate cookie policy page, point to it for the detailed cookie list.
Consent expectations vary by region. EU jurisdictions tend to enforce strict opt-in regimes, while other regions (including the United States) rely more on opt-outs. If you serve multiple regions, do not guess. Configure your consent experience to match where the user sits.
Verification point: open your site in a fresh browser and confirm your data collection behavior matches what your legal documents say.
You might also find this useful: The Best Cookie Consent Tools for GDPR Compliance.
List every third party that touches personal data in plain English, then keep your paperwork and settings aligned with that list. The goal is not to impress anyone. It is to avoid two common failure modes: naming vendors you do not use anymore, and hiding vendors you do use behind generic phrases.
A good recipients section reads like an accurate map. A bad one reads like a template. Your vendor register keeps you out of template land, especially when your stack changes mid-year and you forget to update the notice.
Open the list of tools that handle customer emails, payments, forms, scheduling, video, analytics, and support. If you do not have a register yet, your recipients section will drift fast because you will be writing from memory.
Readers do not care about buzzwords. They care about who receives their data and why.
Use a simple format you can maintain:
| Recipient category | Example you might use | Examples of data that may be involved |
|---|---|---|
| Payment processor | Stripe (example) | Billing contact details, transaction metadata |
| Email provider | Mailchimp (example) | Email address, subscription preferences |
| Analytics provider | Google Analytics (example) | Usage events, device/browser signals |
If you do not use a category, do not list it. If you do, name it. This keeps your disclosure specific without forcing you into paragraphs that try to cover every possible tool you might adopt later.
If a vendor processes personal data on your behalf, keep the agreement and admin proof within reach, where required or available. This is an operations problem, not a writing problem.
The point is not to hoard documents. The point is to avoid scrambling when a client, a partner, or a regulator asks how your stack is governed.
Embedded tools may collect device and usage data as soon as the page loads. Common examples: a scheduling widget, a form embed, or a video player.
Treat embeds as modules you need to account for, not as design elements. If it runs code, it can create a data flow.
Any new SaaS tool should trigger three updates: your vendor register, a quick cookie/tag review, and the relevant paragraph in your legal documents.
Verification point: you should be able to point to one place that answers "who receives what, and why" without hand-waving.
Assume international transfers until you prove otherwise, then describe safeguards in plain language you can back up. This is one of the easiest places to overpromise, because people reach for broad statements that sound safe but do not match what they have actually verified.
Your job here is simple: make sure your public language reflects what you know today, and make sure your internal records show how you decided what to say.
Do not guess. Add a Transfers column to your vendor register and default it to "Possible" until you verify it. That one word keeps you honest while you do the work.
Many website tools can run on global infrastructure. If you use a SaaS for email, payments, or analytics, treat that as a transfer risk by default.
This is not about panic. It is about not writing "we never transfer" when your stack makes that hard to defend.
Use one consistent line of reasoning per vendor, not one vague paragraph for everything.
| Mechanism you can reference | When you'd use it | What you store in the register |
|---|---|---|
| Recognized legal route under your applicable law | You're relying on a specific legal pathway your regime allows | Notes on what you relied on + last-reviewed date |
| Contractual protections | You need contract terms to cover cross-border processing | Link/location of the addendum + acceptance proof + last-reviewed date |
| Other documented transfer arrangement | You operate under another set of jurisdiction-specific obligations | The signed/accepted transfer docs + last-reviewed date |
The register is what makes this maintainable. Without it, you will keep rewriting your transfers paragraph every time you change an analytics setting or swap a vendor.
Write one tight paragraph that stays true even when your stack changes:
Verification point: you should be able to answer "which vendors involve transfers, and what safeguard covers each one" without scrambling.
Build a small DSAR (privacy request) and retention system you can run on command, then document it inside your privacy policy (as applicable to your jurisdiction). This turns compliance from "we posted a page" into "we can execute the promises on that page."
A notice is public. Execution is private. The gap between them is where risk lives. Your goal is to close that gap with a workflow that is boring, repeatable, and easy to prove after the fact.
Choose a single inbox (or contact route) for privacy requests and assign an owner (even if that's just you). Consistency beats speed, because consistency produces a reliable audit trail.
Create a simple playbook you can follow when someone asks to access, delete, or correct their data.
| Playbook item | What you define | What you keep as proof |
|---|---|---|
| Intake | Where requests go + how you confirm receipt | A short acknowledgement template |
| Identity check | What you verify before sharing anything | A checklist of verification steps |
| Search locations | Where you look (email, client system, form submissions, billing records) | A "places searched" log line |
| Response | How you package the answer (summary + exports when available) | A response template |
| Deadline tracker | How you track due dates and status | A single tracker row per request |
Verification point: you can show what you did, when you did it, and what you shared.
Turn your retention schedule into recurring work, not a paragraph you never act on:
The system wins when you can do the same cleanup work even in a busy month. If your retention plan only works when you have free time, it is not a plan.
Add a "Last updated" line plus a 3-bullet changelog (new tool, new purpose, new recipient). Then tighten collection so fewer requests become emergencies:
A changelog is not just for the reader. It is for you, six months from now, when you are trying to remember why the policy mentions a tool you barely use.
Publish your privacy notice after you run a short gates checklist that confirms your public statements match your actual setup. This prevents the clean-document failure mode: a polished page that drifts from reality.
The gates are simple on purpose. You are not trying to create legal theater. You are trying to make sure the notice, the website behavior, and your internal records stay in sync.
Your privacy notice and any related user-facing disclosures, like consent UX, preference centers, and tracking/analytics configuration, should tell the same story about data collection.
| Item | What you verify | Pass looks like |
|---|---|---|
| Privacy notice vs. consent UX (if used) | Words match behavior | Same categories, purposes, and plain-language explanations |
| Consent UX vs. implementation | Controls match what actually runs | Choices are reflected in what loads/collects, where applicable |
| Disclosures vs. reality | Listings reflect actual tools/vendors | No phantom tools; no missing ones |
Instead of rereading the whole notice like a novel, scan it like an operator:
| Check | What should match |
|---|---|
| Identity block | who you are and how to contact you about privacy |
| Purposes | described in a way that maps back to real modules on your site (contact form, newsletter, booking, checkout, embeds) |
| Recipients | match your vendor register (category plus named example, not vague buckets) |
| Retention | stated in defensible criteria, not promises you cannot keep |
| Concerns | clearly explain how someone can raise concerns, including the complaint pathway |
| Tracking | the banner behavior matches what you say happens in the notice |
This gate is "Articles 12-14 discipline" in practice: clear, findable disclosures that match the way your site actually processes data.
Make sure your controller/processor language matches your agreements and the reality of who is doing what.
When processing happens "on behalf of" a controller, GDPR Article 28 points to:
This post does not force a fake calendar schedule, but your stack will change anyway. Pick a cadence you will actually follow, put it on the calendar, and rerun your gates.
Also set a practical trigger: when you add a tool, add a new form, change your analytics setup, or start a new marketing workflow, do not wait for the next review. Update the register and then update the public language that depends on it.
Verification point: if your processing changes in practice, revisit your public notice (and your Article 28 contract posture) so your words still match reality.
If you want to turn this into a repeatable process instead of a one-time edit, grab a few lightweight templates and trackers you can reuse on your chosen cadence: Browse Gruv tools.
Your privacy notice has one job: be clear, complete, and true to how you actually process data. The General Data Protection Regulation (GDPR) took effect on May 25, 2018. It can impose obligations on organizations anywhere if they target or collect data related to people in the EU.
Start with scope before you touch a privacy policy generator.
Verification point: you should be able to explain, in one sentence, why your website setup falls in or out of GDPR scope.
A privacy notice is a public document that explains how you process personal data. Transparency, informing people how their data is used, sits at the core of GDPR's intent.
Write like a human, not like generator output:
Verification point: a reasonable reader should understand your data collection without emailing you.
Do not promise perfection. Promise discipline.
| Change trigger | What usually shifts | What your policy should reflect |
|---|---|---|
| New purpose for existing data | Why you process data | Updated explanation of processing |
| New recipient/vendor | Who receives data | Updated recipient descriptions |
| New tracking or identifiers | What you collect | Updated personal data + use description |
Verification point: your public statements should match reality. GDPR can carry serious consequences, with fines described as up to 4% of global revenue or €20 million, whichever is higher.
Once your notice is in place, the next risk is messy operations as you grow, especially when money moves across borders. If you want a more controlled way to collect and pay out (with compliance gates and audit-ready records where supported), explore Gruv Merchant of Record for freelancers.
A GDPR compliant privacy policy should clearly explain how you handle personal data (information that relates to a person, like names, email addresses, and IP addresses) across your site and operations. In practice, that means it reflects what you actually do when you process data (collection, storage, transmission, analysis, etc.). It should help people understand and exercise their privacy rights.
If you process personal data of people in the EU, you need to comply with the General Data Protection Regulation (GDPR) even if your business sits elsewhere. That can include processing via tracking on your website. If you don't operate within the EU and you're not processing personal data of people in the EU (for example, you're only processing data for domestic purposes), some guidance says GDPR may not apply-scope still depends on what you process and who it relates to.
Treat them as related communications, not labels you can hide behind. What matters is clear, plain-language disclosure that matches your real processing.
The sources here don't give a single "must-include" website checklist. At a high level, your policy should explain what personal data you process (including identifiers like IP addresses) and what you do with it (processing). It should also explain how people can exercise the privacy rights the GDPR requires you to facilitate.
Don't pretend you have one magic list that never changes. Build disclosures from your vendor register and keep them aligned with reality.
This draft doesn't support a yes/no rule or specific conditions for Google Analytics. Use a safe operator approach: treat analytics as processing, verify what data flows out (including identifiers like IP addresses), and make your disclosures and controls match what actually fires.
The sources here don't state a single required update schedule, so don't optimize for a fake calendar deadline. Update when your processing changes (new tools, new purposes, new data collection). Keep a review cadence you will actually follow.
Maya writes about data privacy in plain English-what to do, what to avoid, and how to build trust with clients handling sensitive data.
Priya specializes in international contract law for independent contractors. She ensures that the legal advice provided is accurate, actionable, and up-to-date with current regulations.
Includes 4 external sources outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Start by separating the decisions you are actually making. For a workable **GDPR setup**, run three distinct tracks and record each one in writing before the first invoice goes out: VAT treatment, GDPR scope and role, and daily privacy operations.
Start with the boundary that matters. The materials you already have may settle some VAT decisions, but they cannot, on their own, settle your final GDPR role. That does not make them useless. It means you should separate what is already decidable from what still needs GDPR-specific text, contract language, and legal review before any processing begins.
Choosing among cookie consent tools is a compliance control decision, not just a design choice. You are deciding how consent is collected, managed, and documented while client work keeps moving.