A Practical Guide to GDPR Checklist

A GDPR checklist is not a substitute for legal advice, but it is a practical way to find gaps before customers, regulators, or incidents do. The GDPR is built around accountability: organizations must be able to show what they process, why, under which legal basis, with which safeguards, and for how long.

Use this checklist as an operational review for websites, SaaS products, marketing systems, and internal tools.

1. Map Your Data

Create a record of the personal data you process. Include:

• Contact forms.
• Analytics tools.
• CRM records.
• Email marketing lists.
• Support conversations.
• Billing data.
• Product usage events.
• Server logs.
• Authentication systems.
• Third-party scripts and pixels.

For each processing activity, record the data categories, purpose, legal basis, retention, recipients, storage location, and responsible owner. GDPR Article 30 requires records of processing activities for many organizations, and even when a formal Article 30 record is not required, the exercise is essential.

2. Identify a Legal Basis

Every processing activity needs one of the six GDPR Article 6 legal bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests. See the text of GDPR Article 6.

Do not default to consent. Consent must be freely given and withdrawable. Contract applies only when processing is necessary for the contract. Legitimate interests require a balancing test and cannot override people's rights.

For public website analytics, many teams either rely on consent for cookie-based tools or choose cookieless analytics that minimizes personal data and avoids device storage.

3. Review Cookie and Tracking Rules

GDPR is only part of the picture. In Europe, ePrivacy rules govern storing or accessing information on a user's device. Analytics cookies, advertising pixels, local storage identifiers, and some tracking links can require consent.

Audit your site in a clean browser profile:

• What scripts load before consent?
• What cookies are set before consent?
• Does rejecting all non-essential tracking work?
• Are analytics events still sent after refusal?
• Are form values or personal data sent to analytics vendors?

If you can meet business needs with cookieless aggregate analytics, you may be able to remove a major source of consent complexity.

4. Make Privacy Notices Accurate

GDPR Articles 13 and 14 require transparent information about processing. Your privacy notice should explain:

• Who the controller is.
• What data is collected.
• Why it is collected.
• Legal bases.
• Recipients and vendors.
• International transfers.
• Retention periods.
• Rights and how to exercise them.
• Complaint rights.
• Contact details for privacy requests.

The notice must match reality. If your site loads Google Analytics, Meta Pixel, a heatmap tool, a chat widget, and a CRM form handler, the policy needs to reflect that. Better yet, remove tools you do not need.

5. Prepare for Data Subject Rights

People may request access, correction, deletion, restriction, portability, objection, or withdrawal of consent. Build a workflow before the first request arrives.

Checklist:

• Intake email or form.
• Identity verification rules.
• System search steps.
• Vendor request steps.
• Response templates.
• Deadline tracking.
• Record of outcome.

Analytics data is often hard to connect to a person if designed well. That is a benefit. If your analytics tool cannot identify visitors, many rights requests become easier because there is no person-level analytics profile to retrieve.

6. Secure the Data

GDPR Article 32 requires appropriate technical and organizational measures. For most teams, that means:

• Multi-factor authentication.
• Least-privilege access.
• Encryption in transit and at rest where appropriate.
• Logging and audit trails.
• Vendor access controls.
• Backup protection.
• Incident response plans.
• Staff training.

Do not forget exports. CSV files, dashboard screenshots, and BI extracts often become the weakest privacy point.

7. Review Vendors and Contracts

For each vendor processing personal data, identify whether it is a processor, controller, or joint controller. Processors need Article 28 data processing terms. Check subprocessors, transfer mechanisms, deletion terms, security measures, and audit rights.

Analytics vendors deserve special attention because they sit on public pages and may receive IP addresses, user agents, URLs, campaign data, and event details from every visitor.

8. Check International Transfers

Transfers outside the EEA need a legal mechanism, such as an adequacy decision, standard contractual clauses, binding corporate rules, or another GDPR Chapter V route. The EU-US Data Privacy Framework changed transfer options for participating US organizations, but it does not remove the need to understand vendor participation, scope, onward transfers, and product configuration.

9. Minimize and Delete

Set retention by purpose. Website analytics may not need years of raw event data. Server logs may only need weeks or months unless required for security. Old lead lists should be cleaned. Dormant accounts should be reviewed.

Data minimization is one of the GDPR Article 5 principles. It is also the easiest way to reduce breach impact.

10. Document Decisions

Keep evidence:

• Data maps.
• Legitimate interest assessments.
• Consent records.
• Vendor reviews.
• DPIAs where required.
• Security controls.
• Retention schedules.
• Privacy notice versions.

