The Hellenic Data Protection Authority's decision against E.E.T.A.A. S.A. and the Ministry of Social Cohesion and Family Affairs raises a tough question: when your processor's outdated systems cause a breach, who bears responsibility?
The answer isn't as straightforward as your contracts might suggest.
The question at hand
You've chosen a processor, signed an agreement, and checked their SOC 2 report. Then they get breached because they're running systems from 2015. Now you're explaining to your board why the controller paid EUR 200,000 in fines while the processor, who maintained the vulnerable infrastructure, paid EUR 150,000.
The debate centers on how much responsibility controllers should have for their processors' security failures. One view argues that Article 28 GDPR creates clear obligations: processors must implement appropriate technical measures, and controllers must choose competent processors. If the processor fails, they're liable under Article 82. The other side points out that controllers bear ultimate accountability to data subjects and regulators, no matter where the failure occurred in the processing chain.
Both positions have regulatory support and create real operational challenges.
The case for strict processor accountability
Article 28(3)(c) GDPR requires processors to implement appropriate technical and organizational measures. When E.E.T.A.A. continued using outdated systems despite knowing the risks, it was a direct failure of processor obligations. The processor controls the infrastructure, deciding whether to patch systems, upgrade databases, or maintain legacy platforms.
Shifting too much scrutiny to controllers creates perverse incentives. Processors might defer necessary security investments, knowing regulatory pressure will fall on their clients. This leads to controllers conducting endless audits and assessments, duplicating work the processor should be doing.
The Hellenic DPA's EUR 150,000 fine against E.E.T.A.A. reflects this principle. The processor had the technical knowledge and operational control but chose not to act. Accountability should land there.
This approach aligns with commercial reality. Large processors serve many controllers. If each controller must verify every security control, it creates an audit nightmare that doesn't improve security. It's better to hold processors to clear standards and enforce those obligations directly.
The case for controller oversight responsibility
Article 28(1) GDPR requires controllers to use processors that provide "sufficient guarantees" for technical and organizational measures. "Sufficient" means you can't just accept a processor's self-assessment. You need to verify.
The Ministry of Social Cohesion and Family Affairs paid EUR 200,000 despite properly notifying the breach and communicating with affected data subjects. Why? Because choosing and monitoring a processor is a controller obligation. Selecting a processor with outdated systems means failing your Article 28(1) duty before the breach even occurs.
This isn't theoretical. Controllers have direct relationships with data subjects. When health data and financial information are exposed, data subjects don't care whether the failure happened at the processor or controller level. They care that the controller they trusted failed to protect their information.
The EDPB Guidelines make this clear: controllers must conduct due diligence before engaging a processor and monitor compliance throughout the relationship. This means technical assessments, not just contract reviews. If you're processing sensitive data through a third party, you need to verify their patch management, access controls, and incident response capabilities.
You can't outsource accountability. You can only outsource processing activities.
Where practitioners actually land
Most privacy officers and security teams operate in the messy middle. You conduct initial due diligence, require annual SOC 2 Type II reports, and include standard Article 28 language in your data processing agreements. Then you hope the processor maintains the controls they've documented.
The Hellenic DPA's order for the parties to enter into a proper data processing agreement under Article 28 GDPR suggests they didn't have adequate contractual protections before the breach. This is common in legacy relationships, especially with government processors or long-standing vendors where the relationship predates GDPR.
Your practical challenge isn't choosing between controller oversight and processor accountability. It's building a verification program that scales. You can't audit every processor's patch management schedule. You can require:
- Annual attestations of security control implementation
- Notification requirements for material changes to processing systems
- Specific upgrade commitments in your processing agreement
- Breach notification within defined timeframes with root cause analysis
When processors resist these requirements, it reveals something valuable about their security posture.
Our take
The Hellenic DPA got the balance right. Both parties paid fines because both failed distinct obligations.
E.E.T.A.A. violated Article 32 GDPR by maintaining inadequate security measures despite knowing the risks. That's a processor obligation, and the EUR 150,000 fine reflects it. The Ministry violated Article 28(1) GDPR by failing to ensure their processor provided sufficient guarantees. That's a controller obligation worth EUR 200,000.
The lesson isn't that controllers should micromanage processor security. It's that you need verification mechanisms built into your processing relationships from the start. Your data processing agreement should require specific security commitments, not just general language about "appropriate measures." You should have contractual rights to security documentation and material change notifications.
When a processor tells you they can't provide evidence of their patch management process or their system upgrade timeline, you're not being unreasonable. You're meeting your Article 28(1) obligation to verify sufficient guarantees.
The uncomfortable truth: if your processor is running outdated systems and you didn't know, you've failed controller due diligence. If you did know and continued the relationship without remediation commitments, you've accepted the risk. Either way, the fine letter will have your organization's name on it too.
