Why Your Privacy Policy and Your Website Often Disagree

Many privacy policies describe the website that existed when the lawyer or generator produced the document. The live site has moved on. Marketing added a scheduler, development replaced analytics, a plugin introduced a CAPTCHA, and form submissions now enter a CRM. The policy still names the old stack.

This is not primarily a copywriting failure. It is a release-management failure. The document and the runtime were allowed to evolve through separate processes.

The cure is a reconciliation exercise: compare what the notice says with what the browser, server and connected systems actually do. This article explains the technical part of that exercise. Legal conclusions and final wording should be reviewed by qualified counsel.

Treat the policy as a set of testable claims

Bottom line: turn each material sentence into a question that evidence can answer.

“We use analytics only with consent” becomes: does any analytics request or identifier appear before consent? “We retain enquiries for six months” becomes: do the mailbox, CRM, database and backups follow that schedule? “We do not share data with third parties” becomes: which outside hosts and service providers receive a request or submission?

Create a reconciliation table:

A mismatch does not automatically tell you whether the software or the wording should change. It tells you where a decision is required.

The browser exposes only the first layer

Bottom line: network inspection finds recipients and storage on the page, but not the full lifecycle after submission.

Use a fresh browser profile to record first load, rejection, selective consent, full consent and withdrawal. Inventory external domains, cookies, local storage, pixels and iframes. Inspect initiators to connect a request to its source component.

Then follow active features. Submit each form using controlled test data. Trace the record into email, CRM, support software and automation platforms. Review server logs, error monitoring and analytics events for unexpected field values.

The objective is a map, not a compliance score. A crawler can see an external host but cannot reliably determine the contract, purpose, legal basis or whether an exemption applies.

Forms create more copies than the policy suggests

Bottom line: trace the submission beyond the success message.

A typical contact form can create a database entry, email notification, CRM lead, spam-filter request, automation execution log and backup copy. File uploads may sit in object storage even after the visible lead is deleted.

Test each form and record:

• submitted fields and hidden metadata
• every receiving system
• staff roles with access
• notification contents
• default retention settings
• deletion behaviour in downstream systems

Do not use real customer data in the test. Mark the synthetic record clearly and remove it afterward.

Vendor names drift faster than legal pages

Bottom line: reconcile the policy with actual recipients and purposes, not with last year’s plugin inventory.

A team may move from one analytics product to another while the notice still names the former provider. A tag manager can retain disabled tags or load a new marketing endpoint without a policy review. A page builder update can introduce external font or CDN requests.

Maintain a vendor register linked to component ownership. Each entry should record the service, purpose, data categories, hosting or access regions, configuration owner and contract location. Provider documentation can explain product options, but only your runtime and account configuration show which option you use.

International transfer mechanisms and processor terms require legal review. Engineering should provide accurate destinations and configuration evidence, not infer a legal conclusion from a provider’s marketing page.

Retention language often has no implementation

Bottom line: compare stated periods with all active copies and the jobs that enforce them.

Search primary databases, CRMs, mailboxes, logs, exports and backups. A policy may promise a specific period while the application has no deletion job at all. It may also delete the visible record but retain attachments or event payloads indefinitely.

For each store, capture the configured period, the responsible job or manual process, failure monitoring and restoration behaviour. Counsel should confirm the period and exceptions. Engineering can then make the approved rule executable.

Consent descriptions must match state transitions

Bottom line: test what changes when the visitor chooses, rejects and later withdraws.

Many policies correctly describe categories while the website implements them incorrectly. Common failures include analytics loading before the consent interface, rejected services returning on the next page, a withdrawal control that deletes a cookie but leaves tags running, and category labels that do not match loaded services.

Create a state matrix and record observable results:

The legal team decides what belongs in each category. The test proves whether the deployed code follows that decision.

Fix the system before polishing the sentence

Bottom line: do not rewrite a notice to normalize unnecessary or accidental behaviour.

When a mismatch appears, use this order:

1. Confirm the observation and identify the component owner.
2. Ask whether the data flow is necessary for the intended feature.
3. Remove, minimise, localise or delay it where practical.
4. Obtain legal review for what remains.
5. Update the notice and internal records.
6. Add a regression test or release control.

Sometimes the policy is wrong. Sometimes the implementation is wrong. Often both are too vague because nobody had a complete flow map.

Keep the two synchronized after the audit

Bottom line: make privacy reconciliation part of normal delivery rather than an annual document project.

Add a short privacy question to feature briefs and pull requests: will this change collect, store, transmit, expose or delete user-related data? If yes, link the data-flow update, vendor review and required policy change to the same release ticket.

Monitor unexpected third-party hosts and storage keys on important templates. Review form destinations and retention jobs at a regular cadence. Give the privacy notice a technical owner as well as a legal reviewer.

The goal is not continuous legal redrafting. It is to prevent invisible architectural changes from bypassing the people responsible for accurate disclosure.

Frequently asked questions

Can an automated scanner compare my full site with my privacy policy?

It can flag domains, cookies, storage and some named vendors. It cannot see every backend copy or determine the correct legal basis. Use automation for evidence collection and a human for interpretation.

Should the policy list every technical supplier?

That depends on the role, context and applicable disclosure requirements. Provide counsel with a complete vendor and recipient map so they can decide the right level of detail.

Which should change first, the website or the policy?

First determine the intended and justified behaviour. Remove accidental or unnecessary processing, implement the approved design, then make the notice describe the resulting system.

How often should we reconcile them?

Review on material releases and vendor changes. A periodic full check is useful, but it should not be the first time anyone notices a new data flow.

Official references

• GDPR, including transparency obligations in Articles 12 to 14
• EDPB Guidelines on Data Protection by Design and by Default
• DSK guidance for telemedia providers

If you need the evidence first, run the free website check: it compares the providers named in your privacy policy with the ones your homepage actually contacts. Then see what a technical GDPR website audit can actually verify, why a cookie banner is not proof of control and our guide to hidden third-party requests.