Your privacy policy says one thing. Your code does another.

There's a genre of document every SaaS product ships and almost no engineer reads after the day it's written: the privacy policy. It lists what you collect, who you share it with, and what rights users have. Then the product ships a new analytics script, a new third-party SDK, a new "just this once" data field — and the policy is now a promise the code doesn't keep.

I built PrivScan because I kept being the person who noticed the gap after the fact, not before.

30-second takeaway

• A privacy policy is a static claim; your dependency list is a moving target. They drift apart by default.
• The highest-risk items are the ones nobody owns: a marketing tag that quietly added a cookie, a vendor SDK with its own sub-processors, a form field that stores more than the policy describes.
• Scanning is cheap, but only if it's a step you actually run — not a PDF you signed once.

The gap isn't malice, it's drift

Almost every policy-vs-code mismatch I've seen came from a normal engineering decision: "we'll add this analytics tool," "this vendor needs this field," "legal said add a checkbox." None of those are evil. But each one widens the distance between what you told users and what your system does, and nobody closes the loop because the policy lives in legal's drive, not in the repo.

A scanner that only checks the policy is useless. A scanner that only checks the code is worse — it can't tell you what you promised. The job is to hold both up side by side and surface the contradictions: a tracker the policy doesn't mention, a data category collected but not disclosed, a right offered but not implemented.

Where this fits in a real workflow

If you ship to Europe, this is the kind of check that belongs before a release, not after a complaint. It pairs naturally with the AI Act and DPIA work a lot of teams are suddenly doing — same root cause, different regulator.

PrivScan runs in the browser, no account, no key. Point it at what you ship and it tells you where your policy and your code disagree. If it misses something your audit caught, that's my bug.

FAQ

What is PrivScan?

A scanner that compares your stated privacy commitments against what your product actually loads and collects, and flags the gaps. It runs in the browser, no account, no key.

Why not just update the policy when we add a tool?

You can — if someone owns that step. In practice the tracker ships on a Tuesday and the policy update is "next sprint" forever. Scanning makes the drift visible on a schedule instead of at audit time.

Does this replace a DPO or legal review?

No. It's a first-pass signal that tells you where to look. The judgement about what's actually compliant still belongs to people who do that for a living.

Author's Process

This product was built with AI coding tools — exploring the codebase, finding the mismatch patterns, and wiring up the scan logic. You can build the same way; the honest part is that the value is in the checklist, not the model.