Skip to main content

The Identity at the Core

The Definitive Chronicle of Identity & Access Management

EDPB adopts harmonized GDPR fining methodology and final DSA-GDPR guidelines

The EDPB set out a five-step method for when data protection authorities should fine under the GDPR and finalized its guidelines on how the DSA and GDPR interact.

By Paulo Barrilli
3 min read155 views0 comments

The European Data Protection Board used its 21 September plenary to adopt two sets of guidelines: one on when Data Protection Authorities should impose administrative fines under the GDPR, on their own or together with other corrective measures, and the final version of its guidelines on the interplay between the Digital Services Act (DSA) and the GDPR. The announcement is on the EDPB website.

The fining guidelines are the bigger story for anyone running identity systems that touch data on people in the EU. The GDPR gave DPAs a broad set of corrective powers, and fines are the one that shows up in board decks. What it did not give them was a shared method for deciding when a fine is the right tool rather than one of the other measures. The EDPB describes the new guidelines as "a major step in further aligning" how DPAs make that decision.

"The GDPR significantly increased the corrective powers of DPAs, with fines serving as an important instrument for effective enforcement. The guidelines reaffirm our commitment to providing greater clarity and ensuring the consistent application of the GDPR across Europe," said EDPB Deputy Chair Jelena Virant Burnik.

Anyone who has tried to predict enforcement outcomes across member states will know that "consistent" has so far described the ambition more than the result. A written method changes the conversation, because it gives organizations something concrete to point at when arguing about which end of the scale they belong on.

According to the EDPB summary, DPAs should follow a five-step methodology when deciding whether to impose a fine:

  1. Legal basis for a fine. The DPA checks whether the infringement can lead to a fine at all, by finding support either directly in the GDPR or in national law.
  2. Who can be fined. The DPA determines whether the party under investigation may be fined for the infringement in question. Whether the controller or the processor is liable depends on who is bound by the provision that was breached.
  3. Culpability. The DPA assesses whether the infringement was committed intentionally or negligently. A culpable infringement is a condition for imposing a fine.
  4. Aggravating and mitigating circumstances. The DPA weighs the factors that make the infringement more or less serious.

The EDPB's announcement does not lay out the fifth step in the same detail, and it does not summarize how the guidelines handle the choice between a fine and other corrective powers. Practitioners who need that level of detail should read the full guidelines rather than the press release.

Two of those steps land squarely on identity teams. Step 2 turns on the controller versus processor question, which is exactly where identity providers, CIAM platforms, directory services and outsourced workforce IAM tend to sit in a grey area. Who is bound by the breached provision decides who gets the invoice. Step 3 makes intent or negligence a precondition for a fine. That is the encouraging part, in a slightly backhanded way: a culpability test rewards the unglamorous work of documenting decisions, running access reviews on schedule and keeping the logs that prove you noticed. Boring, defensible evidence has rarely been worth this much.

The second adoption is the final version of the EDPB's guidelines on how the DSA and the GDPR interact. The announcement does not describe what changed from the earlier version, so organizations that follow both regimes will need to compare the texts themselves. For platforms that fall under the DSA, the practical question is which set of obligations governs which processing activity, and these guidelines are the EDPB's answer to that.

Neither set of guidelines creates new obligations for controllers or processors. They describe how regulators should reason. But knowing how the referee thinks is not a small advantage, and the EDPB has just published the referee's checklist.

Here is what I'd check this week. First, pull the data processing agreements behind your identity stack and confirm each one states clearly whether you are controller or processor for each flow, because step 2 of this methodology will ask exactly that. Second, make sure your access review records, incident timelines and risk acceptance decisions are written down and retrievable, since "negligent" is the word a DPA reaches for when there is no evidence anyone was paying attention. If your program already does both, congratulations, you have been quietly building a mitigation file this whole time.

#eu#policy#identity-governance#iga#ciam#gdpr#edpb
Share:XLinkedInFacebook

Be the first to comment

Members only: sign up if you have something worth saying.

Want to weigh in? Sign in or create a free account.

No comments yet.