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.