GDPR Website Compliance: The QA Team's Checklist

What GDPR Means for Websites Specifically

The General Data Protection Regulation (GDPR), in effect since May 2018, is the European Union's data protection law. It applies to any website that processes personal data of individuals in the EU/EEA — regardless of where the company is based. If your website has European visitors and collects any personal data (including IP addresses, cookies, and analytics data), GDPR applies to you.

For QA teams, GDPR compliance isn't a legal abstraction — it translates into concrete, testable requirements that affect how your website handles cookies, forms, tracking scripts, user accounts, and data storage. A QA team that understands GDPR can catch compliance violations before they become regulatory problems.

Core GDPR principles relevant to websites:

• Lawful basis for processing: You need a legal reason to collect personal data. For most website tracking and marketing, the lawful basis is consent — the user must actively agree before you collect their data.
• Purpose limitation: Data collected for one purpose (e.g., completing an order) cannot be used for an unrelated purpose (e.g., marketing) without separate consent.
• Data minimization: Only collect the personal data you actually need. A newsletter signup shouldn't require a phone number and date of birth.
• Transparency: Users must be clearly told what data you collect, why, who it's shared with, and how long it's kept.
• Data subject rights: Users have the right to access their data, correct it, delete it, and object to its processing.

The regulation has real enforcement. As of early 2026, GDPR fines have exceeded 4.5 billion euros in total across thousands of enforcement actions. The largest fines target household names, but small and medium companies are also regularly penalized for basic compliance failures — often failures that a thorough QA process would have caught.

Cookie Consent: Getting It Right

Cookie consent is the most visible — and most frequently botched — GDPR requirement on websites. The ePrivacy Directive (often called the "Cookie Law") works alongside GDPR to require informed consent before setting non-essential cookies.

What the law requires:

• Prior consent for non-essential cookies: No analytics cookies, marketing cookies, or tracking pixels may be set until the user has actively consented. This means Google Analytics, Meta Pixel, HubSpot tracking, and similar tools must not load on the first page view before consent is given.
• Granular choices: Users must be able to consent to specific categories of cookies (e.g., analytics, marketing, functional) rather than being forced to accept all or nothing.
• Equal prominence for accept and reject: The "reject all" or "decline" option must be as easy to use as the "accept all" option. Burying the reject option behind multiple clicks or making the accept button visually prominent while hiding the reject link in small text is a violation. The French data protection authority (CNIL) fined Google 150 million euros in 2022 partly for this reason.
• No pre-ticked boxes: Consent must be opt-in, not opt-out. Cookie categories cannot be pre-selected.
• Easy withdrawal: Users must be able to change their cookie preferences at any time, as easily as they gave consent originally.

QA testing checklist for cookie consent:

• Verify that no non-essential cookies are set before consent. Open the browser's developer tools, clear all cookies, load the page, and check the cookies before interacting with the consent banner. This is the single most common GDPR website violation.
• Verify that clicking "reject all" or declining cookies actually prevents analytics and marketing scripts from loading. Check the Network tab in developer tools — no requests should go to tracking domains.
• Verify that accepting specific categories (e.g., analytics but not marketing) correctly enables/disables the right scripts.
• Verify that the consent banner reappears appropriately — typically on first visit, and not again for a set period after consent is given (usually 6-12 months).
• Verify that consent preferences can be changed after the initial choice (usually via a "Cookie Settings" link in the footer).
• Test in private/incognito mode to simulate a first-time visitor.
• Test that consent works correctly across the whole site, not just the homepage.

Third-Party Scripts and Trackers

Third-party scripts are the biggest GDPR compliance risk on most websites. Every analytics tool, marketing pixel, embedded widget, chat tool, A/B testing platform, and social media embed potentially collects personal data from your visitors.

Common third-party scripts that require consent:

• Analytics: Google Analytics, Adobe Analytics, Hotjar, Mixpanel, Heap, Amplitude
• Marketing/advertising: Meta Pixel (Facebook), Google Ads conversion tracking, LinkedIn Insight Tag, TikTok Pixel, Twitter/X Pixel
• Session recording: Hotjar, FullStory, Microsoft Clarity, Mouseflow
• Social embeds: Embedded YouTube videos, Instagram feeds, Twitter embeds (these set tracking cookies)
• Live chat: Intercom, Drift, HubSpot chat (if they use tracking cookies)
• A/B testing: Google Optimize (deprecated), Optimizely, VWO, AB Tasty

