A GDPR website compliance audit should be repeatable, not a one-time document review. This checklist shows how to monitor cookies, consent, forms, analytics, embedded services, privacy notices, retention, and user-rights workflows, then record what changed so your review remains useful after each site release.
Overview
Website privacy compliance depends on what the site actually does, not only on the wording of its privacy notice. A marketing page may load analytics before a visitor makes a choice. A contact form may collect more information than the sales team needs. A video, chat widget, payment tool, or scheduling service may send information to a third party. A redesign can introduce new scripts without anyone updating the cookie notice or records of processing activities.
The purpose of this GDPR website audit is to compare the documented experience with the live one. It is not a substitute for legal advice or a complete organizational GDPR program. Instead, it gives developers, IT administrators, product owners, and privacy leads a practical control routine.
Start by defining the scope. Record the domains, subdomains, landing pages, forms, authenticated areas, regional versions, and major campaign pages being reviewed. Capture the date, reviewer, test browser, device type, and whether the test was performed as a new visitor. Keeping this context makes later comparisons more reliable.
For broader coverage, pair this review with a website security compliance checklist. Privacy and security overlap, but they answer different questions: privacy review examines how personal data is collected and used, while security review examines how systems and information are protected.
What to track
1. Cookies and similar technologies
Test the site in a clean browser session with storage and network activity visible. Record each cookie, local-storage item, pixel, script, or comparable technology that appears before and after a visitor interacts with the consent interface. For every item, note its provider, purpose, category, duration, data involved, and the page or event that activates it.
Check whether non-essential technologies are blocked until the visitor makes an appropriate choice. The interface should make the available choices understandable and should not make rejection materially harder than acceptance. Confirm that consent can be withdrawn or changed later, and test whether the withdrawal affects subsequent activity rather than only changing the banner display.
Do not rely solely on a vendor's category label. A tool described as analytics may also support advertising, profiling, session recording, or cross-site measurement. Review the configuration in your own account and compare it with the tool's current behavior.
2. Forms and data collection
Inventory every public form, including contact, newsletter, demo, account-registration, support, download, survey, and recruitment forms. For each one, record the fields collected, whether a field is required, the purpose of collection, the receiving system, the retention expectation, and the people or teams with access.
Look for unnecessary fields, open text boxes that invite sensitive information, and hidden fields that pass data to marketing or customer relationship systems. Confirm that the form displays a clear privacy notice or a nearby link before submission. If consent is requested for a separate purpose, keep that choice distinct from the act of submitting an enquiry.
3. Analytics, advertising, and embedded services
List every external service loaded by the site, such as analytics platforms, maps, fonts, video players, chat tools, payment providers, scheduling systems, social media embeds, content delivery services, and fraud-prevention tools. Record the data flow, activation condition, provider, contractual status, and relevant transfer or subprocessor information maintained by your organization.
Test the service in practice. A page may contact a provider as soon as it loads, even when the visible embed appears inactive. Where a service cannot be loaded without sharing information, consider a prior-consent design, a self-hosted alternative, a click-to-load placeholder, or another documented approach appropriate to the purpose.
Keep supplier information current. A subprocessor list review can help SaaS teams track changes that may affect website disclosures and data-processing records.
4. Privacy notices and disclosures
Compare the privacy notice with the live collection points. It should describe the purposes relevant to the site, categories of personal data, recipients or recipient categories, retention approach, individual rights, contact routes, and other information required for the organization’s situation. Avoid treating a generic privacy policy template as complete without adapting it to actual processing.
Check that links are visible, functional, versioned, and available from forms, account areas, and the cookie interface where appropriate. The notice should explain material changes in a way that a normal visitor can understand. Record its publication date and the internal owner responsible for reviewing it.
5. Retention and rights workflows
Trace what happens after a visitor submits information. Identify where the data is stored, when it is deleted or anonymized, which backups or connected systems may retain it, and who handles a request for access, correction, deletion, objection, or consent withdrawal. The exact workflow will vary by organization, but ownership and escalation should be clear.
Maintain a simple evidence record: test submission ID, systems checked, deletion or suppression result, reviewer, and completion date. If your organization maintains records of processing activities, reconcile the website inventory with those records rather than keeping two unrelated lists.
Cadence and checkpoints
A quarterly review is a practical baseline for many sites, with a lighter monthly check for consent functionality and recent changes. Use a fixed checklist so results can be compared over time.
- Monthly: test the consent banner, rejection path, withdrawal control, principal forms, and privacy-policy links in a clean session.
- Quarterly: rescan representative pages, review cookies and third-party requests, reconcile forms and vendors, and verify retention and rights workflows.
- Before a major release: review tracking requirements, embedded services, form fields, regional behavior, and notice changes with the release owner.
- After a release: repeat the clean-session test and compare the results with the pre-release inventory.
- When a supplier changes: check new scripts, subprocessors, purposes, transfer information, retention settings, and contractual documentation.
Give each finding an owner, severity, due date, evidence link, and status. Screenshots, network logs, configuration exports, and test records are more useful than a checklist marked “complete” without supporting detail.
How to interpret changes
Not every change has the same significance. A new strictly necessary session cookie may require inventory work but may not change the consent experience. A new advertising pixel, session-recording tool, or form integration can affect purposes, disclosures, consent logic, vendor reviews, and retention.
Classify findings by the control they affect:
- Collection: the site gathers a new field, identifier, or category of data.
- Activation: a script or embedded service runs earlier than expected or without the intended choice.
- Purpose: collected information is used for a new or broader purpose.
- Disclosure: the privacy notice, cookie information, or vendor description no longer matches reality.
- Retention: data remains in a form or connected system longer than the documented approach.
- Rights and security: a person cannot exercise a relevant choice, or access and deletion controls do not work as expected.
Prioritize issues that affect many visitors, activate before choice, expose sensitive information, involve a new provider, or prevent withdrawal and rights requests. Then document the decision, including accepted limitations and the reason for the chosen remediation. For supplier-related questions, use a structured vendor risk assessment rather than relying on a marketing page.
When to revisit
Revisit this GDPR checklist on the monthly or quarterly cadence selected for your risk profile, but do not wait for the next scheduled review when a material change occurs. Trigger an additional audit after a redesign, tag-manager change, analytics migration, new form, new marketing campaign, regional expansion, CMS or hosting migration, identity-provider change, or addition of an embedded service.
Also review the checklist after a suspected privacy incident, an unexpected cookie discovery, a vendor notification, a change to internal retention rules, or a user-rights complaint. Coordinate privacy findings with your incident response plan when personal data may have been exposed.
At the end of each review, save four items: the tested scope, the current inventory, unresolved findings, and a change log. The change log should state what changed, when it changed, who approved it, which controls were retested, and when the next review is due. This turns website compliance from a static policy exercise into an operational record that can keep pace with releases.
For the next cycle, begin with the last unresolved item and the pages most likely to have changed. That simple habit keeps the audit focused, preserves evidence, and makes privacy compliance part of ordinary website maintenance.
