GDPR Kit Example: Privacy, Cookies, Consent and DPR
This example shows the aiwebpageseo GDPR Kit for an e-commerce site. The kit scanned the site, detected 12 cookies and 3 third-party trackers, then generated 4 ready-to-use compliance documents including a cookie consent banner with accept/reject controls.
| Document | Status | Description |
|---|---|---|
| Privacy Policy | ✓ Ready | Full UK GDPR compliant privacy policy tailored to your site |
| Cookie Policy | ✓ Ready | Lists all 12 detected cookies with purpose and retention period |
| Cookie Consent Banner | ✓ Ready | Copy-paste HTML/JS consent banner with accept/reject/settings |
| Data Processing Record | ✓ Ready | Article 30 Record of Processing Activities (RoPA) |
Four documents in a few seconds is genuinely useful, and it is worth being precise about the nature of the usefulness. The kit scanned your front end, found the cookies and trackers that fired during that visit, and produced drafts structured the way a regulator expects. That saves a week of formatting and a fortnight of working out what sections a policy needs.
What it cannot do is know your organisation. A scan cannot see your lawful basis for each processing purpose, your retention schedules, the contracts you hold with your processors, where your backups live, or whether a deletion request would actually result in deletion. Every one of those is the substance of compliance, and none of it is inferable from HTML.
This matters more than it sounds, because a published policy is a statement of fact. If the generated privacy policy says you retain order data for six years and you in fact retain it indefinitely, you have not become compliant — you have published a dated, public, verifiable untruth, which is a worse position than having no policy at all.
So read every line before you publish it, and change every line that is not true of your business. That is the work. The generation was the easy part.
| Document | Audience | The part people get wrong |
|---|---|---|
| Privacy policy | Public | It must describe what you actually do, in language a customer can follow. Copying a competitor's produces a document that describes their business. |
| Cookie policy | Public | Specificity. Name each cookie or category, its setter, its purpose, its lifetime, and the consequence of refusing. "We use cookies to improve your experience" is the phrasing regulators single out. |
| Consent banner | Public, interactive | It is not a notice. It must obtain a real choice — and it must actually gate the scripts, which is the step that gets skipped. |
| Record of Processing (RoPA) | Internal — for the regulator | It is never published. It is the Article 30 record you produce on request, and it is the one document here that forces you to write down what you genuinely do with data. |
The RoPA is the most valuable of the four and the one most likely to be filed and forgotten. Filling it in honestly is the exercise that surfaces the things nobody wants to find: the marketing spreadsheet of customer emails, the analytics export sitting in someone's drive, the processor you never signed an agreement with. That discovery is uncomfortable and it is exactly the point.
The generated banner puts Reject All beside Accept All with comparable weight, which clears the bar that most banners in the wild still fail. Regulators have been consistent and repetitive: consent must be as easy to refuse as to give, pre-ticked boxes are not consent, and "by continuing to browse you agree" is not consent.
But a banner is a user interface, and a user interface enforces nothing. The failure that shows up in almost every audit is a site that has installed a perfectly correct banner while the analytics tag remains hardcoded in the template, or fires on a page-load trigger in a tag manager that does not check the consent state. The identifier is set, the pageview is sent, and then the visitor is politely asked whether they mind.
Consent obtained after the processing has happened has no legal effect. So the deployment step that matters is not pasting the banner in — it is making every non-essential script conditional on the consent signal, and then proving it: open the site in a clean browser profile, watch the network panel and the cookie jar, and confirm that nothing non-essential appears until you click.
Two further things the banner must do and is often not wired to do: offer granularity by purpose rather than a single undifferentiated switch, and provide a route to withdraw consent later that is as easy to find as the banner was to dismiss.
Twelve cookies and three third-party trackers is what the scan observed on the paths it crawled, in one consent state, from one location, at one moment. Take that seriously as a limitation rather than as a technicality.
A crawl typically misses cookies set only after login, only during checkout, only for visitors in particular regions, or by tags that fire on pages it did not reach. It also cannot know what a third-party cookie truly does or how long the vendor keeps the data behind it — it can only report what the vendor documents, which is not always the same thing.
So walk your own critical journeys with developer tools open: browse, log in, add to basket, check out, and watch what accumulates. Then, for each item, ask the question the scan cannot: who inside this business relies on this data, and would anything break if we deleted it? The honest answer for a meaningful share of trackers on most sites is nobody, and nothing.
Removing them is the cheapest improvement available. It reduces the surface area you must document and defend, it removes third parties from your customers' browsers, and it usually makes the site measurably faster, since third-party scripts are among the most reliable causes of poor Core Web Vitals.
Publishing the four documents is the beginning. Four obligations sit behind them, and none is visible from the front end.
Test a real erasure request end to end. The right to erasure is not the sentence in your policy; it is your ability to find and delete every copy of a person's data within a month — including backups, the analytics platform, the email tool, the support desk and the spreadsheet somebody keeps. If you have never done this once, you do not know whether you can.
Check your processor agreements. Every third party processing personal data on your behalf needs a contract that says so. The generated RoPA will ask you to list them, which is usually the moment somebody discovers there is no agreement with one of them.
Know your retention periods and enforce them. A policy that states a period you do not enforce is worse than one that stays silent. Retention that is genuinely indefinite is very hard to justify and easy for a regulator to ask about.
Have somebody qualified review the whole arrangement. This page is general information and the kit is a drafting tool. If you process special-category data, children's data, or significant volumes across borders, that review is not optional — and arriving at it with a completed RoPA is the point of doing all of the above.
Does applying these four documents make my site GDPR compliant?
No, and no generated document can. Compliance is about what your organisation actually does with personal data — your lawful basis for each purpose, your retention periods, your processor contracts, your security measures, and whether you can genuinely honour a deletion request within a month. The documents describe those things. They do not create them. A generated privacy policy that says you retain order data for six years is worthless, and actively harmful, if you in fact retain it forever: you have now published a dated, public statement that is untrue. Treat the kit as a well-structured first draft that saves you a week, then check every claim in it against reality.
What is a Record of Processing Activities and do I need one?
A RoPA is the Article 30 record: an internal document listing each processing activity, its purpose, the categories of data and data subjects, who you share it with, any transfers outside the UK or EU, your retention periods and your security measures. It is not published — it is what you produce if a regulator asks. The obligation is not universal: it applies to organisations with 250 or more employees, and to smaller ones whose processing is not occasional, is likely to risk people's rights, or involves special-category data. An e-commerce site processing customer orders continuously will generally be caught by that, which is why the kit generates one.
Is a generated cookie policy accurate?
It is accurate about what the scanner found on the day it ran, and that is a narrower claim than it sounds. The scan sees the cookies that were set during that visit, by that path, with that consent state. It will miss cookies set only after login, only at checkout, only for users in certain regions, or by a tag that fires on a page the crawl did not reach. It also cannot know the true purpose or retention of a third-party cookie beyond what the vendor documents. Use the generated list as a starting inventory, then walk your own key journeys with developer tools open and add what the crawl could not see.
The banner preview shows Reject All next to Accept All. Is equal prominence enough?
It is the necessary starting point, not the whole test. Regulators in the UK and across the EU have been consistent that consent must be as easy to refuse as to give, so a Reject All on the first screen with comparable visual weight clears the bar that most banners fail. But the rest of the standard still applies: no pre-ticked boxes for non-essential categories, no scripts firing before a choice is made, granularity by purpose rather than one undifferentiated switch, and a way to withdraw consent later that is as easy to find as the banner was to dismiss. A banner that looks compliant and is bypassed by a hardcoded analytics tag is the most common failure of all.
Do I need a separate privacy policy and cookie policy?
The law requires the information to be available, specific and accessible; whether it sits on one page or two is your choice. In practice separating them is a maintenance decision that pays: your cookie inventory changes every time marketing adds a pixel, while your privacy policy changes rarely, and combining them tends to mean neither gets updated. What is not optional is specificity. "We use cookies to improve your experience" tells a reader nothing and has been criticised repeatedly by regulators. Name each cookie or category, say who sets it, what it does, how long it lasts, and what happens if the user refuses.
Does the UK GDPR differ from the EU GDPR in ways that matter here?
For the purposes of this kit, less than people expect. The UK GDPR retains the substance of the EU regime and the ICO is the supervisory authority; the cookie consent obligation comes from PECR, which mirrors the ePrivacy Directive. The differences that do bite are about scope and transfers: if you offer goods or services to people in the EU as well as the UK, you are likely subject to both regimes simultaneously, may need a representative in the EU, and will need a lawful transfer mechanism for data moving between them. A site selling into both markets should not assume that a UK-jurisdiction kit is the whole answer.
Is any of this a substitute for legal advice?
No. This is general information, and the documents the kit generates are templates informed by a technical scan of your front end. They cannot see your data flows, your contracts, your internal systems or your risk profile, and none of those is inferable from HTML. For a site of any scale, or one processing special-category data, children's data, or significant volumes of personal data across borders, have a qualified adviser review the actual arrangement. The kit is a way to arrive at that conversation with the groundwork already done, not a way to avoid it.
Related Demo Reports
🔒 Generate Your GDPR Compliance Kit
Scan your site and get a complete GDPR compliance kit — privacy policy, cookie policy, consent banner and data processing record — in minutes.