GDPR Data Protection Checklist for Websites

You cannot protect data you don't know you have. Start by mapping every form, analytics tag, tracking pixel, and API call on your site that touches personal data. Document what is collected, the purpose, where it is stored, and how long it is retained.

• List every data-collection touchpoint: contact forms, newsletter sign-ups, checkout flows, live chat, analytics scripts, and comment sections.
• Record the categories of data collected (name, email, IP address, device identifiers, payment details, health data, etc.).
• Document the storage location for each data type (your own server, a SaaS CRM, a cloud database, a third-party analytics platform).
• Define and document a retention period for each data category — do not keep data longer than necessary.
• Check for any legacy data stores (old databases, spreadsheets, email archives) that may hold personal data without a clear purpose.

GDPR Article 6 requires that each processing activity rests on one of six legal bases: consent, contract performance, legal obligation, vital interests, public task, or legitimate interests. Picking the wrong basis — or having none at all — is one of the most common compliance failures.

• For each data flow in your audit, assign one of the six Article 6 legal bases and document your reasoning.
• If relying on consent, ensure it is freely given, specific, informed, unambiguous, and as easy to withdraw as to give.
• If relying on legitimate interests, complete and document a Legitimate Interests Assessment (LIA) balancing your interests against the data subject's rights.
• For special-category data (health, biometric, religious, etc.), identify the additional Article 9 condition that applies.
• Review your legal bases at least annually and whenever you introduce a new processing purpose.

Cookies and similar tracking technologies require informed, prior consent for anything beyond strictly necessary functions. Regulators across Europe have issued significant fines for pre-ticked boxes, buried opt-outs, and misleading consent flows. Sensagraph scans your site to detect cookies and tracking scripts that fire before consent is recorded.

• Deploy a Consent Management Platform (CMP) that blocks all non-essential cookies until the user actively accepts them.
• Do not pre-tick any category checkboxes; every non-essential category must be opt-in.
• Provide a Reject All button as prominently as the Accept All button on the first layer of the banner.
• Record and store consent logs (timestamp, version of the policy shown, categories accepted) so you can prove consent was obtained.
• Make it equally easy to withdraw consent at any time — provide a persistent link to re-open the cookie preference centre.
• Categorise cookies correctly: strictly necessary, functional, analytics, and marketing/advertising.
• Review and refresh your cookie inventory every six months, as third-party scripts often introduce new cookies silently.

Articles 13 and 14 of the GDPR require you to provide specific information to data subjects at the point of collection. A clear, jargon-free privacy policy is your primary transparency tool.

• State the identity and contact details of the data controller (and DPO if applicable).
• Describe every category of personal data you collect and the specific purpose for each.
• List the legal basis for each processing purpose.
• Disclose all third parties and sub-processors that receive personal data, including analytics providers, payment processors, and hosting companies.
• Specify retention periods for each data category or the criteria used to determine them.
• Explain all data subject rights and how to exercise them (with a clear contact method).
• Describe your use of automated decision-making or profiling, if applicable.
• Include information on cross-border data transfers and the safeguards in place (e.g., Standard Contractual Clauses).
• Date-stamp the policy and keep previous versions archived for accountability.
• Link to the privacy policy from every page footer, every sign-up form, and your cookie banner.

GDPR Article 32 requires appropriate technical measures to protect personal data. Encryption is explicitly mentioned as an example. Insecure data transmission is a technical vulnerability and a compliance failure simultaneously. Sensagraph continuously checks your HTTPS configuration, TLS version, certificate validity, and security headers.

• Enforce HTTPS across every page of your website — redirect all HTTP traffic to HTTPS automatically.
• Use TLS 1.2 or higher; disable TLS 1.0 and 1.1, and disable SSL 2.0 and 3.0 entirely.
• Obtain and maintain a valid, trusted SSL/TLS certificate and set up automated renewal.
• Enable HTTP Strict Transport Security (HSTS) with a long max-age value (at least 31536000 seconds).
• Encrypt databases and file stores that contain personal data at rest using AES-256 or equivalent.
• Apply the Secure and HttpOnly flags to all session and authentication cookies.
• Implement Content Security Policy (CSP) to prevent data exfiltration via injected scripts.
• Set X-Content-Type-Options: nosniff and X-Frame-Options: DENY (or SAMEORIGIN) headers.