Scripts that typically do NOT require consent:

• Payment processing scripts (Stripe, PayPal) when used for completing a transaction the user initiated
• Security scripts (bot detection, fraud prevention) when necessary for the service
• Essential functionality scripts (shopping cart, authentication)
• Consent management platforms themselves (Cookiebot, OneTrust, CookieYes)

How to test third-party script compliance:

1. Audit all third-party requests: Load your website and examine the Network tab in browser developer tools. Filter by third-party domains. Document every external domain your site contacts. Compare this against your cookie consent categories.
2. Test with consent denied: Reject all cookies or decline consent, then check the Network tab. No requests should go to analytics or marketing domains. Common failures: Google Tag Manager loading unconditionally and then firing tags regardless of consent; embedded YouTube videos setting cookies even before consent.
3. Use a scanner: Tools like Cookiebot can scan your site and identify all cookies and trackers, including ones you didn't know about. Run these scans regularly since third-party scripts can add new trackers in their updates.
4. Check for tag manager misconfigurations: Google Tag Manager is the most common source of GDPR violations. Tags must be configured to respect consent mode. Verify that consent-dependent tags have the correct trigger conditions and that GTM's built-in consent mode is properly configured.

Data Collection Forms and Privacy

Every form on your website that collects personal data is a GDPR touchpoint. Contact forms, signup forms, checkout forms, newsletter subscriptions, survey forms, job applications — each needs to be compliant.

Form compliance requirements:

• Clear purpose statement: Users must know why their data is being collected. A contact form should state something like "We'll use your email to respond to your inquiry and won't use it for marketing purposes."
• Separate consent for marketing: If you want to add form submitters to a marketing list, you need separate, opt-in consent. A pre-ticked "Subscribe to our newsletter" checkbox is non-compliant. An unticked checkbox that the user actively selects is compliant.
• Data minimization in form fields: Only collect what's necessary. A newsletter signup needs an email address, not a full name, phone number, date of birth, and company name. If extra fields are optional, clearly mark them as such.
• Link to privacy policy: Forms should include a link to your privacy policy, ideally near the submit button.
• Double opt-in for email marketing: While not strictly required by GDPR, double opt-in (user confirms their subscription via email) is considered best practice and is required by some national implementations (e.g., Germany). It also proves that consent was genuinely given.

QA testing checklist for forms:

• Verify that no marketing consent checkboxes are pre-ticked
• Verify that purpose statements are present and accurate
• Verify that privacy policy links are present and functional (not 404s)
• Test form submissions with and without optional marketing consent — confirm that opting out of marketing doesn't prevent the form from being submitted
• Verify that form data is transmitted securely (HTTPS) — check for mixed content warnings
• Verify that confirmation emails for double opt-in are sent and work correctly
• Test that form validation doesn't require unnecessary fields (phone number on a newsletter form, for example)
• Verify that form data is stored in the appropriate system with the correct consent flags

Privacy Policies: What QA Should Check

QA teams aren't expected to write privacy policies — that's a legal function. But QA teams are in the best position to verify that the privacy policy is accessible, accurate, and consistent with the website's actual data practices.

Accessibility checks:

• The privacy policy link should be present on every page, typically in the footer
• The link should work (not return a 404 or redirect to the wrong page)
• The policy should be accessible without requiring login or accepting cookies
• The policy should be readable — not a PDF that downloads, not behind a paywall, not in a tiny iframe
• The policy should be available in all languages your website supports (if your site is in French and German, your privacy policy should be too)

Accuracy checks:

This is where QA adds significant value. Cross-reference the privacy policy against the website's actual behavior:

• Does the policy list all third-party services? If your website uses Google Analytics, Meta Pixel, and Hotjar, all three should be mentioned in the privacy policy. Run a third-party script audit and compare against the policy.
• Does the policy mention all cookie categories? Compare the cookies your site actually sets against what the policy describes.
• Does the policy match the cookie consent categories? If your consent banner offers "analytics" and "marketing" categories, the privacy policy should explain what each category includes.
• Are data retention periods stated? GDPR requires that you state how long you keep personal data. Check that the policy includes retention periods and that they match your actual data practices.
• Is the data controller identified? The policy must clearly state who is responsible for the data (company name, address, contact details, and Data Protection Officer contact if applicable).

