Website GDPR Compliance Checklist: A Practical Guide for 2025

Overview

Website GDPR compliance is not a one-time document exercise. It is an operating process that connects what your website does, what data it collects, why it collects it, where that data goes, and how people can exercise their rights.

Use this checklist as a repeatable review tool rather than a substitute for legal advice. Your obligations may depend on your role, location, users, processing activities, and other applicable laws. Start by documenting assumptions, then confirm the areas that create the greatest risk or uncertainty.

Establish the processing picture

• List every public-facing website, landing page, customer portal, application, form, and support channel.
• Identify the personal data each service collects, such as names, email addresses, account details, device information, identifiers, billing data, or support messages.
• Record the purpose of each activity and whether the data is necessary for that purpose.
• Identify who determines the purposes and means of processing. Under the controller vs processor GDPR distinction, a controller generally decides why and how personal data is processed, while a processor handles it on the controller's instructions.
• Map transfers between your website, hosting provider, analytics tools, payment services, customer relationship systems, email platforms, and other vendors.

Create a usable record

Maintain a records of processing activities template or equivalent register for material processing activities. Useful fields include the process owner, purpose, categories of individuals and data, recipients, retention period, security measures, vendors, and international transfer information where relevant. Keep the register practical: it should help the team answer questions, not merely exist for an audit.

Checklist by scenario

1. Marketing and informational websites

• Publish a privacy notice that matches the site's actual data flows. Explain purposes, categories of data, relevant rights, retention approach, recipients or recipient categories, and contact routes.
• Review every form. State why information is requested, avoid collecting fields that are not needed, and provide an appropriate privacy notice link near the point of collection.
• Inventory cookies, pixels, tags, local storage, embedded media, chat tools, fonts, and other technologies that may transmit information to third parties.
• Separate strictly necessary technologies from optional analytics, advertising, personalization, or similar technologies.
• Configure the consent mechanism so optional technologies do not run before the required choice is recorded. Make rejecting or changing optional choices reasonably accessible.
• Record consent events where consent is used, including the version of the notice or preference information needed to understand what was accepted.
• Provide a way to withdraw or change consent that is at least as practical as giving it.

2. Account-based websites and SaaS products

• Document the data collected during registration, authentication, onboarding, use of the service, billing, support, and account closure.
• Separate processing needed to provide the service from optional product analytics, direct marketing, research, or feature personalization.
• Give users clear privacy information at the relevant touchpoints, not only in a document they are unlikely to read.
• Define retention and deletion behavior for active accounts, closed accounts, backups, logs, tickets, and exported data.
• Provide operational routes for access, correction, deletion, restriction, objection, and portability requests where applicable.
• Document how identity is verified, how requests are assigned, and how responses are reviewed before sending.

3. Websites using external vendors

• Maintain a current vendor and subprocessor inventory, including the service, data involved, purpose, hosting or transfer locations, and owner.
• Determine whether a data processing agreement is needed and ensure instructions, confidentiality, security, subprocessors, assistance, deletion, and audit provisions are addressed as appropriate.
• Check that vendor descriptions in your privacy notice and subprocessor disclosures match the tools actually deployed.
• Review vendor access, account permissions, authentication, offboarding, breach communication routes, and contract renewal dates.
• Use a documented vendor risk assessment for services that handle sensitive, large-scale, or operationally important data. See the vendor security assessment checklist for a broader review structure.

4. Security and incident readiness

• Enforce HTTPS and protect administrative access with strong authentication, least privilege, and timely offboarding.
• Review application, hosting, database, DNS, backup, logging, and monitoring controls according to the sensitivity of the data and the service's risk profile.
• Define how suspected personal data incidents are reported internally, investigated, contained, documented, and escalated.
• Assign responsibility for assessing whether notification or other communications may be required under applicable rules and contracts.
• Test contact lists and decision paths rather than relying on an unused document. The incident response plan checklist can help structure this work.

What to double-check

Most compliance gaps occur where documentation and implementation diverge. Compare your published privacy notice with a live browser session and a real account journey. Check which requests are sent, which cookies appear, which vendors receive data, and when each transfer occurs.

Then compare the technical configuration with your records:

• Does the cookie banner reflect the current tag manager and scripts?
• Does each form use the stated purpose and retention approach?
• Do deletion workflows reach connected systems, or does data remain in support, marketing, analytics, and backup environments without an explanation?
• Are vendor and subprocessor lists current after product releases or tool changes?
• Can the team locate request records and demonstrate how decisions were made?
• Do security policies cover the systems that actually process personal data?

For a wider technical review, use the website security compliance checklist alongside your privacy review. Privacy compliance and cybersecurity compliance are related but not interchangeable: a secure system can still collect data without adequate transparency, while a well-written notice cannot compensate for weak access controls.

Common mistakes

• Using a generic privacy policy template without validation. A template is a starting point. Replace assumptions with details from your actual data map, tools, retention rules, and contact process.
• Treating all cookies as necessary. Classify technologies based on their function and confirm behavior through testing, not vendor descriptions alone.
• Collecting consent and then ignoring withdrawal. A preference center should affect future processing and be connected to a documented operational process.
• Choosing a lawful basis after the workflow is built. Document the purpose and necessity of processing first, then assess the appropriate basis with qualified guidance where needed.
• Forgetting non-production environments. Test databases, screenshots, logs, exports, and developer tools may contain personal data and need appropriate controls.
• Leaving ownership unclear. Assign an owner for the privacy notice, cookie configuration, request handling, vendor records, and incident escalation.
• Assuming a vendor contract completes due diligence. Contract terms should be supported by an assessment of access, security, location, dependencies, and service changes.

When to revisit

Schedule a structured review before seasonal planning cycles, major campaigns, product launches, and annual policy reviews. Revisit sooner whenever workflows or tools change.

Trigger an update when you add a tracking technology, change hosting, introduce an AI or analytics feature, launch a new form, alter account registration, begin a new marketing channel, add a subprocessor, change retention rules, or experience a security incident. Also review after changes to the populations you serve, the countries involved, or the types of data processed.

For each review, save the date, scope, participants, evidence checked, decisions, open issues, and next actions. A simple change log makes it easier to show why a notice, consent configuration, or processing record changed.

Practical next step: choose one representative user journey today—such as landing page to newsletter signup or registration to account deletion. Trace every collection point, cookie, vendor, retention rule, and user request route. Record the gaps, assign owners, and repeat the exercise after the next material workflow or tool change.