A Third-Party Data Flow Audit Template You Can Run Today

Purpose of This Template

A class action filed on October 9, 2026 (Woodley, et al. v. Google LLC, et al., 5:26-cv-11715) claims that a "Track your package" widget in Google Search shares extensive personal information with third parties like Meta, Google Analytics, DoubleClick, and Microsoft. The complaint centers on a gap between user expectations (only a tracking number is shared) and actual data practices. These are allegations, not established facts.

For your team, the key takeaway is the importance of aligning your Consent Notice, privacy policy, and Purpose Disclosure with actual data practices. This template offers a repeatable audit to compare these elements and create a defensible record.

Prerequisites

• Access to your Consent Management Platform configuration and consent log export
• Access to your Tag Manager workspace, including Container Tags and Floodlight Tags if applicable
• A browser with developer tools and a clean profile with no extensions
• Your current privacy policy and Consent Notice text
• Your vendor list or records of processing, noting the Legal Basis for Processing for each vendor
• A designated owner from legal or privacy to sign off on findings

The Template

Copy this into a spreadsheet or ticketing system. Run one copy per page type or embedded feature (checkout, order tracking, support widget, etc.).

THIRD-PARTY DATA FLOW AUDIT
Audit ID: [YYYY-MM-DD-feature]
Auditor: [name]       Reviewer: [name]
Feature / page audited: [URL or component]
Consent state tested: [ ] No interaction  [ ] Reject all  [ ] Accept all  [ ] Partial (list categories)

SECTION 1: PROMISES MADE
1.1 Consent Notice text for this feature (paste verbatim):
1.2 Privacy policy statement about this feature (paste verbatim + section):
1.3 Categories disclosed to the user:
1.4 Recipients disclosed to the user:

SECTION 2: OBSERVED REQUESTS
For each outbound request, fill one row:
| # | Destination domain | Vendor | Fired before consent? Y/N | Data in URL/query | Data in headers/cookies | Data in POST body | Identifier types present |

SECTION 3: STORAGE ACCESS
| # | Name | Type (cookie / [Local Storage](/glossary/local-storage) / [Session Storage](/glossary/session-storage) / [IndexedDB](/glossary/indexeddb)) | Set by | Set before consent? Y/N | Essential or Non-Essential | Lifetime |

SECTION 4: RECONCILIATION
4.1 Vendors observed but NOT in vendor list:
4.2 Vendors in vendor list but NOT disclosed in Consent Notice:
4.3 Data elements observed beyond what 1.3 discloses:
4.4 Requests firing in "Reject all" state:
4.5 Requests firing with no interaction ([Prior Consent](/glossary/prior-consent) failures):

SECTION 5: DISPOSITION
| Finding | Risk (H/M/L) | Action | Owner | Due | Closed (date) |

SECTION 6: SIGN-OFF
Reviewer sign-off: ______  Date: ______
Evidence archive location: ______
Next scheduled audit: ______

Explanation of Each Section

Section 1 identifies the promises made to users before examining actual behavior. It's crucial to paste text verbatim to avoid misinterpretation. Misleading privacy claims can create liability even if your consent mechanics are correct.

Section 2 gathers evidence. Document what data leaves the browser, not just what vendor documentation claims. Pay attention to data in URLs and POST bodies, as identifiers and page context often travel there. Note Hashed Email Identifiers, Universal Identifiers, and Mobile Advertising IDs separately, as they require different disclosures.

Section 3 addresses Terminal Equipment Access. Under Article 5(3) of the ePrivacy Directive, storing or reading information on a user's device requires Valid Consent unless it's Consent-Exempt. Classify storage honestly; analytics and advertising storage are Non-Essential Cookies unless you can document a narrow exemption.

Section 4 is where reconciliation occurs, leading to findings. The most critical rows are 4.4 and 4.5. Any requests firing after a rejection or before any interaction can undermine your consent records.

Sections 5 and 6 turn observations into accountability. An audit without assigned owners and deadlines is just a document, not a control measure.

Customization Options

• Add jurisdiction columns. If you serve California users, add a column to determine if the flow constitutes a sale or sharing of personal information under CCPA, and if the opt-out signal was honored.
• Split by consent state. Run Sections 2 and 3 for each consent state tested. The "Reject all" state is of particular interest to regulators and plaintiffs.
• Extend for embedded widgets. For features co-developed with partners, add a row in Section 1 for the partner's published claims. Shared features mean shared exposure, so document who controls each data flow and what your contract specifies.
• Tie to TCF v2.3 if applicable. Add a column mapping each vendor to its registered purposes and confirm the TC string in the browser matches the purposes the user granted.
• Adjust audit frequency based on changes. Conduct audits after every tag deployment, vendor addition, or widget launch, as well as on a fixed schedule.

Validation Steps

1. Clean-profile test. Open the feature in a fresh browser profile, interact with nothing, and capture the network log. Section 4.5 should be empty.
2. Rejection test. Choose "reject" on the Consent Notice, reload, and repeat. Section 4.4 should be empty. Confirm Equal Prominence of the reject option.
3. Withdrawal of Consent test. Grant consent, then withdraw it through your preference center. Confirm requests stop and storage is cleared where you control it.
4. Log match. Compare the consent log entry for your test session against what actually fired. The record should show the state, timestamp, notice version, and categories granted.
5. Policy match. Have someone outside the audit read Sections 1 and 2 side by side. If they can name a recipient or data element not disclosed to the user, you have a finding.
6. Archive the evidence. Save HAR files and screenshots with the audit ID. If a claim arises, this archive shows what you checked and when.

Start with your highest-traffic embedded features. The goal is straightforward: does your network traffic align with your stated promises?