Personal data compliance is not just a legal problem
Data architecture and access controls directly shape legal risk. Technical decisions made today will become legal problems tomorrow.
When a company starts dealing with personal data regulations, the first instinct is to call the lawyers. They will draft the policy, prepare consent forms, and put together the documentation package for the regulator. That is the right step, but it is not enough.
The problem is that a lawyer does not see how data actually moves inside the system. They work with what is written in documents. And the gap between the document and the real architecture is exactly where the risk lives.
I have seen companies with impeccable documentation where customer personal data was quietly sitting in a developer test database, being copied into Excel for "quick analysis", and flowing into third-party services with no contractual basis. The lawyers did not know, because nobody told them.
Where the risk actually lives
Legal risk around personal data is not concentrated in documents. It lives in three places: actual storage locations, access rights, and data flows.
First - storage locations. Does the company actually know where personal data physically resides? Not in theory - in practice. Every copy, every backup, every intermediate store. In practice the list is always longer than it appears.
Second - access rights. Who has access to what data, and on what basis? In most mid-size companies this is not managed systematically. Access is granted on request, accumulates over years, and is never reviewed.
Third - data flows. Where does data go after it enters the system? Which integrations, which analytics tools, which external services touch it? Each of those points is either a documented transfer agreement or an unrecorded risk.
Why this is a technical question, not just a legal one
The Russian regulatory framework has also moved in this direction - FSTEC Order 21 explicitly ties protection levels to the actual nature of systems, not just paperwork. A lawyer can write a correct data processing policy. But they cannot physically restrict access to a table in a database. They cannot set up data masking in test environments. They cannot ensure that all operations on personal data are logged.
Those things are done by the architect or the developer. And if they make decisions without considering data protection requirements, no document will fix that afterwards.
Specific things that need to be resolved at the system level:
- separate data by sensitivity tier and restrict access at the database schema level, not only in the application layer;
- test and analytics environments should not contain real personal data - either anonymise or use synthetic data;
- integrations with external systems must be documented and have a contractual basis before data starts flowing through them;
- log access to sensitive data - not everything, but the data for which obligations exist.
Where the gap typically appears
In most projects I have seen, the gap opens up when technical and legal teams work in parallel and never meet.
Lawyers write documents based on an ideal model. Developers build the system based on convenience and speed. When the documents and the system finally come together, they often turn out to describe different realities.
The fix is organisational: you need a point of intersection where technical decisions are checked against legal requirements, and legal requirements are translated into specific technical constraints. This is not an annual audit. It is involvement at the architectural decision stage.
Diagnostic questions
A few questions that let you quickly assess the real state of things:
- Is there an up-to-date map of all personal data storage locations - based on fact, not documents?
- Have test and analytics environments been verified to contain no real data?
- When were access rights to sensitive data last reviewed?
- Are all external integrations that transmit data covered by contracts?
- Do developers know which specific fields count as personal data in each system?
If at least two of these questions have no clear answer, the problem is not in the documents. It is that the legal and technical parts are living in separate worlds.