The Hellenic supervisory authority's decision on a personal data breach at E.E.T.A.A. S.A. offers a valuable lesson for compliance teams. The breach affected databases containing identification, contact details, financial data, and health data. The Ministry of Social Cohesion and Family Affairs, as the controller, notified the supervisory authority and the affected data subjects correctly but was still fined EUR 200,000. E.E.T.A.A., as the processor, was fined EUR 150,000.
The takeaway isn't that notification is unimportant. It's that both parties were penalized for the same underlying weakness, and the controller's clean notification record didn't shield it.
Decisions You Need to Make
You're reviewing a processing relationship, either as a controller or processor, and need to decide what to address first. Resources are limited. The case suggests three exposure points in a predictable sequence: the written agreement under Article 28, the technical condition of the processor's systems under Article 32, and the controller's oversight of both.
The decision tree below helps you choose your starting point based on where your relationship is weakest today.
Key Factors Affecting Your Choice
Answer these four questions before choosing a path.
- Is there a signed agreement covering this specific processing? The Hellenic authority ordered the Ministry and E.E.T.A.A. to enter into a data processing agreement under Article 28, indicating a gap existed even though the processor was operating live systems for the controller.
- Do you know the age and support status of the systems that handle the data? The authority linked the attack's success to outdated information systems and noted E.E.T.A.A. was aware of the relevant risks.
- Is there a documented risk decision? Awareness of a risk without remediation was seen as an aggravating factor. A known, unmanaged risk is harder to defend than an unknown one.
- What data categories are involved? Health and financial data require higher levels of technical and organizational measures under Article 32, due to the increased risk to data subjects.
Path A: The Agreement is Missing, Outdated, or Generic
Choose this path if you can't produce a signed agreement that matches the current scope of processing, or if your template hasn't been reviewed since the relationship began.
Article 28(3) requires a binding contract or other legal act. It must set out:
- The subject matter, duration, nature, and purpose of the processing;
- The type of personal data and categories of data subjects;
- Processing only on documented instructions from the controller;
- Confidentiality commitments for authorized personnel;
- Security measures required under Article 32;
- Conditions for engaging sub-processors;
- Assistance with data subject rights, Articles 32 to 36 obligations, and breach handling;
- Deletion or return of data at the end of the services;
- Audit and inspection rights, and an obligation to provide information demonstrating compliance.
If you're the controller, then treat a missing agreement as your responsibility as much as the processor's. Article 28(1) places the duty to use only processors providing sufficient guarantees on you. The Hellenic outcome, where the controller was fined alongside the processor and both were ordered to formalize the agreement, reflects that shared exposure.
If you're the processor, then don't wait for the controller to initiate. Propose your own compliant terms. Article 28(3) obligations bind you directly, and Article 28(10) makes you a controller if you determine purposes and means outside the controller's instructions.
Watch for: an agreement that lists security measures in generic terms. If the contract says "industry-standard security" and nothing more, it won't help either party show that the measures were appropriate.
Path B: The Agreement Exists but Systems Are Weak
Choose this path if you have a compliant Article 28 contract but your processor, or you as processor, runs legacy infrastructure, unsupported software, or unpatched components.
Article 32(1) requires measures appropriate to the risk, considering the state of the art and the cost of implementation. Outdated systems are hard to align with "state of the art," especially where health and financial data are involved.
If you're the processor, then follow this sequence:
- Inventory every system that stores or accesses controller data, with its support status.
- Flag anything where the processor no longer issues security updates.
- Record a risk decision for each flagged item: remediate by a set date, apply documented compensating measures, or escalate to the controller.
- Report the decision to the controller. Silence is not a mitigation.
If you're the controller, then your Article 28(1) due diligence should ask for evidence, not assurances. Request patch cadence, end-of-life system lists, penetration test summaries, and remediation timelines. Use your audit right under Article 28(3)(h) and document that you did.
The authority also ordered the parties to fully implement planned security measures. Planned but unexecuted remediation carries no weight, and a stalled roadmap is a liability once a personal data breach occurs.
Path C: Both Are in Place but Oversight Is Thin
Choose this path if the contract is sound and the systems are reasonably current, yet nobody checks whether the contract's promises are being kept.
If you're the controller, then build a recurring review into your governance calendar: confirm the processor's sub-processor list, re-test breach notification handoffs, and re-score risk when data categories change. Article 24 requires you to implement measures and be able to demonstrate compliance, and Article 5(2) makes accountability a core principle.
If you're the processor, then remember Article 33(2): you must notify the controller without undue delay after becoming aware of a personal data breach. Rehearse that handoff. The Ministry's timely notification to the authority and data subjects shows the controller-side process worked; your job is to make the processor-side process equally dependable.
Summary Matrix
| Your Situation | Start Here | Primary Driver | First Action |
|---|---|---|---|
| No signed or current agreement | Path A | Article 28(1), 28(3) | Execute an agreement covering all mandatory terms |
| Agreement in place, legacy or unsupported systems | Path B | Article 32(1) | Inventory systems, record risk decisions, set remediation dates |
| Agreement and systems adequate, no routine checks | Path C | Articles 5(2), 24, 33(2) | Schedule audits and breach handoff tests |
If you recognize more than one row, work in order: agreement, systems, oversight. The agreement defines who must do what, the systems determine whether it can be done, and oversight proves it is being done. A supervisory authority reviewing a breach will look for all three, and as the Hellenic decision shows, a gap in any one can cost both parties.
