GDPR Transparency Enforcement 2026: What the EDPB Sweep Means for KYC

Key highlights

• The European Data Protection Board launched coordinated GDPR transparency enforcement, with 25 national data protection authorities examining whether organisations clearly explain how they collect and use personal data.
• Regulators are focused on Articles 12 through 14: what you tell people about your data processing, when you tell them, and how clearly you say it.
• KYC flows are exposed because they collect highly sensitive data (government IDs, facial images, proof of address, financial records) while hiding the details on page 17 of a 30-page company privacy policy.
• Coordinated enforcement means a failure found in one country triggers scrutiny in another, and 25 regulators are checking simultaneously after years of tolerating gradual adoption.
• Good transparency means a focused notice at the moment a check begins: what data, which provider, how long it is stored, and how to request deletion, not the general privacy policy.
• Transparency is an engineering requirement, not a legal document. Architecture that never duplicates the data makes the obligation simpler to meet.

GDPR transparency enforcement is the EDPB's coordinated 2026 action where 25 national data protection authorities check whether organisations clearly explain, under Articles 12 to 14, how they collect and use personal data. For KYC and identity verification, that means showing users a specific, plain-language notice at the moment of collection: what data you take, who receives it, how long you keep it, and how they can request deletion. This is active enforcement, not a consultation paper.

25 EU Regulators Are About to Check Your Privacy Notices. Most KYC Flows Will Fail.

The European Data Protection Board just launched coordinated enforcement on GDPR transparency obligations. That means 25 national data protection authorities, working together, examining whether organisations properly explain how they collect and use personal data. They’re specifically looking at Articles 12 through 14, which cover what you tell people about your data processing, when you tell them, and how clearly you say it.

Europe's wider identity rules are shifting too, as we explain in the eIDAS 2.0 digital identity wallet guide.

If you run identity verification or KYC workflows in Europe, pay attention. This isn’t a consultation paper. It’s active enforcement.

Why is the EDPB targeting transparency, and why now?

The EDPB picked this topic after looking at enforcement data across member states and finding the same gap everywhere: organisations collect personal data while providing vague, legalistic, or effectively invisible information about what they’re doing with it. Privacy policies have become legal artifacts that exist to protect the company, not to inform the user.

Everyone knows this. Every compliance professional I’ve talked to knows their privacy notice is too long and too dense. The difference now is that 25 regulators are going to start checking, comparing notes across borders, and generating pan-European insights. A failure found in Ireland will trigger scrutiny in Germany. That’s the point of coordinated enforcement.

The GDPR has required clear, accessible transparency since 2018. Regulators tolerated gradual adoption for years. That patience has run out.

Why do most KYC flows fail GDPR transparency?

Identity verification workflows collect extremely sensitive data. Government IDs. Facial images. Proof of address. Financial records. Sometimes biometric templates and criminal background checks. The transparency requirements for this kind of processing are correspondingly high.

The same sensitivity drives the wider data risk we map in why centralized PII storage is your biggest liability.

But look at how most KYC flows actually handle it. There’s a checkbox at the bottom of a form, linking to a 30-page privacy policy that covers the entire company’s data processing. Somewhere on page 17, there’s a paragraph about identity verification that uses phrases like “we may process your personal data for the purposes of regulatory compliance” without specifying what data, which regulators, how long it’s kept, or who else sees it.

When a user uploads their passport for verification, do they know who will view it? Where it’s stored? When it gets deleted? Whether it’s sent to a third-party provider? In most implementations, the answer is no. That’s the gap the EDPB is targeting.

We break down whether that data is actually safe in the math on KYC safety after the IDmerit breach.

The identity verification industry has grown fast, and transparency hasn’t kept pace with the data collection. Companies added more data points, more verification steps, more third-party integrations, while their privacy notices stayed the same generic paragraphs they wrote when they launched. That worked when no one was checking. Now 25 regulators are checking simultaneously.

What does good GDPR transparency look like for KYC?

Article 12 says information must be “concise, transparent, intelligible and easily accessible, using clear and plain language.” Article 13 lists specific things you must tell people when you collect data directly from them: who you are, what you’re collecting, why, the legal basis, who receives it, retention periods, and their rights.

Privacy and compliance often pull against each other, a tension we examine in balancing privacy and compliance.

In practice, this means: at the moment someone starts a KYC check, they should see a clear, specific explanation of that check. Not the company’s general privacy policy. A focused notice that says: we’re about to verify your identity using your passport and a selfie, we’ll share this with [specific provider], it’ll be stored for [specific period], and here’s how to request deletion.

It sounds simple. It’s hard to implement well, especially if your identity infrastructure wasn’t designed for it. Which brings us to architecture.

Why does architecture matter more than policy here?

You can write a perfect privacy notice and still have a transparency problem if your infrastructure makes it impossible to deliver that notice at the right moment, or if the actual data flows don’t match what the notice describes. Transparency isn’t a legal document. It’s an engineering requirement.

Zyphe’s decentralised identity architecture was designed with this in mind. Users see exactly what data is being requested and by whom, because the architecture makes this visible by default. Consent is specific to each verification request, not a blanket authorization. Data stays with the user until they explicitly share it for a specific purpose. When a regulator asks how you informed users, the answer is built into the product, not stored in a legal PDF.

You can see how this model works end to end in decentralised KYC explained.

This approach also avoids the secondary problem with centralised KYC: data duplication. Every copy of someone’s passport is another transparency obligation. If you never hold the data in the first place, the transparency conversation gets much simpler.

Holding less data also cuts the breach surface we describe in why your KYC vendor is your biggest data breach risk.

What should you do before the sweep reaches you?

Test your privacy notices with actual users, not lawyers. Hand someone your KYC privacy notice and ask them to explain back what data you collect and why. If they can’t, rewrite it until they can. Compliance teams write notices for regulators, but regulators are now checking whether the notices work for people.

Audit every KYC touchpoint against Articles 12 through 14. Check timing (does the notice appear before data collection?), specificity (does it cover this specific process or just the company generally?), and accessibility (can a non-expert understand it?). Map your actual data flows against your privacy notice. If the notice says data is stored for 12 months but your system keeps it for 36, you have a compliance gap that a coordinated enforcement action will find.

Retention is its own trap, which we cover in the data retention risk nobody names.

Prepare evidence of your transparency practices now. Document how notices are delivered, when consent is collected, how withdrawal works, and how you handle access requests. When the EDPB’s coordinated enforcement reaches your sector, the firms with documentation ready will have a much easier time than those assembling it under pressure.

When is a perfect privacy notice not enough?

A well-written notice does not solve the problem on its own. You can write a perfect privacy notice and still fail transparency if your infrastructure cannot deliver that notice at the right moment, or if your actual data flows do not match what the notice describes. If your notice says data is stored for 12 months but your system keeps it for 36, the coordinated enforcement action will find that gap.

Treating this purely as a legal exercise is the wrong call. Transparency here is an engineering requirement, not just a legal document. Teams that test notices with real users instead of lawyers, audit every KYC touchpoint against Articles 12 through 14, and map actual data flows against what they promise will handle the sweep best.

What is the bottom line for KYC teams?

Twenty-five regulators are now coordinating on a single question: are you telling people what you’re doing with their data, clearly, at the right time? For KYC and identity verification, where the data is sensitive and the processing is complex, this is going to be uncomfortable for a lot of organisations. The ones who treat it as an engineering problem, not just a legal one, will handle it best.

This sweep fits the broader pattern we track in compliance enforcement in 2026.