Consistency checks:

• If the privacy policy says "we don't share data with third parties" but the website loads Meta Pixel and sends data to Facebook — that's a compliance problem that QA should flag.
• If the privacy policy was last updated in 2020 but the website has added new tracking tools since then — the policy is outdated and needs legal review.

Data Subject Access Requests (DSARs)

Under GDPR, individuals have the right to request access to, correction of, deletion of, and portability of their personal data. These are called Data Subject Access Requests (DSARs). While DSAR processing is largely a backend and organizational process, the QA team's role is ensuring the user-facing DSAR mechanisms work correctly.

User rights that websites should facilitate:

• Right of access: Users can request a copy of all personal data you hold about them. You must respond within 30 days.
• Right to rectification: Users can request corrections to inaccurate data.
• Right to erasure ("right to be forgotten"): Users can request deletion of their personal data in many circumstances.
• Right to data portability: Users can request their data in a machine-readable format (typically JSON or CSV).
• Right to object: Users can object to processing of their data, particularly for direct marketing.

QA testing for DSAR mechanisms:

• Self-service account features: If your website has user accounts, test the data export, account deletion, and preference management features. Data export should produce a complete, readable file. Account deletion should actually delete the data (or anonymize it) rather than just deactivating the account.
• DSAR submission forms/processes: If you have a dedicated form or email address for data requests, test that it works — submissions are received, confirmation emails are sent, and the process is documented.
• Identity verification: DSAR requests require identity verification to prevent unauthorized data access. Test that the verification process works without being so burdensome that it effectively prevents users from exercising their rights.
• Email unsubscribe: Every marketing email must include a working unsubscribe link. Test that unsubscribing actually stops marketing emails and that the preference change is reflected in the user's account settings.
• Data deletion thoroughness: When testing account deletion, verify that the user's data is removed from all visible surfaces — their profile, their comments, their reviews, search results. Also verify that the user can't log in after deletion and that their email address is freed up for a new account if desired.

For organizations that receive DSARs regularly, consider testing the end-to-end DSAR workflow quarterly as part of your regression testing, including the internal notification to the team responsible for processing the request.

Real Enforcement Cases: What Gets Companies Fined

Understanding real enforcement actions helps QA teams prioritize what to test. These are actual fines issued by EU data protection authorities for website-related GDPR violations.

Google — 150 million euros (CNIL, France, 2022)

Google was fined for making it difficult to reject cookies on google.fr and youtube.com. The "Accept All" button was prominently displayed, while rejecting cookies required navigating multiple screens and clicks. The fix was straightforward: provide a "Reject All" button at the same level as "Accept All." This case established that cookie rejection must be as easy as acceptance.

Meta — 390 million euros (Irish DPC, 2023)

Meta was fined for using "contractual necessity" as the legal basis for behavioral advertising on Facebook and Instagram, rather than obtaining proper consent. The regulator ruled that serving personalized ads is not necessary for providing the social media service. This case confirmed that advertising and tracking require genuine consent, not buried terms of service clauses.

Amazon — 746 million euros (CNPD, Luxembourg, 2021)

The largest GDPR fine to date was issued to Amazon for processing personal data for targeted advertising without proper consent. The specifics of the violation weren't publicly detailed, but the scale of the fine (later reduced on appeal but still substantial) demonstrated that regulators are willing to impose massive penalties on major companies.

Criteo — 40 million euros (CNIL, France, 2023)

The advertising technology company was fined for tracking users without proper consent, not properly informing users about data processing, and making it difficult to withdraw consent. This case is especially relevant because Criteo's tracking code runs on other companies' websites — if your site uses Criteo, their compliance problems become your compliance problems.

Smaller fines that reflect common website issues:

• A German company fined 20,000 euros for using Google Analytics without proper consent
• An Austrian website fined 2,000 euros for transferring personal data to Google (via Google Analytics) without adequate data transfer protections
• Multiple companies fined 5,000-50,000 euros for sending marketing emails without proper consent or without working unsubscribe mechanisms
• A Spanish company fined 30,000 euros for having a pre-ticked newsletter consent checkbox on their order form

The pattern is clear: most website-related fines stem from cookie consent failures, tracking without consent, and marketing without proper opt-in — all of which are testable by QA teams.

A Practical QA Process for GDPR Compliance Testing

Here's a structured approach to incorporating GDPR compliance into your QA workflow.

