GDPR: personal data becomes an architecture problem
What GDPR changes in how companies must design their systems, not just what policies to write.
Today GDPR comes into force. Most companies have spent the last months updating privacy policies, consent forms and legal documents. That is necessary work - but it covers only the visible part of the requirements.
The less visible and more demanding part is what GDPR requires companies to change in the architecture of their systems, not just in their documents. That is what I want to work through today.
What GDPR requires from systems
Three GDPR requirements directly affect how systems must be built:
First - the right of access. A person can request what data the company holds about them. If data is scattered across dozens of disconnected systems, answering that request within a month (the regulatory deadline) is physically impossible without manual work.
Second - the right to erasure. A person can ask for their data to be deleted. If copies of data live in multiple systems, backups, analytics warehouses and logs - "deletion" becomes a project, not an operation.
Third - data portability. A person can request their data in a machine-readable format. This requires data to be structured and attributed to the individual subject - not just stored somewhere.
Why this is an architecture problem
None of these three requirements can be met simply by updating the privacy policy. Meeting them requires:
- knowing which systems hold personal data about a specific person;
- being able to link different records to one subject (person);
- being able to extract or delete that data technically - without manually searching through databases;
- maintaining a log of who accessed personal data and when.
These are requirements for how data and systems are built - not for what is written in documents.
The principle of privacy by design
GDPR introduces a concept called privacy by design - personal data protection must be built into systems at the design stage, not added later as a layer on top.
In practice this means several things:
Data minimisation - collect only what is genuinely needed for a specific purpose. This is the opposite of the "collect everything in case it comes in handy" approach.
Purpose limitation - data collected for one purpose should not be used for another without additional consent.
Access restriction - access to personal data should belong only to those who need it for their work. Not to the whole company "just in case".
Retention periods - data must be deleted when the purpose for storing it is exhausted. This requires automated processes, not a manual decision each time.
What changes for new projects
For companies designing new products or systems now, GDPR creates clear architectural requirements from the outset.
When designing any system that works with personal data, you now need to answer:
- What data exactly are we collecting and for what purpose?
- Where will it be stored and for how long?
- How will we respond to deletion or access requests?
- Who has access and how do we log that access?
- How is the data protected - and what happens in the event of a breach?
This is not a legal checklist. These are technical requirements that must be embedded in the system design.
The long-term shift
GDPR is the first, but not the last, regulatory act of this kind. Similar laws are already being discussed or adopted in other jurisdictions. The privacy by design approach that GDPR requires today for European users will likely become the standard in most regions within a few years.
Companies that build this architecture now - not because they fear fines, but because they understand it is the right approach - will be in a significantly better position. Both technically and in terms of customer trust.