It’s a busy day, because every day is a busy day. It’s the usual kind of busy, however, until you get an email from a customer with a screenshot of your latest marketing ad running on another website pasted into it.
“Your privacy notice says you don’t us third party cookies…”
“Arrghh,” you say and slap your forehead.
Sidebar: I want to take a moment to apologize. I’m usually a better storyteller. No, really, I also write books and people publish them, but it’s super hard to sound compelling when you’re talking about AdTech mishaps. OK, back to your rapidly devolving day…
The problem? You just rolled out a new cookieless retargeting program using first-party data and hashing, but you never went back to confirm what your privacy notice said. Now you have a customer complaining that your notice says you don’t use third party cookies, and you don’t, but you also didn’t talk to legal about whether the privacy notice needed to be updated. And, you didn’t make any changes to the notice to disclose this new initiative, so now you have a trust problem.
I usually advise clients to review their privacy notices at least annually, since that seems to be the best practice that regulators and counsel are coalescing around, but many companies still treat their online website privacy notices like a legal document. It gets written, posted, and then forgotten until someone else brings it up.
But a privacy notice is not just a document. It’s your organization’s public biography (part of what I also call Visual Compliance) that outlines your “this is who we are and how we handle data” statement to customers, prospects, employees, regulators (like the FTC and CPPA), and partners.
Which means your privacy notice does something more than just disclose your data handling. It reflects the truth of your program back to you. Even when it’s distorted and you don’t love what you see.
Privacy Notice Drift
Over time, notices drift. The notice says one thing, but the business operates another way. Nobody meant for it to happen. It just happens, sometimes because of a new feature or a new vendor, and sometimes because technologies change. It’s not usually the result of bad intent but rather normal life inside a fast-moving company, particularly if there’s a disconnect between the people who implement the changes (e.g., marketing, IT) and the people who own the notice (e.g. legal, privacy)
As I mentioned above drift is a trust problem in addition to a compliance issue. If your notice promises one reality and your systems produce another (even facially), it becomes harder to communicate credibly during customer questions, due diligence, security reviews, incidents, and audits.
It’s easier to avoid drift if your company is conscientiously updating its privacy notice at least annually, but the annual legal refresh to comply with new laws needs to also capture these common drift engines that pop up repeatedly:
Shadow IT and “just for now” tools: The company spins up a new SaaS tool or plugin that collects data, and it never makes it into the inventory or the notice. Or alternatively, the tool is supposed to be temporary or a pilot or some other non-permanent addition and is promptly forgotten.
New SDKs and tags: Marketing adds a new tracking or tag manager container, and “what we collect” changes overnight.
Product launches: A feature introduces a new identifier, telemetry stream, or data sharing path that didn’t exist when the notice was last updated.
Acquisitions and integrations: Data systems merge; retention and disclosure practices change; the notice stays frozen.
Vendor ecosystems: Subprocessors shift, hosting regions change, support access expands, and the notice doesn’t keep up.
Consent mechanics are misconfigured: Your banner says one thing; your tags do another. The notice might be accurate on paper but inaccurate in practice.
Some of these activities can (and should) be controlled with privacy request intake processes and a tracker inventory, which I recommend to my clients, but I’m offering up a condensed tool below to help you do quarterly checks against high-impact statements that you make in your quarterly notice. You don’t have to re-do this from scratch every quarter. Once your high impact statements are loaded, you can check the grid against your new feature, tracker, vendor, etc. and see if anything operationally changed because of this new implementation. Or even better, check it before you roll it out and see if anything WILL be impacted by the new tech. This grid also gives you a quick reference on who owns that operation and where to go to validate that nothing has changed (or will change).
Privacy Notices Aren’t Just Marketing Documents
So, I might have gotten ahead of myself in the last paragraph. To take a step back, consider looking at your privacy notice from the same practical perspective as you do your incident response plan or your product requirements documentation. Stop treating it like just a public notice and pull it into your overall governance model.
That means assigning your privacy notice an internal owner (if there isn’t one already or if you outsource it whenever it gets reviewed), a review schedule (at least annually), change triggers (you can start with the list above), and evidence (tracker log, intake forms, configuration screenshots). If these concepts sound like too much work for a website notice, that’s a sign your organization isn’t treating privacy as a system that should be maintained like all your other systems.
Make Your Privacy Notice a Workflow Artifact
I honestly am not trying to add to your already hectic work schedule. I truly believe that doing a little bit of extra work up front on how you plan to maintain your privacy notice disclosures will yield the ability to make quick, confident updates with minimum revision. You will not need to revise your privacy notice each month, but you do need an operating rhythm:
Define ownership: Decide who owns the notice language, and who owns validating practices (these are often different people).
Maintain a disclosure table: Break your notice into modular statements (e.g., what we collect, why, with whom we share, how long we keep it, what choices exist).
Set review triggers: New vendor, new SDK, new product feature, acquisition/integration, new consent tool, or a major incident = “notice drift check.” If things are constantly shifting, that might mean running a quick validation to specific features more often, but if your disclosure table is already updated, that’s just one confirmation, not twenty confirmations at once.
Tie each disclosure to evidence: For every key statement, identify where proof lives. This might look like inventory entries, screenshots of CMP settings, vendor lists, DPIAs/PIAs, retention schedules, and decision logs.
Run a quick drift check quarterly: Even if you don’t think anything changed, you might be surprised what you find. 30 minutes with the right owners validating can prevent year-long drift.
Get Fewer Surprises & Faster Answers
When your notice reflects reality, you don’t get surprise emails from your customers, or if you do, you can address them faster, because you’ve already validated their concerns in advance. This means more confidence communication with customers, procurement, auditors, executive leadership, and from the engineers and marketing teams handling most of the visible compliance changes.
And when something does drift (because none of us are perfect and sometimes sh*t happens), you’ll catch it early when it’s still a simple internal fix instead of a reputational event.
Become a paid subscriber to get access to all of the mini tools that we publish with each post. For instance, this post includes a Privacy Notice-to-Reality Drift Finder that you can use right now!
Finally, reminder that the opinions expressed in this article are the opinion of The Privacy Design Lab. They are not legal advice, and no attorney-client relationship is formed by reading this article or downloading thePrivacy Notice-to-Reality Drift Finder. If you need to consult legal counsel, you can book a consult with ARLA Strategies or other legal counsel you trust!
If you’re tired of privacy advice that only works in theory, you’re in the right place.
The Privacy Design Lab exists for people who want to practice privacy, not just talk about it. It focuses on practical, repeatable ways teams actually learn. We offer hands-on workshops, downloadable systems, and a Privacy Studio community where teams and practitioners can go deeper. Paid subscribers get access all the tools.
If that sounds like your kind of work, we’d love to have you.