Pre-deployment checklist (run before every release):

1. Cookie audit: Clear all cookies, load the site, check cookies before interacting with consent banner. Zero non-essential cookies should be present. Use document.cookie in the console or the Application tab in DevTools.
2. Consent banner functionality: Test accept all, reject all, and granular category selection. Verify each choice correctly enables/disables the appropriate scripts and cookies.
3. Network request audit: With consent rejected, verify no requests to analytics or marketing domains appear in the Network tab.
4. Form review: Check all forms for pre-ticked marketing checkboxes, missing purpose statements, and missing privacy policy links.
5. Privacy policy link check: Verify the privacy policy is accessible from every page and the link works.

Monthly compliance review:

1. Full cookie and tracker scan: Use Cookiebot, OneTrust, or similar scanning tools to identify all cookies and third-party trackers on your site. Compare against your documented cookie list and privacy policy.
2. Third-party script inventory: Review all third-party scripts loaded on the site. Verify each is documented in the privacy policy. Remove any scripts that are no longer needed.
3. Consent mechanism review: Test the full consent workflow including changing preferences after initial consent.
4. DSAR mechanism test: Submit a test data access or deletion request through your self-service tools and verify the process works end to end.

Quarterly deep review:

1. Cross-reference privacy policy with actual behavior: Audit every claim in the privacy policy against the website's actual data practices.
2. Data retention check: Verify that data is actually being deleted or anonymized according to stated retention periods.
3. Third-party compliance review: Check that your third-party processors (analytics providers, CRM, email platforms) have valid Data Processing Agreements in place.
4. New feature review: Review any features added in the quarter for GDPR implications — new forms, new tracking, new third-party integrations.

Tools for GDPR compliance testing:

• Cookiebot — scans websites and identifies all cookies and trackers; also serves as a consent management platform
• OneTrust — enterprise consent and privacy management platform
• CookieYes — affordable consent management for small to mid-size sites
• Browser developer tools — the most accessible tool for manual cookie and network request auditing
• Blacklight by The Markup — free online tool that scans a URL and reports on trackers, cookies, and privacy issues

Beyond GDPR: Other Privacy Regulations to Watch

GDPR was the first major data protection regulation, but it's no longer the only one. QA teams working on websites with global audiences need to be aware of the expanding privacy regulation landscape.

ePrivacy Regulation (EU): The long-awaited update to the ePrivacy Directive (which governs cookies and electronic communications) is still in progress. When finalized, it will update cookie consent requirements and align more closely with GDPR. Watch for changes to how consent is managed.

UK GDPR: Post-Brexit, the UK has its own version of GDPR that is substantially similar but enforced by the UK's Information Commissioner's Office (ICO). If you serve UK users, you need to comply with both EU GDPR and UK GDPR. In practice, the requirements are nearly identical.

US state privacy laws: The US lacks a federal privacy law, but multiple states have enacted their own. California's CCPA/CPRA is the most significant, requiring a "Do Not Sell or Share My Personal Information" link and opt-out rights for data sales. Virginia (VCDPA), Colorado (CPA), Connecticut (CTDPA), and several other states have their own laws. Each has slightly different requirements, which makes compliance for US-wide websites complex.

Brazil (LGPD): Brazil's data protection law is similar to GDPR in its requirements for consent, transparency, and data subject rights.

Canada (PIPEDA and provincial laws): Canada's privacy framework requires meaningful consent for data collection and is currently being modernized.

For QA teams: The practical impact is that your website may need to handle consent differently based on the user's location. If you use a consent management platform, test that it correctly applies the right consent rules for different regions. A user in California should see CCPA-required options. A user in Germany should see GDPR-compliant consent flows. A user in a region with no specific privacy law might see a simpler notice. Geolocation-based consent is increasingly common and needs thorough testing to verify correct behavior.

Frequently Asked Questions

Resources and Further Reading

• GDPR Official Text The full text of the GDPR with article-by-article commentary and cross-references.
• ICO Guide to GDPR The UK Information Commissioner's Office practical guide to GDPR compliance.
• CNIL Cookie Guidelines France's CNIL detailed guidance on cookie consent requirements.
• Cookiebot Cookie scanning and consent management platform for GDPR compliance.
• GDPR Enforcement Tracker Database of GDPR fines and enforcement actions across Europe, searchable by country, amount, and type.

Related Guides