UK GDPR Article 13 is the provision that lists what you must tell people when you collect their personal data directly from them. It is the legal foundation for most Privacy Policies. What is frustrating is that the Article itself is written in the dense, cross-referencing style of European legislation, and most people who need to write a Privacy Policy have no idea what they are actually required to include.

This guide translates Article 13 into plain English and adds the context that the bare text does not give you: what each requirement actually means in practice, what people commonly get wrong, and where the grey areas are.

Who you are: the controller identity requirement

Article 13(1)(a) requires you to give the identity and contact details of the data controller - the person or entity responsible for deciding how data is used. For most website operators, the controller is the business or the individual behind the site. You need to give your name (or your company name), your registered address if you have one, and at minimum an email address for data protection queries.

If you have a Data Protection Officer (DPO), you must include their contact details separately. Most small businesses do not need a DPO - the requirement applies to public authorities, organisations that carry out large-scale systematic monitoring, or those processing special category data at large scale. But if you have one, their details go here.

One thing people routinely omit: if you are not established in the UK but you are processing data about UK residents (because you sell to the UK market), you may need to name a UK representative. That representative's details also need to be in the policy. The same obligation exists under EU GDPR for those processing EU residents' data without an EU establishment.

Why you are collecting data and what legal basis you are using

Article 13(1)(c) requires you to state the purposes of the processing and the legal basis. These are two different things and both must be included. Purposes describe what you are doing with the data ("processing your order," "sending you our newsletter," "analysing website traffic to improve our service"). Legal basis is the UK GDPR justification for why you are allowed to do that.

The six lawful bases under UK GDPR are: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Most websites will rely on a mixture. Contract is used when you process data to fulfil an order or provide a service the person has bought. Consent is used for marketing emails and non-essential cookies. Legitimate interests is used for things like fraud prevention, security, and sometimes analytics - but it requires a balancing test and cannot be used as a catch-all for anything you find convenient.

Legitimate interests needs to be explained properly. It is not sufficient to state that you rely on legitimate interests without explaining what those interests are and why they override the individual's privacy rights. The ICO expects to see the balancing exercise reflected in your policy, even if briefly.

A common mistake is listing legitimate interests as the basis for email marketing. That does not work. Marketing to people who have not consented requires consent as the lawful basis. Legitimate interests can cover some marketing to existing customers under "soft opt-in" rules in PECR, but this is more limited than many businesses assume. For more detail on cookies and PECR, see our guide on cookie policy requirements under PECR.

Legitimate interests: what needs to go in the policy

If you are relying on legitimate interests as a lawful basis for any processing, Article 13(1)(d) requires you to state what those legitimate interests are. "To operate our business" is not specific enough. Something like "to prevent fraud and ensure the security of our platform" or "to improve our services by understanding how the website is used" gives more meaningful information.

You do not need to reproduce your full legitimate interests assessment in the policy, but you do need to name the interests you are relying on. This also matters practically: if someone objects to processing under legitimate interests (which is a right under Article 21), you need to have a clear enough articulation of those interests to respond meaningfully.

How long you keep data

Article 13(2)(a) requires either specific retention periods or the criteria used to determine them. This is one of the most commonly omitted or fudged elements. "We keep your data for as long as necessary" is not compliant - it is exactly the kind of vague non-answer the regulation is designed to prevent. You need to either state specific periods ("we keep order records for 7 years to comply with our accounting obligations") or explain what drives the decision ("we retain customer account data until you close your account, and then for 12 months in case of any outstanding queries").

Different categories of data often have different retention periods. Account information, financial records, marketing lists, and support tickets all typically have different appropriate retention windows. Getting this right requires actually thinking through what you keep and why, which most businesses have not done in any systematic way. The effort is worth it - being specific about retention is also good data hygiene, since data you do not need is also data you do not need to protect.

Who you share data with

If you share personal data with third parties, your policy must explain this. Article 13(1)(e) refers to recipients or categories of recipients. You have a choice: name specific recipients (Google Analytics, Stripe, Mailchimp) or describe categories (payment processors, email service providers, analytics providers). Both approaches are acceptable, but naming specific providers is more useful to users and tends to reflect better practice.

