GDPR Checklist for Websites: A Practical Compliance Audit You Can Reuse

Overview

This guide gives you a working GDPR checklist for websites, not a one-time legal theory exercise. The goal is to help you identify the main compliance points that tend to drift out of date as websites evolve.

At a high level, the GDPR applies to organizations that offer goods or services to people in the EU or monitor the behavior of EU residents. For websites, that often means the compliance questions start with ordinary features: forms, analytics, chat widgets, cookies, account creation, support tools, and marketing integrations.

Before you begin the audit, keep three concepts straight:

• Personal data is broadly defined. It is not limited to names and email addresses. IP addresses, device identifiers, usernames, and form submissions may all be relevant depending on context.
• Controller vs processor matters operationally. The controller determines the purposes and means of processing. A processor handles personal data on behalf of the controller. Many website owners act as controllers for site data, while vendors such as hosting, analytics, CRM, or email platforms may act as processors for at least some processing activities. If you need a deeper breakdown, see Controller vs Processor Under GDPR: A Practical Guide for SaaS, Agencies, and Website Owners.
• Accountability is not just about having a policy page. You should be able to explain what data the site collects, why it is collected, where it goes, and what settings or contracts support that processing.

A useful way to run a GDPR website audit is to inspect the site in four layers:

1. Visible collection points: forms, signups, checkout, chat, comments, account areas.
2. Hidden collection points: cookies, pixels, scripts, session replay, logs, CDN, security tooling.
3. Back-end processing: storage, retention, access, exports, vendor transfers, backups.
4. Governance: privacy notice, consent records, vendor agreements, response procedures, and documentation.

If your site is small, this may fit in a spreadsheet. If it is complex, build the checklist into your release and change-management process.

Checklist by scenario

Use the scenario that best matches your website, then add any overlapping items. Most sites are hybrids.

1) Brochure site with analytics, contact forms, and basic marketing tools

This is the most common starting point for website GDPR compliance. Even simple sites often process more personal data than expected.

• List every form on the site and document what fields are collected, why they are necessary, and where submissions are sent.
• Confirm your privacy notice accurately describes contact form processing, including categories of data, purpose, legal basis, and retention approach.
• Check whether analytics tools collect IP addresses, device identifiers, or event-level behavior data. Document the purpose and configuration.
• Identify all cookies and similar technologies set by the site, tag manager, analytics provider, embedded video tools, social widgets, and ad platforms.
• Make sure non-essential cookies or trackers are not dropped before valid consent where consent is required.
• Review your cookie banner and preference center for clarity. Users should be able to reject non-essential categories as easily as they can accept them.
• Verify consent choices are stored and respected across the tools you actually use.
• Check that your contact form does not ask for more information than you need.
• Ensure email marketing opt-ins are separated from ordinary contact requests unless you have a clear basis to combine them.
• Confirm any spam filtering, form plugins, CAPTCHA tools, or hosting logs used in connection with forms are documented as part of your data flows.

2) Lead generation or marketing-heavy website

If the site uses ad attribution, retargeting, CRM sync, or enriched lead tracking, the privacy risk is higher and the audit needs to go deeper.

• Map all marketing scripts loaded through your tag manager, not just the tools your team remembers installing.
• Review whether visitor behavior is profiled for ad targeting, segmentation, or lead scoring.
• Check whether your cookie consent mechanism blocks marketing tags until consent is obtained.
• Confirm your privacy notice clearly discloses marketing cookies, profiling, analytics, and any third-party advertising or audience tools.
• Document data flows from website to CRM, marketing automation, customer data platform, ad platform, and support tools.
• Check whether the website shares hashed identifiers, email addresses, or custom conversion events with ad platforms.
• Review embedded content such as videos, maps, webinar tools, or chat platforms that may set third-party cookies or initiate personal data transfers.
• Make sure your unsubscribe and marketing preference processes align with the way contact data is actually used after collection.

3) SaaS website with accounts, trials, or product telemetry

For SaaS teams, the public website and product experience often blur together. Your privacy compliance checklist should cover both the marketing layer and the authenticated product layer.

• Separate website processing from in-product processing in your records and disclosures.
• Identify whether you act as controller, processor, or both, depending on the dataset and service model.
• Verify account registration, SSO, trial signups, support requests, and billing flows are documented with purpose and retention logic.
• Review telemetry, diagnostics, audit logs, and error reporting. System-generated logs can still be relevant to privacy compliance if they include identifiers or user-linked activity.
• Confirm your privacy notice and customer-facing documents distinguish between prospect data, account owner data, end-user data, and support data.
• Check that your data processing agreement is current where you act as a processor. A useful starting point is Data Processing Agreement Checklist: What Controllers and Processors Should Verify.
• Verify access controls, administrative roles, export features, and deletion workflows align with your stated data protection commitments.
• Ensure your incident response and breach escalation process covers website and application data together. For timing reference, see Breach Notification Requirements Tracker: GDPR, UK, and US State Timelines.

4) Ecommerce or transaction-enabled website

Ecommerce sites combine identity data, payment flows, customer support, and behavioral data, which makes the audit broader.

• Inventory checkout fields, fraud controls, shipping integrations, and support workflows.
• Document which vendors receive order, billing, address, and support information.
• Check that payment providers, fulfillment tools, customer support tools, and review platforms are covered in your vendor inventory.
• Make sure account areas offer practical ways to review personal details and manage preferences where appropriate.
• Review retention settings for abandoned carts, order histories, support tickets, and promotional lists.
• Confirm analytics and marketing tools are not silently collecting more checkout or purchase data than intended.

