Personal data protection done properly: it starts with a data flow model
Without a map of data flows you cannot honestly build either security controls or compliance - you are just patching random holes.
When a company starts thinking about protecting personal data, the first instinct is usually to buy something. A DLP system, encryption, an antivirus with a monitoring module. Or hire a consultant to write a privacy policy. I have seen the result of this approach many times: a set of technical measures that protect what is visible and completely miss what poses the real risk.
The problem is almost never a lack of security tools. The problem is that the company does not know what it is protecting.
What a data processing model is and why it matters
A data processing model is a description of where personal data lives in the company, where it comes from, where it goes, who works with it, and how long it is retained. This is not a document for the regulator - it is a tool for understanding.
Without such a model, the question "how protected are we" has no meaning. Protected from what? Where? What data are we even processing?
A typical picture: CRM stores customer contacts, the mail server holds correspondence with them, the accounting system holds financial data on individuals, and support holds the history of requests. The marketing department exports the database to Excel for a mailing campaign. That Excel file ends up on a laptop the employee takes home. Between these points there are several more: integrations, third-party service APIs, backups.
This is not paranoia - it is a standard picture for a mid-sized business. Until it is drawn out explicitly, any protective measure will patch random holes rather than systemic ones.
How to build the model
Start not with technical systems but with business processes. Which processes in the company involve collecting data about people? Sales, HR, support, marketing, delivery. For each process - where does data come from, where is it stored, who has access, where can it go.
The output should be a map. It does not need to be polished - it needs to be complete. Every point where personal data exists must be visible.
After that it becomes possible to ask the right questions: which points are most vulnerable? Where is the most sensitive data concentrated? Where is data being transferred to third parties without a clear legal basis?
What this changes in the security approach
Once the model exists, security measures stop being arbitrary. Encryption is not needed everywhere - only where data is stored or transmitted with high risk. Access control is configured against real roles rather than whoever asked loudest. Log auditing makes sense where there is actual access to sensitive data.
The same approach applies to compliance. Data protection law requires a set of organisational and technical measures - but fulfilling them without understanding what is actually being processed turns into paperwork that does not reduce real risk.
A regulator inspecting the company looks not only for the existence of a policy but for whether actual practice matches what the policy says. You can only verify that if you have a model.
Where to start
A few practical questions for an initial assessment:
- Can you name right now every system that stores your customers' personal data?
- Do you have a list of third parties to whom this data is or could be transferred?
- Do you know what happens to data when an employee leaves - access rights, copies, devices?
- Is there a process by which a customer can request deletion of their data and you can actually execute it?
- When did someone last review the access rights to databases containing personal data?
If most of these questions have no clear answer, the problem is not a lack of security tools. The problem is a lack of a model. That is exactly where to begin.