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

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.

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

Why 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.

The KYC Problem

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.

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.

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 “Good” Looks Like

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.

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 Architecture Matters More Than Policy

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.

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.

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.

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.

The Bottom Line

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.