You also need to cover international transfers. If any of your data processors are outside the UK - which they likely are, given that most cloud services and SaaS tools are US-based - you need to explain this and state what safeguards apply. For transfers to the EU, the UK adequacy decision covers this. For transfers to the US and other countries, you will typically be relying on UK Standard Contractual Clauses (now called International Data Transfer Agreements) or binding corporate rules. State which mechanism applies.

Individual rights

Article 13(2)(b) through (d) require you to explain the rights that individuals have in relation to their data. In UK GDPR, these are:

The right of access (Subject Access Request) - individuals can ask you what data you hold about them. The right to rectification - they can ask you to correct inaccurate data. The right to erasure ("right to be forgotten") - in certain circumstances they can ask you to delete their data. The right to restrict processing - they can ask you to stop using their data in certain ways while a dispute is resolved. The right to data portability - they can ask for a copy of their data in a machine-readable format (this applies when processing is based on consent or contract and is carried out by automated means). The right to object - they can object to processing based on legitimate interests or for direct marketing.

You must explain all of these rights and tell people how to exercise them. In practice, this usually means providing an email address for data rights requests. You should also note that you will respond within one month (the UK GDPR deadline), and that you may need to verify the person's identity before processing their request.

Do not overstate the right to erasure. Many businesses either ignore this right or tell people they can always get their data deleted. Neither is correct. The right to erasure applies in specific circumstances - for example, if the data is no longer necessary, if consent has been withdrawn and there is no other lawful basis, or if the person objects and there are no overriding legitimate grounds. There are also exemptions, including for compliance with legal obligations. Be accurate about when the right applies.

The right to withdraw consent

If any of your processing is based on consent, Article 13(2)(c) requires you to tell people they can withdraw that consent at any time, and that withdrawal does not affect the lawfulness of processing that took place before withdrawal. In plain English: if someone previously agreed to receive your newsletter, they can unsubscribe and you must stop - but sending them previous emails was still lawful at the time.

The mechanism for withdrawing consent must be as easy as giving it. If people can sign up for your newsletter with one click, they should be able to unsubscribe with one click. A policy that talks about withdrawal of consent but makes it difficult in practice is a compliance problem.

The right to complain to the ICO

Article 13(2)(d) requires you to tell people about their right to make a complaint to the supervisory authority. In the UK, that is the Information Commissioner's Office (ICO). Include the ICO's website address (ico.org.uk) and note that people can make a complaint there if they believe their data protection rights have been infringed.

This is a small element of the policy but one that the ICO notices in its reviews. Omitting it is an easy mistake to fix and an unnecessary compliance gap.

Automated decision-making

If you use automated processes that make decisions with legal or similarly significant effects on individuals - credit scoring, automated fraud detection that blocks accounts, algorithmic pricing that materially affects what someone is offered - Article 13(2)(f) requires you to say so. You need to explain the logic, significance, and envisaged consequences of that processing.

For most small websites, this section can be brief or omitted entirely on the basis that no such processing takes place. If you do use it, though, it must be disclosed. Automated decisions made without the required transparency are one area where the ICO has been increasingly active.

Plain language: the requirement behind all the other requirements

Article 12 of UK GDPR requires that all information provided under Article 13 be "concise, transparent, intelligible and easily accessible," using "clear and plain language." This applies especially to any information directed at children.

What this means in practice: write in plain English, organise the policy so people can find what they are looking for, and do not hide important information in dense paragraphs. Headings, short sentences, and avoiding legal jargon where possible all contribute to compliance. The ICO has published guidance on this and has been clear that a technically complete but incomprehensible policy is still non-compliant.

If you are starting from scratch or updating an existing policy, our broader guide on UK website Privacy Policy requirements covers who needs one and what happens if you do not have one. For the post-Brexit context on which version of GDPR applies to you, see UK GDPR vs EU GDPR.