The week before a product launch is the worst possible time to discover that your tracking is leaking personal data without consent. I’ve sat in too many emergency meetings where someone realized at the last minute that the chat widget was capturing IPs into a US datacenter without an SCC in place. Every one of those meetings could have been prevented by a 30-minute privacy audit done a week earlier.
This article is the checklist I run before any European product goes live or accepts traffic from a new market. It’s twelve points, it takes about half an hour, and it catches the failures that turn into regulator letters six months later.
When to Run a Privacy Audit
I run this checklist at four moments:
- Before any product launch that adds a new domain, region, or user base.
- After adding a new analytics or marketing vendor — even if it “looks similar” to an existing one.
- Quarterly, as a routine drift check on existing properties.
- Whenever a regulator publishes new guidance that touches your stack.
The quarterly cadence is the most important. Things change without anyone noticing — a marketing intern pastes a new pixel into the template, a CMS update enables a tracking feature, a vendor silently adds a sub-processor. The audit is the only routine that catches all of these.
The 12-Point Privacy Audit Checklist
1. Cookie Inventory
Open the site in an incognito browser, accept nothing, and list every cookie that gets set. Every. Single. One. Compare against your published cookie policy. If anything is set before consent that isn’t strictly necessary, you have a violation.
2. Network Request Inventory
Same incognito session, open the network tab, and list every outbound request to a third-party domain. Map each domain to a vendor and a purpose. Anything you can’t immediately identify is an unknown processor — and an unknown processor is a violation by itself.
3. Consent Banner Behavior
Test the consent banner in three states: declined, partially accepted, and fully accepted. For each state, repeat the network request inventory. Confirm that nothing fires that shouldn’t. The most common failure here is a vendor that “respects consent” by waiting for an event that the banner never sends.
4. IP Anonymization
For every analytics vendor, verify that IP anonymization is enabled in the configuration — not just promised in the marketing copy. For server-side endpoints, confirm that the receiving server truncates or hashes the IP before storage.
5. Data Transfer Destinations
Where does each request go? Every third-party domain you logged in step 2 maps to a server location. If any of them is outside the EEA, you need a transfer mechanism: SCCs, an adequacy decision, or BCRs. List the mechanism for each.
6. Data Processing Records
Article 30 of the GDPR requires you to maintain records of processing activities. Open the records and confirm that every vendor you found in steps 2 and 5 is listed, with the right legal basis, retention period, and processor agreement reference. Missing rows are common and easy to fix once you’ve spotted them.
7. Privacy Policy Match
Read the public privacy policy with fresh eyes. Does every vendor you found get mentioned? Do the categories of personal data match what’s actually collected? Are the retention periods accurate? The privacy policy is the document a regulator will read first — it must match reality.
8. User Rights Workflow
Walk through the user rights flow yourself: request access, request deletion, request export. Confirm that each request reaches a real human, that the system can find the user across all your processors, and that the response time is within the 30-day legal window. Run an end-to-end test, not just a process review.
9. Cross-Domain Tracking
If your product spans multiple domains, check that consent and identifiers don’t leak between them in ways the user wouldn’t expect. Cross-domain tracking is a frequent finding in DPA audits because it’s easy to misconfigure and hard to detect from the outside.
10. Form Field Data Capture
Many session replay and analytics vendors capture form input by default, including fields like email, phone number, and credit card. Verify that sensitive fields are masked at the source, not just hidden in the dashboard. Confirm by inspecting the actual outbound payload.
11. Mobile App Permissions
For mobile apps, audit the permissions requested at install and runtime. Each one should map to a documented purpose. The big offenders are location, contacts, and advertising identifiers — all of which need explicit consent and a clear legitimate purpose.
12. Sub-Processor Drift
For each main vendor, pull the latest published sub-processor list and compare it against the version you signed off on. Vendors update these regularly, and you’re contractually entitled to know — but only if you actually check.
How to Run the Audit Efficiently
I block 30 to 45 minutes per audit. Tools I use: an incognito browser, the network tab, a spreadsheet for the inventory, and a copy of the published privacy policy and cookie policy in a side window. That’s it.
- Spend the first 10 minutes capturing the raw inventory — cookies, network requests, banner behavior across consent states.
- Spend the next 10 minutes mapping each entry to a vendor, a purpose, and a transfer mechanism.
- Spend the next 10 minutes cross-checking against the policy, the records, and the consent design.
- Spend the last 5 to 15 minutes writing the findings into a short report with a severity rating.
The output is a one-page document I can share with the DPO, the product owner, and the engineering lead. Findings get tagged Critical, Important, or Minor, with a remediation owner and a date. That’s the artifact that triggers the actual fixes.
Common Findings That Surface in 80% of Audits
- Pixels firing before consent. A meta or LinkedIn pixel that’s loaded with the page rather than gated behind the banner.
- Outdated sub-processor list. The version on the vendor’s site has changed since procurement signed off.
- Privacy policy missing a vendor. Engineering added a new tool and forgot to update the policy.
- Form fields captured by session replay. A new vendor was installed with default settings, capturing email and phone in the recordings.
- Cross-domain consent leak. The user accepts cookies on the marketing site, and the consent token is silently propagated to the unrelated product subdomain.
FAQ
How is a privacy audit different from a DPIA?
A DPIA is a formal risk assessment for a specific high-risk processing activity, required by Article 35 of the GDPR. A privacy audit is a routine operational check on what’s actually live. They serve different purposes — you need the DPIA before launching a high-risk feature, and the audit to make sure the launch matches the DPIA in production.
Should I run the audit myself or hire someone?
Internal audits are fine for the routine quarterly drift check. Hire an external reviewer once a year and before any major launch — they’ll spot blind spots that you’ve trained yourself to overlook. Both have their place.
What’s the most common reason audits miss something?
Auditing in a logged-in or warmed-up browser. Always use a fresh incognito window. The site behaves differently for first-time visitors than for established users, and the violations usually live in the first-visit experience.
Do I need to audit subdomains separately?
Yes. Subdomains often have independent tag managers, vendor configurations, and consent banner instances. Treating them as one audit hides exactly the kind of cross-domain issues you’re trying to catch.
Conclusion
A 30-minute privacy audit before launch and once a quarter is the cheapest insurance you can buy against a regulator letter. The 12 points above catch the failures I’ve seen most often, and the discipline of running them on a calendar is what stops them piling up.
The first time you run this checklist on an existing site, you’ll find at least three things you didn’t know were happening. Fix those, set a quarterly reminder, and the rest of the year stops being firefighting.