Complete GDPR Website Audit: Step-by-Step Checklist

A GDPR audit isn't something you do once and forget. Every new plugin, form, or third-party service can introduce a compliance gap. The good news: for a typical small business website, the whole process takes one to two hours if you follow a structured approach.

This guide walks you through each step. Open your website in one tab, this checklist in another, and work through it section by section.

Before you start

You'll need access to your website's front end, your CMS admin panel, your hosting control panel, and a list of all plugins and third-party services. Open a spreadsheet to track what you find. For each item, note whether it passes, fails, or needs investigation. This record is useful if a data protection authority ever asks how you manage compliance.

Step 1: Cookie audit

Cookies are where most violations hide. Start here because the problems are concrete and fixable.

Check the consent banner

Visit your website in a private/incognito browser window so you see what a new visitor experiences.

• Is there a consent banner? If your site sets any non-essential cookies (analytics, marketing, social media), you need one. If you're not sure, read do I need a cookie banner?
• Does it offer a real choice? Look for both an Accept and a Reject button on the first layer. A banner that only says "OK" or "I understand" with no way to refuse is not valid consent.
• Is the Reject button equally visible? Same size, same visual weight as Accept. A bright green "Accept All" next to a tiny grey "Manage settings" link fails this test. Our full guide on cookie banner requirements covers exactly what regulators check.
• How many clicks to reject? If accepting is one click, rejecting must also be one click. Three clicks through a settings panel to decline is not equivalent.

Check for pre-loading

This is the most common technical violation. Open your browser's developer tools (F12), go to the Network tab, and reload the page without interacting with the cookie banner. Look for requests to Google Analytics, Facebook, Hotjar, or any marketing tool. If these load before you click anything, consent is being bypassed. Many cheap cookie plugins show a banner but don't actually block scripts from loading.

Build a cookie inventory

In your browser's developer tools, go to Application > Cookies (Chrome) or Storage > Cookies (Firefox). List every cookie with its name, domain, purpose, and expiration. Classify each one: strictly necessary, analytics, marketing, or functional. Compare this list to your cookie policy page. Missing cookies mean your policy is incomplete.

If you have a GDPR compliance checklist, use it alongside this audit to cross-reference the cookie section.

Step 2: Privacy policy review

Your privacy policy needs to satisfy specific requirements from GDPR Articles 13 and 14. This isn't about having a long document. It's about covering every required element.

Open your privacy policy and check each of these points. Our privacy policy requirements guide covers the full list, but here are the ones most often missing:

• Controller identity and contact details. Your business name, address, and a way to contact you. Article 13(1)(a).
• Purposes and legal basis for each type of processing. Not a single blanket statement. Each activity (analytics, contact forms, newsletter, payments) needs its own stated purpose and legal basis. Article 13(1)(c).
• Categories of personal data collected. Be specific. List what you actually collect: names, email addresses, IP addresses, payment details, browsing behavior. Article 13(1)(d).
• Recipients or categories of recipients. Name your hosting provider, analytics service, email platform, payment processor. Article 13(1)(e).
• Retention periods. How long you keep each type of data. "As long as necessary" is too vague. State actual timeframes: "We delete contact form submissions after 2 years." Article 13(2)(a).
• Data subject rights. Access, rectification, erasure, restriction, portability, and the right to object. Plus the right to lodge a complaint with a supervisory authority. Don't just list them -- explain briefly how someone exercises them. Article 13(2)(b-d).
• Transfer to third countries. If any of your processors are based outside the EU (and they probably are -- think Google, Mailchimp, Stripe), state the legal basis for that transfer. Article 13(1)(f).

Red flag: Template privacy policies that mention services you don't use, or omit services you do use.

Step 3: Form audit

Every form on your site that collects personal data needs attention. Check each one.

Contact forms

• Is there a link to your privacy policy near the submit button? Visitors need to know how their data will be used before they submit.
• Are you collecting only what you need? A contact form that asks for date of birth, gender, and home address when all you need is a name and email violates the data minimization principle (Article 5(1)(c)).
• Where does submitted data go? Is form data stored in the database? Emailed to you? Sent to a third-party service? Each destination needs to be covered in your privacy policy.

Newsletter signups

• Is newsletter consent separate from other consent? You cannot bundle terms acceptance and newsletter subscription in a single checkbox. See our newsletter signup GDPR guide for the exact requirements.
• Are checkboxes unchecked by default? Pre-checked boxes are invalid consent. The EU Court of Justice settled this in the Planet49 ruling.
• Do you use double opt-in? Required in several EU countries and best practice everywhere. The subscriber enters their email, receives a confirmation email, and clicks a link to confirm.
• Can people unsubscribe easily? Every marketing email must include a working unsubscribe link.

Check checkout, registration, and booking forms too. The same rules apply: clear purpose, link to privacy policy, no pre-checked marketing consent, minimal data collection.

Step 4: Third-party service inventory

Every external service your website loads sends visitor data to that service's servers. Many of these transfers require consent. Open your browser's developer tools, go to the Network tab, and load several pages. List every external domain that receives requests.

Common problems

• Google Fonts loaded from Google's CDN. Every page load sends the visitor's IP address to Google. A German court fined a website owner 100 euros per visitor for this in 2022. The fix: host the fonts locally.
• Google Maps embeds. Loading a Google Maps iframe transfers visitor data to Google before consent. Use a placeholder image that loads the actual map only after the visitor clicks.
• YouTube and Vimeo embeds. Embedded videos set tracking cookies on load. Show a thumbnail, load the embed only after consent.
• Social media widgets. Facebook Like buttons, Instagram feeds, and Twitter/X embeds all track visitors on load. Use a two-click solution: static placeholder first, actual widget only after the visitor clicks.
• Analytics and tracking scripts. Google Analytics, Meta Pixel, LinkedIn Insight, Hotjar, Clarity. All require consent before loading.
• Chat widgets. Many live chat tools (Intercom, Drift, Tidio) set tracking cookies from the first page load.
• CDN and performance services. Some CDNs log visitor IP addresses. Check whether your CDN provider processes personal data.

