Conduct a technical data privacy inventory for websites
An inventory records scripts, cookies, storage, endpoints, recipients, and forms within the company. Automatically detected items are professionally reviewed.
"Conducting a technical data protection inventory" is considered here from the perspective of "Data Protection Inventory and Responsibility." For website operators and data protection officers, "Multiple Levels of Observation" and "Scanner Blindness" are particularly important.
Published: 3 min read · Author: Sebastian Geier
What technical traces must a data privacy inventory of a website capture?
The inventory combines code and tag configuration, browser network, cookies and storage, server logs, forms, and vendor documentation. Each data flow is assigned triggers, fields, purpose, recipients, region, legal assessment, retention period, owner, and technical deactivation method.
Multiple levels of observation
Test criterion
Multiple levels of observation
[Note: The last sentence appears to be incomplete and unrelated to the preceding text. It has been omitted from the translation.]
Test criterion
State Coverage
Initial visit, rejection, consent, revocation, login, and relevant forms are tested as separate technical situations.
Actionable entry Each finding includes an owner, purpose, configuration, deletion or blocking method, and the next review period.
Actionable entry
Control signal
Signal 1
Proportion of relevant user paths and consent states with verified client, server, and receiver flows.
Control signal
Signal 2
Number of unknown or unaccounted-for data flows and the time until their classification.
Scanner blindness
Scanner blindness An automated crawl may not detect logged-in, interactive, or server-side transmissions and may miss vendors.
Snapshot Experiments, tag manager changes, and conditional features may generate different data flows outside of the audit time.
Document without operation An inventory quickly loses value if releases and new vendors do not trigger an update process.
Diagnostic Case: "Scanner Blindness"
The scanner detects analytics cookies, but only a submitted form triggers server-side forwarding to a ticketing system. The inventory connects both levels, documents fields and deletion paths, and adds the form path as a fixed release test.
State Coverage
Systems, page types, states, and user paths are defined as the risk-based inventory scope.
Network, storage, servers, tags, forms, and vendor targets are recorded and aggregated for each state.
Findings are assigned to owners and corresponding actions; a release process updates the inventory in the event of technical changes.
Questions that remain after "Conducting a Technical Data Protection Inventory"
A relevant follow-up question answered Enabling Revocation and Subsequent Changes in a Technically Clean Manner"How does a website technically implement revocation and subsequent changes to consent?"
A second link for "Conducting a Technical Data Protection Inventory" leads to Fully test tracking and consent before launch.. This article remains focused on the question “How can tracking and consent be fully and realistically tested before go-live?”
If you want to practically implement "Conducting a Technical Data Protection Inventory," you can refer to Robust Website Systems This focuses on "Data Protection Inventory and Responsibility" and "Multiple Levels of Observation."
Conclusion: Conducting a Technical Data Protection Inventory
A technical inventory describes actual processing across all runtime levels. Its value arises from state coverage and a continuous connection to the change process.
Sources and Further Information
The following sources document the technical and methodological guidelines used for "Conducting a Technical Data Protection Inventory."
Guidelines 05/2020 on Consent – European Data Protection BoardOfficial European interpretation of the organizational and evidence-based requirements for consent.
General Data Protection Regulation – EUR-LexPrimary source on accountability, information obligations, records of processing activities, and the roles of controllers and processors.
Key Thesis
Source code, network traffic, browser memory, forms, server logs, and integrations in multiple states are examined. Each finding is recorded with its purpose, owner, recipient, and permitted execution.
What This Is Not About
A data privacy inventory is neither a simple cookie list from a scanner nor a one-off document from the legal department.
What it's about
It captures real data sources, scripts, requests, storage, recipients, purposes, consent dependencies, and retention across typical user paths.
Consent, data protection & tracking quality
Systematically test for consent errors after releases
The "Conducting a Technical Data Protection Inventory" includes, as a separate audit step, the question: Which consent scenarios should be automatically checked after each website release?
Consent, data protection & tracking quality
Configuring Tag Manager to prevent consent rules from being bypassed
Supplements "Conducting a Technical Data Protection Inventory" with a separate decision: How can we prevent a tag manager from circumventing defined consent rules?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Actionable entry: Starting point for implementation
A typical first visit and a critical form path constitute the initial scope of the inventory. Both are fully tracked from the client, server, and recipient perspectives.