GDPR: what actually changes for product data
May arrived and panic came with it. Most teams we spoke to didn't have a legal problem. They had an inventory problem.
The deadline of May pushed a lot of companies into a genuine panic. Most conversations we had were not about legal exposure at all. They were about not knowing where their data actually lived or who had access to it. A simple inventory question turned out to be harder than interpreting the regulation itself.
We built a data map for four clients this quarter. It documents tables and fields, tracks retention periods and identifies who reads what. The exercise takes roughly two weeks and almost always deletes more database columns than it documents, which never fails to surprise the teams running through it.
The visible part of GDPR is the consent mechanism, the cookie banner, the policy text. The real work is somewhere else entirely: deletion. If you cannot remove a user profile and all their traces with one command, you fail the audit, regardless of how precise your cookie banner appears.
User data lives in more places than anyone initially thinks. A database gets backed up and backups live around indefinitely. Logs mention usernames and email addresses. Derivatives sit in caches and analytics systems. One client found user records in a service they had discontinued four years earlier and completely forgotten about.
We started by building deletion paths before touching policy or updating consent language. Because once you know what you can actually remove, you know what you need to retain and most importantly why. The policy then writes itself from that technical reality rather than regulatory interpretation.
The lesson that matters is that compliance starts with inventory, not interpretation. Not lawyers reading the regulation or vendor consultants. Just knowing what you have, where it lives, and whether you can actually remove it when someone asks to do so legally and technically.