The most mature privacy programs are not the ones with the most paperwork. They are the ones where data collection is intentional and easy to explain.

When to Run This Checklist

Run the checklist before launching a new website, adding a tracking tool, changing CRM or email platforms, entering a new EU market, or connecting analytics to advertising. Also run it after incidents: a leaked spreadsheet, a broken consent banner, a surprise vendor integration, or a customer complaint usually reveals a process gap worth fixing.

Final Launch Check

Before launching a new tracking setup, write down every event collected, the decision each event supports, whether it uses storage or identifiers, which vendors receive it, and when raw records expire. Then test the page in a clean browser profile and compare what loads with the privacy notice.

If the browser still shows unplanned third-party calls, persistent identifiers, or personal data in URLs, the checklist is not complete yet. Fix the implementation first, then update the paperwork.

Frequently Asked Questions

What is a GDPR checklist for?

A GDPR checklist finds gaps in what you process, why, and under which legal basis before customers, regulators, or incidents find them for you. It is not a substitute for legal advice. Treat it as an operational review for websites, SaaS products, marketing systems, and internal tools.

What are the six legal bases for processing personal data under GDPR?

GDPR Article 6 lists six legal bases: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Every processing activity needs one of them, and picking the right one matters more than defaulting to the same one every time. Contract only applies when processing is necessary for the contract, and legitimate interests require a balancing test that cannot override people's rights.

Does GDPR require consent for website analytics?

Not automatically. Cookie-based analytics tools generally need consent because they store or access information on a device, which falls under ePrivacy rules. Teams that switch to cookieless analytics that minimizes personal data and skips device storage can avoid much of that consent burden.

What is the difference between GDPR and ePrivacy rules on cookies?

GDPR governs how personal data gets processed once it exists. ePrivacy rules cover a narrower question: whether you can store or access information on someone's device at all, which is why analytics cookies, advertising pixels, local storage identifiers, and some tracking links can need consent on their own. A site can be careful about GDPR and still break ePrivacy rules by setting cookies before a visitor decides anything.

What information must a GDPR privacy notice include?

A GDPR privacy notice needs to name the controller, describe what data is collected and why, state the legal bases, list recipients and vendors, disclose international transfers, and give retention periods. It also needs to explain rights and how to exercise them, cover complaint rights, and provide contact details for privacy requests. Articles 13 and 14 require all of this to be transparent. The notice also has to match what the site actually does, down to every analytics tool, pixel, and chat widget it loads.

How should a company prepare for data subject access requests?

Build the workflow before the first request arrives, not after. That means an intake email or form, identity verification rules, steps for searching internal systems and contacting vendors, response templates, deadline tracking, and a record of the outcome. People can request access, correction, deletion, restriction, portability, objection, or withdrawal of consent, so the workflow needs to handle all of them, not just deletion.

What security measures does GDPR Article 32 expect?

Article 32 calls for appropriate technical and organizational measures. In practice that means multi-factor authentication, least-privilege access, encryption in transit and at rest where appropriate, logging and audit trails, vendor access controls, backup protection, incident response plans, and staff training. Exports are an easy blind spot. CSV files, dashboard screenshots, and BI extracts often end up as the weakest point in an otherwise solid setup.

When does a vendor need a GDPR data processing agreement?

Any vendor acting as a processor needs Article 28 data processing terms in place. Before signing, work out whether the vendor is a processor, a controller, or a joint controller, then check its subprocessors, transfer mechanisms, deletion terms, security measures, and audit rights. Analytics vendors deserve extra scrutiny because they sit on public pages and can receive IP addresses, user agents, URLs, campaign data, and event details from every visitor.

What do you need for international data transfers outside the EEA?

Transfers outside the EEA need a legal mechanism such as an adequacy decision, standard contractual clauses, binding corporate rules, or another route under GDPR Chapter V. The EU-US Data Privacy Framework gives participating US organizations another option, but it does not remove the need to check whether a specific vendor actually participates, what scope that covers, and how the product handles onward transfers. Read the vendor's configuration, not just its marketing page.

When should you rerun a GDPR compliance checklist?

Run it before launching a new website, adding a tracking tool, switching CRM or email platforms, entering a new EU market, or connecting analytics to advertising. Run it again after anything that suggests a process gap: a leaked spreadsheet, a broken consent banner, a surprise vendor integration, or a customer complaint. These moments tend to surface exactly the kind of gap the checklist catches.