A practical, do-it-yourself checklist for business owners who want to know exactly where their site stands on privacy — before hiring a consultant or paying for a tool.
Most privacy problems aren't discovered by regulators first. They're discovered by a developer who added a third-party script and didn't tell anyone, or by a customer who noticed a tracker firing before they clicked "Accept." By then, the damage is done.
A privacy audit doesn't require a law degree or an enterprise compliance budget. It requires going through your site systematically and verifying — not assuming — that the basics are in place. This checklist gives you 30 specific things to check, organized into six areas. Work through it once and you'll have a clear picture of where you stand and what needs fixing.
Section 1: Data Collection Inventory
Before you can comply with any privacy law, you need to know what data your website actually collects. Most business owners think they know — most are wrong. Developer-installed plugins, embedded widgets, and third-party scripts all collect data, often without the site owner's knowledge.
[ ] Know every cookie set on your site (first- and third-party). Open your browser's DevTools (Application > Cookies), load your site without consenting to anything, and list every cookie that's already set. Note the name, domain, and purpose for each one. First-party cookies are set by your own domain; third-party cookies are set by external services.
[ ] Know every tracking pixel and script loading on your pages. In DevTools, open the Network tab, filter by "Script," and reload your page. Every external script URL is a potential data collection point. Check your homepage, a product page, and your checkout or contact page — they often differ.
[ ] Know every third party receiving visitor data. In the Network tab, look for requests to external domains. Every domain that receives a request from your visitor's browser is receiving some data (at minimum, the visitor's IP address). List them. Common examples: Google, Meta, HubSpot, Hotjar, Intercom, Stripe, Cloudflare.
[ ] Know what data your forms collect and where it goes. Audit every form on your site — contact, newsletter, checkout, login, survey. For each one: what fields are collected, what service receives the submission, and where is it stored? If you're using a form tool like Typeform, Gravity Forms, or HubSpot Forms, check what data it's sending to the form provider's servers.
[ ] Know what data is stored in local/session storage. In DevTools (Application > Local Storage / Session Storage), check what your site stores. Some analytics and marketing tools store identifiers here to track users across sessions or bypass cookie consent. If you find data you can't explain, identify the source.
Section 2: Consent & Cookie Banner
A cookie banner that looks compliant and a cookie banner that is compliant are often very different things. The most common failure mode: the banner is visible but the cookies are already firing. Here's how to verify yours actually works.
[ ] Non-essential cookies are blocked until consent is given — not just hidden. Before clicking anything on your banner, open DevTools > Network and reload. You should see zero requests to analytics or advertising domains. If Google Analytics fires before you click Accept, your banner is cosmetic, not functional.
[ ] Accept and Reject buttons are equally prominent. Inspect your banner. The Reject/Decline button must be as visible and accessible as the Accept button — same size, same contrast, not buried in a settings submenu. Pre-ticked boxes and misleadingly colored buttons are dark patterns that regulators are actively enforcing against.
[ ] Consent records are stored with timestamp and choices made. Test your consent flow and then check your backend or cookie provider's dashboard. For each visitor who consents, you should have a record showing: when they consented, what choices they made (which categories), and what version of the banner they saw.
[ ] Visitors can change consent preferences at any time. Look for a consent preferences link in your site's footer. It should reopen the banner and allow visitors to modify or withdraw their choices. "Withdraw consent" must be as easy as giving consent — not buried five clicks deep.
[ ] Google Consent Mode v2 signals are sent correctly (if using Google Ads or Analytics). If you run Google Ads or use GA4, Consent Mode v2 is required. Open Tag Assistant or check your GTM configuration — you should see
gtag('consent', 'default', {...})firing on page load before any other Google tags, with the appropriatead_storage,analytics_storage, andad_user_dataparameters being updated based on visitor choice.[ ] EU visitors get GDPR opt-in; California visitors get CCPA opt-out. Use a VPN or browser extension to simulate an EU IP address. Your banner should require opt-in (consent before cookies fire). Simulate a California IP — your banner should present an opt-out option (data is collected by default, but visitors can say no). These are different legal frameworks requiring different flows.
Section 3: Privacy Policy
Your privacy policy is a legal disclosure, not a formality. Regulators have specifically cited incomplete and generic privacy policies in enforcement actions. Check yours against these items.
[ ] Privacy policy exists and is accessible from every page. A link to your privacy policy should appear in the footer of every page — not just the homepage. Click through five pages on your site and verify the link is present and working on each one.
[ ] Policy names specific third-party services — not just "analytics providers." Search your privacy policy for the word "analytics." If it says "we use analytics providers to track site usage" without naming Google Analytics, Hotjar, or whatever you actually use, it's incomplete. List every third-party service by name.
[ ] Policy covers all jurisdictions you serve. If you have EU customers, your policy must cover GDPR (legal bases for processing, DPA contact, EU data subjects' rights). If you have California customers, it must cover CCPA (right to know, delete, and opt out of sale). Check whether your policy addresses each law's specific requirements, not just privacy in the abstract.
[ ] Policy includes retention periods, legal bases (GDPR), and data rights. For each category of personal data you collect, your policy should state: how long you keep it, your legal basis under GDPR (consent, legitimate interest, contract, etc.), and what rights users have (access, deletion, portability, objection). These specifics are what transform a generic template into a compliant disclosure.
[ ] Policy is current — updated when your data practices changed. Check the "last updated" date. Now think: have you added any new tools, integrations, or features since that date? If HubSpot was added six months ago and your policy predates it, your policy is out of date. Regulators can and do cite stale policies.
Section 4: Data Subject Rights
GDPR gives EU residents the right to access, correct, delete, and port their data within 30 days of a request. CCPA gives California residents similar rights within 45 days. Having these rights in your policy means nothing if you can't actually fulfill them.
[ ] There is a way for visitors to submit access and deletion requests. Your site needs a visible, functional mechanism for submitting data subject requests — a dedicated form, a clearly labeled email address, or a self-service portal. "Contact us" is not sufficient. Test it yourself: can you submit a request right now in under two minutes?
[ ] You know where personal data lives across all your systems. List every system that holds personal data: your CRM, email platform, analytics tool, payment processor, support desk, and any databases your app writes to. When a deletion request comes in, you need to be able to fulfill it across all of them — not just your main database.
[ ] You have a process to respond within 30 days (GDPR) / 45 days (CCPA). "Process" means: someone is notified when a request arrives, a deadline is tracked, and there's a documented workflow for verifying identity, gathering data, and responding. A shared inbox with no owner and no deadline tracking is not a process.
[ ] Deletion requests are actually fulfilled across all systems — not just the main database. When you delete a user from your app, do you also delete their data from your email marketing list, your analytics platform, your support history, and your data warehouse? Test this end-to-end. Most companies find at least one system they forgot.
Section 5: Security Basics
Privacy compliance and data security are separate disciplines, but they overlap in ways that matter for compliance. A breach caused by a preventable vulnerability is also a compliance failure.
[ ] HTTPS is enforced across the entire site — no mixed content. Navigate to your site using
http://(nothttps://). You should be automatically redirected. Open DevTools > Console on your main pages and look for "mixed content" warnings — these indicate that some resources are still loading over HTTP even when the page itself is HTTPS.[ ] CMS and plugins are updated. Log into your CMS (WordPress, Webflow, Shopify, etc.) and check for pending updates. Outdated plugins are the most common vector for website compromises. If you're running WordPress, check: WordPress core version, all active plugins, and your theme. A single unpatched plugin can expose every visitor record you hold.
[ ] Third-party scripts are loaded only from trusted CDNs. Review the external script URLs you found in Section 1. Each one should load from a domain you recognize and trust. Be alert to any scripts loading from unfamiliar domains, especially if they were added by a plugin you installed recently — script injection via compromised plugins is a real attack vector.
[ ] Payment pages don't capture card data before Stripe or PayPal processes it. If you use Stripe, card data should never touch your server — it goes directly from the visitor's browser to Stripe's servers via Stripe.js. Check your checkout page in DevTools: card field input should not appear in any form submission to your own domain. If it does, you have a serious compliance and security problem.
Section 6: Ongoing Monitoring
Privacy compliance isn't a project with a completion date. Your website changes. You add tools, your developers install plugins, your marketing team embeds new widgets. Without ongoing monitoring, a site that passes this audit today can drift out of compliance within weeks.
[ ] New trackers are detected when developers add tools or plugins. Establish a process — or use a tool — that alerts you when a new tracker appears on your site. At minimum, someone should be running a scan after any significant deployment. The worst compliance surprises come from scripts that were added quietly and never disclosed to the privacy team.
[ ] Privacy policy is reviewed and updated at least annually. Schedule a recurring calendar event: once a year, compare your privacy policy against your actual data practices. Has anything changed? New integrations? New data flows? New jurisdictions you're serving? Update the policy to match and update the "last updated" date.
[ ] There is a process for handling new DSARs when they arrive. This item is about readiness, not just tooling. If a data subject request arrived tomorrow, does someone know they own it? Do they know the deadline? Do they know where to look? A process that exists in someone's head and isn't documented will break the first time that person is unavailable.
How to Use This Checklist
Most items require actually loading your site — not reading documentation or trusting that something is set up correctly. Open your browser, open DevTools (F12 on most browsers), and verify each item directly.
A few items — like checking your consent record storage or your DSAR intake — require logging into your backend or third-party dashboards.
One-time fixes vs. ongoing monitoring:
The items in Sections 1–5 are primarily one-time fixes. Once you've inventoried your data collection, fixed your consent banner, updated your privacy policy, established a DSAR process, and addressed security basics, those items are done until something on your site changes.
Section 6 is different. Monitoring, policy reviews, and DSAR readiness are ongoing. They need to be owned by someone and built into your regular operations — not treated as a project that ends.
Prioritize by risk. If you haven't done Section 2 (consent and cookie banner) or Section 3 (privacy policy), start there — these are the items regulators check first and where most enforcement actions originate. Section 1 (data inventory) is the foundation that makes everything else possible.
How Custodia Automates the Hard Parts
Sections 1, 2, and 6 of this checklist — data collection inventory, consent verification, and ongoing monitoring — are the most technically demanding and the most time-consuming to maintain manually.
Custodia handles all three automatically. A single scan crawls your site like a real visitor, detects every cookie, tracker, pixel, and third-party script, and maps exactly what fires before and after consent. Weekly re-scans catch new trackers the moment they appear. And if your consent banner has a gap — a cookie firing before opt-in, a missing Google Consent Mode signal — Custodia flags it with specific remediation steps, not just a generic warning.
The manual items in Sections 3, 4, and 5 — privacy policy accuracy, DSAR processes, security hygiene — are still on you. This post exists because compliance requires human decisions, not just automation. But if you're spending hours manually running scanner tools and cross-referencing network requests, there's a better use of your time.
See every tracker on your site, verify your consent banner is actually blocking cookies, and get a plain-English compliance report — in about 60 seconds.
Last updated: March 2026
Top comments (0)