GDPR's data minimisation principle (Article 5(1)(c)) requires collecting only data that is adequate, relevant, and limited to what is necessary for the stated purpose. Less data means less liability and a smaller blast radius if you suffer a breach.

• Review every form on your site and remove any field that is not strictly required for the stated purpose.
• Set form fields as optional unless they are genuinely required; never make optional fields appear mandatory.
• Anonymise or delete analytics data that you no longer analyse — configure your analytics platform's data retention settings.
• Replace direct identifiers with pseudonymous tokens in logs and reporting systems where full identification is not needed.
• Implement automated data deletion jobs that purge records when their retention period expires.
• Use data masking in non-production environments — never use real personal data in development, testing, or staging.

Every third-party service that processes personal data on your behalf — analytics, email marketing, CRM, payment processing, CDN, hosting — is a data processor under GDPR. Article 28 requires a written Data Processing Agreement (DPA) with each one.

• Compile a list of all third-party tools and services that receive or access personal data from your website.
• Confirm a current, signed DPA exists for each processor — most major vendors (Google, Stripe, Mailchimp, etc.) provide DPAs in their settings or on request.
• Verify that processors do not use your data for their own purposes beyond what you have authorised.
• For processors outside the EU/EEA, confirm the transfer mechanism: adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules.
• Re-evaluate processors annually or when a significant change occurs (acquisition, change of sub-processors, new data centre region).
• Remove or replace processors that cannot demonstrate adequate security or sign a DPA.

GDPR grants individuals the rights of access, rectification, erasure, restriction of processing, data portability, and objection. You must be able to respond to any valid request within one calendar month (extendable to three months for complex cases). Failing to respond is itself a violation.

• Publish a clear, easy-to-find method for submitting rights requests (a dedicated email address or web form).
• Document an internal workflow: who receives the request, who verifies identity, who retrieves/deletes the data, and who sends the response.
• Implement identity verification steps to prevent unauthorised disclosure — do not require excessive proof, but confirm the requester is who they claim to be.
• Test the workflow end-to-end at least once a year — submit a sample request internally and measure the response time.
• Log every request received, the action taken, and the response date for accountability purposes.
• Ensure your databases and systems can actually export or delete a specific individual's data — test this technically, not just on paper.
• Train all staff who might receive rights requests (support team, sales) on how to route them correctly.

Article 33 requires notifying your supervisory authority within 72 hours of becoming aware of a personal data breach that poses a risk to individuals. Article 34 may additionally require notifying the affected individuals. Having a plan in place before a breach occurs is the difference between a managed incident and a compliance crisis.

• Define what constitutes a personal data breach for your organisation (unauthorised access, accidental disclosure, ransomware, lost device, etc.).
• Assign a named individual (or the DPO) as the breach response coordinator.
• Create a breach assessment template: data affected, number of individuals, likely consequences, and mitigating measures taken.
• Know your supervisory authority's breach notification portal URL and have login credentials ready.
• Prepare a notification template for affected individuals covering: what happened, what data was involved, what you are doing, and what they should do.
• Test the plan with a tabletop exercise at least once a year.
• Implement intrusion detection and alerting so you become aware of breaches quickly — the 72-hour clock starts when you have a reasonable belief a breach occurred.
• Document all breaches in an internal breach register, even those that do not meet the notification threshold.

Article 30 requires most organisations to maintain a written record of all processing activities. Even where not strictly mandatory (organisations with fewer than 250 employees may have a narrower obligation), a ROPA is the backbone of your accountability programme and invaluable during a regulatory investigation.

• Create a ROPA document or spreadsheet with one row per processing activity.
• For each activity, record: name and purpose, data categories, data subjects affected, legal basis, retention period, storage location, and safeguards applied.
• Include details of cross-border transfers and the transfer mechanism used.
• Assign a data owner responsible for each processing activity.
• Review and update the ROPA whenever a new processing activity is introduced, an existing one changes, or at minimum annually.
• Make the ROPA available to your supervisory authority on request — store it somewhere accessible to the responsible team, not just the DPO.