5) Small business website with limited compliance resources

For SMBs, the fastest way to improve small business cybersecurity compliance and privacy posture is to focus on the systems you actually use.

• Create one simple data map: collection point, purpose, legal basis, vendor, storage location, retention, and owner.
• Maintain a current list of plugins, scripts, and embedded tools. Remove anything no longer needed.
• Use a privacy notice that reflects your real workflows, not a copied template. This companion guide helps: Privacy Policy Checklist for Websites and SaaS: What to Disclose and When to Update It.
• Check that cookie settings, form fields, and CRM workflows still match what the site says publicly.
• Review whether a formal record of processing activities is needed or useful for your environment. See Records of Processing Activities Checklist: When You Need a ROPA and What to Include.
• Assign ownership. Even a small site needs one person responsible for privacy updates after changes.

What to double-check

This section covers the items most likely to look compliant on paper but fail in implementation.

Cookie consent and tracking behavior

• Test the site in a clean browser session. Reject optional cookies and see what still loads.
• Inspect scripts loaded through consent management tools and tag managers, not just visible cookies.
• Check region-based logic carefully. If your banner behavior changes by geography, confirm the configuration matches your risk assumptions.
• Make sure consent logs are retained long enough to support accountability without keeping unnecessary data forever.

Privacy notice accuracy

• Compare every disclosure in the notice to the live site and actual vendor stack.
• Verify controller identity, contact method, data categories, purposes, lawful basis, retention framing, rights information, and international transfer disclosures are still current.
• Update references to retired tools, old domains, legacy forms, or previous business models.

Vendor and processor oversight

• List all processors and significant sub-processors involved in website operations, including hosting, CDN, analytics, forms, customer support, email delivery, and security tooling.
• Confirm data processing terms are in place where needed and that vendor roles are understood. Not every vendor relationship is identical.
• Review whether vendor defaults are privacy-friendly or whether you must actively disable excessive collection.

User rights and internal response readiness

• Make sure requests for access, deletion, correction, or objection can be routed to someone who knows where website data is stored.
• Check whether website data is duplicated across CMS exports, CRM systems, support tools, analytics platforms, and backups.
• Document who approves responses and how identity is verified before disclosure.

Security controls that support privacy commitments

Privacy compliance depends on operational controls. If your site promises data protection but basic controls are missing, the documentation will not carry much weight.

• Use HTTPS consistently and review certificates, redirects, and mixed content.
• Limit admin access to CMS, hosting, DNS, analytics, consent manager, and tag manager accounts.
• Enable MFA for privileged accounts.
• Review logging and monitoring for unauthorized admin actions or unexpected script changes.
• Patch CMS cores, plugins, themes, and server components on a defined schedule.
• Check backup access and restoration procedures, especially if backups contain personal data.

If your website is part of a broader SaaS environment, align this work with your broader control set. For example, teams preparing for customer assurance often pair privacy reviews with SOC 2 Readiness Checklist for Startups and SaaS Teams.

Common mistakes

Most website GDPR issues are not caused by one dramatic failure. They come from small mismatches between tools, disclosures, and habits.

• Treating the privacy policy as the whole program. A notice is only one output of compliance. You also need accurate data mapping, vendor review, and working controls.
• Forgetting hidden third parties. Embedded fonts, video players, chat tools, heatmaps, anti-spam services, and tag managers can introduce personal data processing you did not account for.
• Using consent banners that are cosmetic. If non-essential scripts fire before consent, the banner is not doing the work it appears to do.
• Collecting more than necessary. Long forms, broad telemetry, and default marketing integrations often expand the data footprint without a clear need.
• Ignoring controller-processor distinctions. If you do not understand who determines the purpose and means of processing, contracts and notices become harder to get right.
• Assuming pseudonymous data is out of scope. Identifiers in logs and analytics may still matter if they relate to identifiable individuals or can be linked back in context.
• Failing to revisit after redesigns. New templates, scripts, and plugins routinely break prior consent and disclosure assumptions.
• Leaving privacy updates to legal alone. Website compliance usually depends on developers, marketing ops, IT, product, and whoever administers vendors and tags.

If your organization needs a broader baseline beyond the website itself, GDPR Compliance Checklist for Small Businesses: Website, App, and Customer Data Requirements provides a wider operational view.

When to revisit

Use this article as a living audit, not a one-time project. Revisit your website GDPR checklist at predictable moments and after any meaningful workflow change.

Review the checklist at least when:

• You launch a redesign, new CMS, or new cookie banner.
• You add analytics, ad tech, chat, support, video, personalization, or session replay tools.
• You change hosting, CDN, consent management, forms, CRM, or email platforms.
• You expand into new regions or begin targeting EU users more directly.
• You add account creation, gated content, newsletter automation, or ecommerce features.
• You update your retention model, security tooling, or incident response process.
• Seasonal planning cycles begin and teams are evaluating new campaigns or integrations.

A practical quarterly review routine:

1. Export a current list of scripts, cookies, plugins, and integrations.
2. Compare it to your privacy notice, consent categories, and vendor inventory.
3. Test the banner in a clean browser session and verify pre-consent behavior.
4. Review one live user journey end to end: landing page, form, CRM, email, support, deletion path.
5. Update your data map and records if anything changed.
6. Assign remediation owners and deadlines, then log the review date.

That simple routine is often enough to catch the gaps that create avoidable risk.

The strongest GDPR checklist for websites is one your team can repeat without starting from scratch. Keep it tied to the real site, the real vendor stack, and the real workflows your users move through. If a page, tag, form, or integration changes, your audit should change with it.