Our guide on third-party tracking and consent explains the rules for each category. For each service, ask: Is it in my privacy policy? Does it load only after consent? Do I have a data processing agreement with this provider?

Step 5: Security check

GDPR Article 32 requires "appropriate technical and organisational measures" to protect personal data. A security breach caused by missing basics is a compliance failure, not just a technical one. Our security checklist for small businesses covers this in detail, but here are the audit essentials.

• HTTPS everywhere. Every page on your site must load over HTTPS. Check the padlock icon in the address bar. Test a few pages, not just the homepage. Mixed content warnings (HTTPS page loading HTTP resources) count as a failure too.
• Security headers. Visit securityheaders.com and enter your URL. A grade below B means you're missing basic protections like Content-Security-Policy, X-Content-Type-Options, or Strict-Transport-Security.
• CMS and plugin updates. Log into your admin panel. Are there pending updates? An unpatched WordPress installation with known vulnerabilities is not "appropriate" security. If a breach happens because you skipped a security update from three months ago, that's hard to defend.
• Admin access controls. Strong passwords (16+ characters, unique per account). Two-factor authentication enabled for every admin account. No shared login credentials.
• Backup verification. Backups exist, run automatically, and are stored off-site.

Step 6: Data processing records

Article 30 requires a Record of Processing Activities (ROPA). Even if your business is under 250 employees, the exemption rarely applies -- it only covers occasional processing, and most websites continuously process data through analytics, forms, and newsletters.

Your ROPA should be a simple spreadsheet:

| Processing activity | Purpose | Categories of data | Recipients | Legal basis | Retention period | |---|---|---|---|---|---| | Contact form | Respond to enquiries | Name, email, message | Hosting provider | Legitimate interest | 2 years | | Newsletter | Marketing updates | Email address | Email platform (e.g. Mailchimp) | Consent | Until unsubscribe | | Analytics | Website improvement | IP address, browsing data | Google (GA4) | Consent | 14 months | | Orders | Contract fulfilment | Name, address, payment | Payment processor, shipping | Contract | 7 years (tax) |

Check each row: Is the legal basis correct? Is the retention period documented? Are all recipients listed in your privacy policy? If you don't have a ROPA yet, building one during this audit is the right time.

Step 7: Data breach preparedness

You probably won't have a breach today. But when one happens, the 72-hour notification window under Article 33 doesn't leave time for figuring out what to do.

Check these items:

• Do you know who to notify? Identify your national data protection authority and their breach notification portal. In the Netherlands, it's the Autoriteit Persoonsgegevens. In Belgium, the GBA. In Ireland, the DPC.
• Do you have a basic response plan? A one-page document covering: who handles it internally, what information you need to gather, the notification deadline, and template text for notifying affected individuals.
• Can you detect a breach? Do you monitor your website for unauthorized changes? Does your hosting provider notify you of suspicious activity?
• Do you know what data you hold? The ROPA from Step 6 tells you exactly what personal data you process and where it's stored. Without it, you'll waste critical hours figuring out what was exposed.

A small business doesn't need a 50-page incident response plan. One page with the right contact details, a clear process, and assigned responsibility is enough.

Step 8: Vendor and processor agreements

Article 28 requires a written agreement -- a Data Processing Agreement (DPA) -- with every third party that processes personal data on your behalf. This includes your hosting provider, email service, analytics platform, payment processor, and any SaaS tool that handles customer data.

• List every processor. Go back to your third-party inventory from Step 4. Each external service that handles personal data is a processor.
• Check for existing DPAs. Most reputable providers (AWS, Google Cloud, Mailchimp, Stripe, Shopify) offer a DPA online. Check their legal/privacy pages.
• Verify the content. A valid DPA covers: subject matter and duration of processing, types of personal data, categories of data subjects, and obligations of both parties.
• Watch for missing agreements. Smaller or free tools sometimes don't offer a DPA. If a service processes personal data and won't provide one, find an alternative.
• International transfers. For processors outside the EU, the DPA should include Standard Contractual Clauses (SCCs) or reference an adequacy decision. Many US companies are covered by the EU-US Data Privacy Framework, but check that your specific processor is on the DPF list.

Keep copies of all signed DPAs in one place. Data protection authorities ask for them during investigations.

After the audit

Prioritize fixes by risk:

1. Fix immediately: Scripts loading before consent, missing HTTPS, no privacy policy, pre-checked consent boxes.
2. Fix this week: Incomplete privacy policy, missing cookie inventory, absent DPAs, outdated software.
3. Fix this month: ROPA creation, breach response plan, security header improvements.

Repeat this audit quarterly. Run an automated scan monthly to catch new issues between manual reviews.

Frequently asked questions

How long does a GDPR website audit take?

A basic audit of a small business website takes 1-2 hours. You check cookies, privacy policy, forms, third-party services, and security settings. Most issues can be fixed the same day.

Do I need to hire someone for a GDPR audit?

For a standard small business website, you can do it yourself with a checklist. If you process sensitive data (health, financial) or operate at scale, consider a professional review.

How often should I audit my website for GDPR?

Whenever you add a new feature, plugin, or third-party integration. A quarterly check is a reasonable minimum. Run an automated scan monthly.

Start with an automated scan

You don't have to start from scratch. Run a free website scan to get an instant report on your cookies, privacy policy, third-party services, and security. Use the results as a starting point for your full audit.