What a UK privacy policy must cover (UK GDPR + DPA 2018 basics)
A UK privacy policy should clearly explain how and why you use personal data, in line with the UK GDPR and the Data Protection Act 2018. At a minimum, include:
- Who you are: your business name, address (or registered office), and contact details. If you have a Data Protection Officer (DPO) or privacy contact, list them.
- What data you collect: e.g. names, emails, billing details, account logins, IP addresses, cookie IDs, and any special category data (only if relevant).
- Why you use it and your lawful bases: link each purpose to a lawful basis (contract, legal obligation, legitimate interests, consent, etc.). If relying on legitimate interests, summarise what those interests are.
- Who you share it with: processors and third parties (hosting, email, analytics, payment providers), plus whether they act as processors or independent controllers where applicable.
- International transfers: whether data leaves the UK, and what safeguards you use (e.g. adequacy regulations or standard contractual clauses).
- How long you keep data: retention periods or the criteria used to set them.
- Individuals’ rights: access, rectification, erasure, restriction, portability, objection, and rights around automated decision-making/profiling (if used).
- Complaints: how to complain to you and the ICO (include the ICO’s role and a link).
- Cookies/online tracking: signpost to a cookie policy and explain consent where required (note: cookie rules sit under PECR, alongside UK GDPR).
Before you copy the template: the details you need to collect (data map checklist)
A UK privacy policy template only works if it matches what you actually do. Before you paste anything, build a simple “data map” by collecting the details below (you can keep this as an internal checklist). If you’re unsure, note assumptions and verify with whoever runs your website, marketing, and customer support.
- Who you are: legal business name, trading name, registered address, contact email/phone, and (if applicable) company number.
- Your roles: are you a controller, joint controller, or processor for any activities (e.g., running campaigns for clients)?
- What personal data you collect: names, emails, phone numbers, postal addresses, payment details (usually via a payment provider), IP address, device IDs, cookie IDs, order history, support messages, and any special category data (typically avoid unless necessary).
- Where it comes from: website forms, checkout, account creation, newsletters, cookies/analytics, social media, referrals, offline enquiries.
- Why you use it (purposes): fulfil orders/services, account admin, customer support, marketing, fraud prevention, analytics, legal compliance.
- Lawful bases: contract, legal obligation, legitimate interests, consent (especially for non-essential cookies and some marketing), vital interests (rare).
- Who you share it with: hosting, email/SMS, CRM, analytics, ad platforms, payment processors, couriers, accountants, IT support.
- International transfers: any suppliers outside the UK; note safeguards (e.g., UK IDTA/Addendum) if used.
- Retention: how long each category is kept and what drives it (warranties, tax rules, dispute handling).
- Security: access controls, MFA, encryption, backups, staff training (describe at a high level).
- User rights & requests: how people can contact you, identity checks, typical response times.
Compliance note: this is practical guidance, not legal advice. If you process special category data, large-scale tracking, or sensitive profiling, consider a UK GDPR review and a DPIA.
UK privacy policy template (copy-and-edit) + annotated placeholders
Copy, then replace anything in [square brackets]. This is a general template for typical UK websites; it isn’t legal advice. If you process special category data, do large-scale tracking, or handle children’s data, get professional review.
Privacy Policy
Last updated: [DD Month YYYY]
1) Who we are (Controller)
[Business name] (“we/us”) is the data controller.
Address: [Registered/trading address]
Email: [Privacy contact email]
ICO registration (if applicable): [Z1234567]
2) What data we collect
- Identity/contact: [name, email, phone]
- Account: [login details] (if applicable)
- Technical/usage: [IP, device, pages viewed]
- Marketing preferences: [opt-in/opt-out]
- Payments: We do not store card details; payments handled by [PSP name]. [Adjust]
3) Why we use your data (purposes + lawful basis)
- Provide services/answer enquiries (contract/legitimate interests)
- Site security and fraud prevention (legitimate interests/legal obligation)
- Marketing emails (consent) [state method + double opt-in if used]
- Analytics/cookies (consent) [UK PECR]
4) Who we share data with
Service providers: [hosting], [email platform], [analytics], [CRM].
We require processors to protect your data. We may share if legally required.
5) International transfers
If data leaves the UK, we use safeguards like UK IDTA/UK Addendum. [Confirm]
6) Retention
We keep data for [X months/years] or as required by law, then delete/anonymise.
7) Your rights
Access, rectification, erasure, restriction, portability, objection, and withdraw consent.
Complain to the ICO: https://ico.org.uk/
8) Cookies
See our Cookie Policy: [link]. Manage consent via [cookie banner/tool].
9) Contact
Email: [privacy email] or write to [postal address].Annotated placeholders: [Controller] = the organisation deciding “why/how” data is used. [Lawful basis] must match each purpose. [PSP] = Stripe/PayPal/etc. [International transfers] only if tools/hosts are outside the UK. [Retention] should be specific and realistic.
How to tailor the template for common setups (SaaS, agencies, eCommerce, lead gen)
Edit the template by mapping what you collect, why you collect it, who you share it with, and how long you keep it. Be specific about categories (not just “data”). If you’re unsure, describe typical practice and confirm with your actual tooling. This is general information, not legal advice.
SaaS
- Account data: add username, email, password (hashed), billing contact, and role/permissions.
- Product usage: describe logs, device/IP, feature analytics, error reporting, and in-app messages.
- Processors: list hosting, email delivery, support desk, analytics, payments; note international transfers and safeguards if applicable.
- Retention: define how long you keep inactive accounts and backups.
Agencies
- Controller/processor roles: state when you act as a processor for clients and when you’re a controller for your own marketing.
- Client data: describe what you receive (customer lists, ad audiences), purpose, and secure handling.
- Sub-processors: include ad platforms, CRM, file storage, project tools.
eCommerce
- Orders: include delivery address, order history, returns, fraud checks.
- Payments: clarify you don’t store full card details if using a payment provider.
- Marketing: explain abandoned cart emails, loyalty schemes, and cookie-based tracking.
Lead generation
- Forms: list fields collected, qualification questions, and consent/legitimate interests basis.
- Sharing: name partners/buyers and how you notify users; include opt-out routes.
- Calls: disclose call recording and retention where used.
Cookies, analytics and marketing tracking: what belongs in the privacy policy vs cookie policy
In the UK, you usually need both a privacy policy and a cookie policy because they cover different legal duties. Your privacy policy explains how you process personal data under UK GDPR, while your cookie policy explains how you store/read information on a user’s device under PECR (and how consent works).
Put in your privacy policy:
- Who you are (controller details) and how to contact you (and DPO if you have one).
- What personal data you collect via tracking (e.g., online identifiers, IP address, device IDs, cookie IDs, inferred interests, page views linked to a user/profile).
- Purposes and lawful bases (e.g., consent for marketing cookies; legitimate interests may apply to some limited analytics depending on setup, but this varies).
- Recipients (analytics/ad platforms), international transfers, retention, and user rights (including how to withdraw consent).
Put in your cookie policy:
- A cookie list: name/provider, purpose, expiry, and category (strictly necessary, analytics, marketing).
- How consent is obtained (banner/CMP), how to change preferences, and whether cookies are set before consent.
- Details of similar technologies (pixels, SDKs, local storage) used for analytics/ads.
Practical rule: the cookie policy explains the technology and consent mechanism; the privacy policy explains the personal data processing that results. This is general information, not legal advice.
Lawful bases compared: consent vs legitimate interests vs contract (and when each fits)
Under the UK GDPR, you must pick a lawful basis for each processing purpose (e.g., taking orders, sending marketing, fraud prevention). The “best” basis depends on what you’re doing, who you’re dealing with, and what they reasonably expect.
Contract
Use contract when processing is necessary to perform a contract with the individual or take steps they request before entering one. Typical examples: creating an account, taking payment, delivering goods, providing customer support tied to the service. Don’t stretch this to cover optional extras (like marketing) just because someone is a customer.
Legitimate interests
Use legitimate interests when you have a genuine business need and the processing is proportionate, with limited privacy impact. Common examples: basic analytics to improve your website, network/security monitoring, preventing fraud, and some direct marketing (often for existing customers), provided you offer a clear opt-out. You should document a Legitimate Interests Assessment (LIA) and be ready to explain why your interests aren’t overridden by the person’s rights.
Consent
Use consent when people should have a real choice and control—especially for non-essential processing. Typical examples: email marketing to non-customers, placing non-essential cookies/trackers, or sharing data with third parties for their marketing. Consent must be freely given, specific, informed, and unambiguous, and it must be as easy to withdraw as to give.
Tip: For each purpose, state the lawful basis, what data you use, and the opt-out/withdrawal method (and any impact on the service).
Data processors and sub-processors: what to disclose and how specific to be
In a UK privacy policy, explain when you use data processors (suppliers who handle personal data on your instructions) and when those processors use sub-processors (their own suppliers). Disclose this so people understand who may handle their data, where it goes, and why.
Be specific enough to be meaningful, without listing every minor vendor if it would be inaccurate or constantly out of date. A practical approach is:
- Name key processors that are central to delivering your service (e.g., website hosting, email delivery, payment processing, customer support, analytics). Include the service type and purpose.
- Indicate locations (UK/EEA/non-UK) and, where relevant, that international transfers may occur. If you rely on safeguards such as the UK International Data Transfer Agreement or UK Addendum to the EU SCCs, say so (avoid legal over-promising).
- Explain sub-processing: state that processors may use approved sub-processors, bound by written terms and security obligations, and that you remain responsible for their processing under contract.
- Offer a stable method for details: link to a “sub-processor list” page or provide a contact email to request the current list. If you maintain a list, include the processor name, service, data categories (e.g., contact details, usage data), and country.
Only claim you have contracts, audits, or security measures if you actually do. This section is informational and not legal advice.
International data transfers (UK to US/EU): options and what to say in your policy
If you use suppliers outside the UK (common examples: US hosting, email marketing, analytics, customer support tools, or EU-based processors), UK GDPR requires you to explain when personal data is transferred internationally and what safeguards you rely on. In your policy, name the countries (or regions) you transfer to, describe the categories of recipients (e.g., “cloud hosting providers”), and state the lawful transfer mechanism you use.
Option 1: UK International Data Transfer Agreement (IDTA) (or Option 2: UK Addendum to the EU Standard Contractual Clauses). These are the most typical safeguards for UK-to-US/EU transfers where no UK adequacy decision applies. Policy wording should say you use “approved standard contractual protections” and that you may provide copies on request (redacted for confidentiality).
Option 3: Adequacy regulations. If the UK has recognised a country/territory as “adequate” (or you rely on a recognised framework where applicable), you can state transfers are protected because the destination provides an adequate level of protection. Keep this general unless you’re sure which adequacy basis applies to your vendors.
Option 4: Limited exceptions (e.g., explicit consent or necessary for a contract). These are narrower and should not be your default; if you rely on them, explain when and why.
Also state you carry out risk assessments and apply additional measures where appropriate (e.g., encryption, access controls, data minimisation). This section is informational and not legal advice; transfer requirements vary by vendor and data type.
Security, retention and breach handling: practical wording that won’t overpromise
Security (what you can safely say): Explain the measures you use without claiming “100% secure”. For example: “We use appropriate technical and organisational measures to protect personal data, including access controls, encryption in transit where available, secure hosting, and staff training. We limit access to personal data to those who need it for their role. No method of transmission or storage is completely secure, so we cannot guarantee absolute security.”
Retention (how to describe timeframes): Avoid vague “we keep data as long as necessary” without context. Use a rule-based approach: “We keep personal data only for as long as needed for the purposes set out in this policy, including meeting legal, accounting, or reporting requirements. Typical retention periods are: account and order records (up to 6 years for tax and contract purposes), customer support correspondence (up to 2 years), and marketing preferences (until you unsubscribe or we refresh consent). We may keep data longer if required to establish, exercise or defend legal claims.” Adjust the examples to match your business.
Breach handling (clear but not alarming): “If we become aware of a personal data breach, we will assess the risk to individuals and take steps to contain and remedy it. Where required by UK GDPR, we will notify the ICO without undue delay (and, where feasible, within 72 hours). If the breach is likely to result in a high risk to your rights and freedoms, we will also inform you without undue delay, describing what happened and the steps you can take.”
How to publish and maintain your privacy policy (placement, versioning, review cadence)
Placement: Publish your UK privacy policy where people expect to find it and where you collect personal data. Add a persistent footer link (“Privacy policy”) on every page, and link it at each data collection point: contact forms, newsletter sign-ups, account registration, checkout, and cookie banner settings. If you use apps or third-party forms (e.g., booking tools), include a direct link there too. For mobile apps, include it in the app store listing and in-app settings. Make sure the policy is accessible (no login required) and readable on mobile.
Versioning: Add a “Last updated” date at the top and keep a simple change log (e.g., “v1.3 – added new payment provider; updated retention periods”). Store previous versions (PDF export or archived web page) so you can evidence what users were told at a given time. If you materially change how you use data (new purposes, new sharing, new international transfers), consider notifying users by email or in-product notice where appropriate. This isn’t legal advice; notification requirements depend on context and your lawful basis.
Review cadence: Review at least annually, and also whenever you change: suppliers/processors, marketing tools, cookies/analytics, retention periods, security measures, or the categories of data you collect. Tie reviews to operational triggers (new vendor onboarding, website redesign, new product launch) and keep a short internal record of what you checked and what changed.
Privacy policy generators vs solicitor-drafted vs template: cost, risk and best fit
Privacy policy templates are the lowest-cost option (often free to low-cost) and can be a sensible starting point for a small UK site with simple data flows (e.g., contact form emails, basic analytics). The trade-off is risk: templates are generic, so it’s easy to miss key details such as your lawful bases, retention periods, international transfers, or processor disclosures. If the policy doesn’t match what you actually do, it can create compliance and reputational issues.
Privacy policy generators sit in the middle. They typically cost a small monthly or one-off fee and guide you through common scenarios (cookies, marketing emails, payment providers). They can reduce omissions compared with a static template, but they still rely on your inputs being accurate and complete. If your setup is unusual (multiple tracking tools, complex marketing, or B2B enrichment), a generator may oversimplify or produce wording that doesn’t reflect your real processing.
Solicitor-drafted policies are the highest-cost option (typically hundreds to thousands, depending on complexity) and best when risk is higher: e-commerce with multiple vendors, special category data, children’s data, regulated sectors, or frequent marketing and profiling. A solicitor can tailor the policy to your actual data map, advise on UK GDPR/PECR touchpoints, and align the document with your contracts and cookie consent approach.
Disclaimer: This is general information, not legal advice. Costs vary by scope and provider.
Privacy policy template UK FAQs (ICO, PECR, DSARs, children, B2B contacts, email marketing)
Do I need to register with the ICO?
Many UK organisations must pay the ICO data protection fee (often called “registering”), unless exempt. Whether you need to pay depends on what data you process and for what purpose. Check the ICO’s fee self-assessment and record the outcome in your compliance notes.
Does my privacy policy need to mention PECR?
If you use cookies, analytics, marketing tags, or send electronic marketing (email/SMS), PECR is likely relevant. Your privacy policy should explain tracking/marketing activities, and your cookie policy/banner should cover consent where required.
What should I say about DSARs (subject access requests)?
State how people can request access, correction, deletion, restriction, portability, or objection, and how you verify identity. Typical response time is one month, with limited grounds to extend. Avoid promising outcomes you can’t guarantee.
How do I handle children’s data?
Explain whether your service targets children. If you may collect children’s data, describe age checks/consent approach and safeguards. Consider the ICO’s Children’s Code if your online service is likely to be accessed by children.
Can I list B2B contacts under “legitimate interests”?
Often, yes—especially for relationship management and direct marketing to corporate addresses—but you should document a Legitimate Interests Assessment and always provide a clear opt-out. Some contexts may still require consent.
What about email marketing?
Explain your lawful basis (consent or “soft opt-in” where applicable), what you send, how often (if known), and how to unsubscribe. Keep your privacy policy aligned with your sign-up forms and preference centre.