Who is accountable when personal data leaks through the master record
Roles, formal accountability, and the day-to-day difference between controller, processor, and data protection officer.
When personal data escapes through a master record — a spreadsheet shared with a vendor, a notes field with health information, a database exported by someone who has already left — the first question is always "whose fault is it". That is the wrong question. The right one is: who is accountable, for which part, and what should each person have done beforehand.
The controller is the company, not a person
The controller is whoever decides on the purpose and means of processing. In practice it is almost always the company itself, as a legal entity. It is not the department manager or the IT team.
This has a direct consequence: accountability does not transfer to the employee who did the work. It may lead to internal employment consequences, but before the data subject and the authority, the controller answers.
The processor acts on the controller's behalf
The processor is whoever processes personal data on behalf of the controller — the payroll vendor, the email marketing service, the consultancy that received an extract to analyze.
The processor has its own obligations and is jointly liable when it breaches the instructions it received or the law. But note the inversion that tends to catch companies off guard: if the controller gave no written instruction, it is hard to argue that the processor breached it.
Hence the importance of a contract with a processing clause, limited purpose, a ban on subcontracting without notice, and an obligation to report incidents within a short deadline. Without that, a leak at the vendor becomes entirely your problem.
The DPO is not the designated scapegoat
The data protection officer — the DPO — is the communication channel with data subjects and with the authority, and advises the company. The DPO is not the one who answers for the incident, and should not be the one deciding on purpose: the business decides that.
A DPO with no access to decisions and no budget is a decorative figure. And a DPO who also runs the operation they are supposed to oversee has an obvious conflict of interest.
What changes in the master record
Three controls resolve most of the incidents that start there.
The free-text field is where unforeseen sensitive data gets in. "Notes" ends up holding health information, racial or ethnic origin, court cases. Restricting, guiding, and reviewing periodically is worth more than any policy.
Export without a trail is the second. Who can download the entire database, with what justification, and where that is recorded.
Access that outlives the person's departure is the third. Review access on HR events, not on a calendar.
When the incident happens
Contain first, document as you go. Record the time, what was known at each moment, and who decided what — that timeline is what supports the notification to the authority and to the data subject.
Assessing whether there is relevant risk to the data subject is a legal and business decision, and the criterion is not the wish to avoid exposure. Notifying late, having known early, makes things worse.
What to do beforehand
A contract with the processor. An inventory that says where sensitive data lives. A retention period with a purge routine that works. A record of the decision on legal basis.
None of these four is technical, which is why they tend to be missing.
Want to become a data governance specialist? Talk to our specialists now and get to know MDM Academy
I want to be a student
