GDPR: lessons from the first months of enforcement
What the first weeks of real GDPR enforcement revealed, and how it changes the practical approach to handling personal data.
The GDPR came into force on 25 May 2018. A few months have passed - enough for the first patterns to become visible: what companies got wrong, where practical difficulties arise, and what the regulator is signalling with its early actions.
I work with companies that either process European user data directly or use European services in their infrastructure. The main conclusion I have reached in these months: most problems appear where companies did not expect them.
What companies get wrong
The most common misconception is thinking that GDPR is about legal documents. Add a cookie consent banner, update the privacy policy, collect checkboxes - and that is it.
The regulation requires something different: knowing where personal data sits, being able to find it, export it, and delete it on request. This is a technical and organisational challenge, not a legal one.
Companies that handled data informally - where user data has spread across a dozen systems, Excel files, and email inboxes - discover they cannot answer a basic question: where is the information about a specific person stored?
Three practical problems
Data mapping. Before you can protect something, you need to know what you have and where it lives. Most companies lack this understanding. They do not have a record of processing activities not because they are lazy, but because data accumulated over years without documentation.
The right to erasure. When a user asks to have their data deleted, the system must do it - in every place where the data exists. If data from a CRM is duplicated in an analytics database, in backups, and in mailing lists, technically ensuring deletion is far harder than it looks.
Breach notification. GDPR requires notifying the regulator of a data breach within 72 hours. This means the company must have a process for detecting an incident, classifying it, and reporting it - and the process has to actually work, not just exist in documentation.
What changes in approach
Treating GDPR purely as a compliance task means seeing only the surface. Companies that take it seriously use it as an opportunity to do what should have been done long ago: understand where and what data is stored, and establish ownership of its correctness and security.
That is useful regardless of fines.
A practical filter
A few questions worth asking right now:
- Do we have a record of processing activities - a list of systems, data types, and legal bases for processing?
- If a user asks to see all data held about them, can we collect it in a reasonable time?
- If a user asks for deletion, do we have a technical process that covers all systems?
- Do we have an incident response process for personal data breaches, and have we actually tested it?
- Who in the company is responsible for these questions and makes decisions when product interests conflict with data protection?
Honest answers to these questions will give a more accurate picture of real readiness than any legal document.