How does the EUDI Wallet affect GDPR compliance for organisations?

The EUDI Wallet does not replace GDPR — it operates alongside it.

The EUDI Wallet does not sit outside GDPR. Organisations that accept or process credentials from the European Digital Identity Wallet remain fully subject to GDPR obligations. The EUDI Wallet is designed to reinforce several of GDPR’s core principles, particularly data minimisation and user control. The sections below cover the most important compliance questions organisations need to answer before integrating wallet-based identity into their services.

Does the EUDI Wallet replace or complement GDPR?

The EUDI Wallet complements GDPR. The two frameworks operate in parallel: eIDAS 2.0, which amends Regulation (EU) 910/2014 through Regulation (EU) 2024/1183, governs how digital identity credentials are issued, stored, and presented, while GDPR continues to govern how organisations collect, process, and store personal data. Any personal data that flows through a wallet interaction remains subject to GDPR from the moment an organisation receives it.

This distinction matters in practice. The EUDI Wallet gives users a privacy-preserving tool to share only the data they choose. Once an organisation accepts and processes that data, GDPR’s full set of obligations applies, including the need for a lawful basis, data retention limits, and the right to erasure. The wallet does not create a GDPR exemption, and it does not transfer responsibility away from the receiving organisation.

What eIDAS 2.0 does add is a stronger technical foundation for privacy by design. The architecture is built around selective disclosure and minimal data sharing, which aligns naturally with GDPR’s principles. For organisations in regulated sectors such as finance, government, and healthcare, the two frameworks can work together to strengthen overall compliance posture.

How does the EUDI Wallet support data minimisation under GDPR?

The EUDI Wallet directly supports GDPR’s data minimisation principle by enabling users to share only the specific attributes a service actually needs. Instead of presenting a full identity document, a user can disclose a single verified claim, such as proof of age or nationality, without revealing any additional personal information. This selective disclosure capability is built into the wallet’s technical architecture.

Under GDPR, data minimisation requires organisations to collect only data that is adequate, relevant, and limited to what is necessary for the stated purpose. The EUDI Wallet makes this easier to achieve in practice. For example, an organisation verifying that a user is over 18 no longer needs to receive and store a full date of birth. An age attestation derived from a verified credential, disclosing only the attribute “older than 18”, is sufficient and more privacy-compliant. Zero-knowledge proofs are not required for this; selective disclosure of a single attribute achieves the same result.

For organisations, this creates both an opportunity and a responsibility. The opportunity is to reduce the volume of personal data they handle, which lowers risk and simplifies compliance. The responsibility is to actively design their wallet integration to request only what is genuinely necessary. GDPR’s data minimisation principle requires a deliberate choice, and the wallet’s technical capabilities make that choice easier to act on.

What lawful basis applies when processing EUDI Wallet credentials?

There is no single lawful basis that applies to all EUDI Wallet interactions. The correct legal ground depends on the purpose of the processing and the context in which the wallet credential is used. Organisations must identify and document their lawful basis before they begin processing wallet-derived data, just as they would for any other form of personal data processing under GDPR.

The most common lawful bases that apply in wallet scenarios include:

• Contract performance: When processing is necessary to deliver a service the user has requested, such as opening a bank account or accessing a digital platform.
• Legal obligation: When a regulatory requirement mandates identity verification, such as Know Your Customer checks in financial services or age verification under sector-specific rules. For KYC purposes, the lawful basis is typically this legal obligation, not consent.
• Legitimate interests: In some cases, where the organisation has a genuine interest that is not overridden by the individual’s rights, though this requires a careful balancing test.
• Consent: Relevant in specific contexts, but consent alone is rarely the most appropriate basis for identity verification, and it must be freely given and withdrawable.

One important distinction: the fact that a user has voluntarily presented a wallet credential does not automatically mean consent is the correct lawful basis. Approving a data request in the wallet and giving consent as a GDPR legal ground are not the same thing. The user approves each individual presentation request in the wallet. That approval is a technical action, not a GDPR consent. Organisations should assess the purpose of each wallet interaction separately and document their reasoning.

Where health data is involved, a lawful basis under GDPR Article 6 is necessary but not sufficient. Processing special category data also requires a specific ground under Article 9(2) of GDPR.

Who is the data controller when an organisation accepts a wallet credential?

When an organisation accepts and processes a credential from an EUDI Wallet, it acts as the data controller for that processing activity. Responsibility for what happens to the data once it has been presented rests with the receiving organisation. Each party in the eIDAS 2.0 governance structure operates within its own defined role: wallet providers are responsible for the wallet solution itself, while issuers of Person Identification Data and attestations are accountable for the credentials they issue. GDPR’s controller responsibilities attach to the organisation that determines the purpose and means of processing the received data.

A vendor that processes wallet data on behalf of a client organisation does not become the data controller by doing so. The registration obligation under CIR (EU) 2025/848 of 6 May 2025 rests with the organisation that delivers the service to the end user, not with the technical provider acting on its behalf.

As the data controller, the accepting organisation must:

1. Have a documented lawful basis for the processing.
2. Inform the data subject about how their data will be used, typically through a privacy notice.
3. Ensure the data is not retained longer than necessary.
4. Respond to data subject rights requests, including access, correction, and erasure.
5. Implement appropriate technical and organisational security measures.

In some scenarios, multiple parties may be involved in a single wallet interaction, for example, where a relying party uses a third-party verification service. In those cases, joint controllership or processor arrangements may apply, and the roles must be clearly defined in a written agreement. Ambiguity about who holds controller responsibility is itself a compliance risk under GDPR.

What are the main GDPR risks organisations face with EUDI Wallet integration?

The main GDPR risks in EUDI Wallet integration arise from how organisations design and manage their side of the interaction. The most common risks include over-collection of data, unclear retention practices, insufficient privacy documentation, and failure to conduct a Data Protection Impact Assessment (DPIA) where required.

Organisations should be aware of these specific risk areas:

• Over-requesting attributes: Asking for more data than the service requires violates data minimisation and may lack a valid lawful basis. Under CIR (EU) 2025/848, a relying party must register with the national authority of its Member State of establishment before requesting wallet data, and must specify per intended use which attributes and attestations it will request. The wallet checks requests against this registered scope.
• Storing verified data unnecessarily: Once a credential has been verified, retaining the underlying personal data beyond what is needed creates both legal and security exposure.
• Inadequate DPIA: Wallet-based identity verification may involve systematic processing of identity data at scale, which can trigger the obligation to conduct a DPIA under Article 35 of GDPR.
• Third-party processors: If a verification service processes wallet credentials on behalf of the organisation, a compliant data processing agreement must be in place.
• Cross-border data flows: The EUDI Wallet framework is designed so that a certified wallet from one Member State can be used with an appropriate relying party in another Member State. This does not mean that national registration requirements disappear or that sector-specific legislation ceases to apply. If processing involves transfers outside the EEA, additional safeguards apply, and relying parties should verify which national registration frameworks govern their specific use case.

Organisations in regulated sectors such as financial services or healthcare face additional sector-specific obligations on top of GDPR, which means the risk profile is more complex. A thorough compliance review before going live with wallet integration is a practical necessity.

How should organisations update their privacy documentation for EUDI Wallet use?

Organisations must update their privacy notices, records of processing activities, and internal data governance documentation before accepting EUDI Wallet credentials from users. GDPR requires that individuals are informed about how their data is processed at the time of collection, which includes wallet-based interactions. Existing privacy documentation is unlikely to cover this new data source without specific updates.

Key documentation updates to address include:

• Privacy notice: Add a clear description of wallet-based data collection, the specific attributes requested, the lawful basis, and how long the data is retained.
• Records of processing activities (RoPA): Create or update entries for wallet credential processing, including the categories of data, purposes, recipients, and retention periods.
• DPIA: Assess whether a Data Protection Impact Assessment is required and document the outcome, including any mitigating measures taken.
• Processor agreements: Review and update contracts with any third-party verification providers involved in the wallet interaction.
• Internal policies: Update data handling procedures and staff guidance to reflect the new data source and any specific rules that apply to verified credential data.

Privacy documentation should be treated as a living set of records. The eIDAS 2.0 framework continues to develop through implementing acts adopted by the European Commission, and practical wallet rollout will progress in phases across Member States as national wallet solutions are certified, notified, and made available. Public bodies must accept notified wallets for online services requiring electronic identification by 24 December 2026. The obligation for relevant regulated private sectors under Article 5f applies from 24 December 2027. As wallet use cases expand and regulations evolve, organisations should plan for periodic reviews to keep documentation accurate and complete. Organisations working across government services or other regulated domains will also need to align wallet-related documentation with any sector-specific privacy requirements that apply alongside GDPR.

How the ID Connector supports EUDI Wallet and GDPR compliance

The ID Connector is an integration that lets relying parties accept every certified European wallet, whatever Member State issued it, for identification, login and qualified signing. EUDI Wallet acceptance comes first; the same interface also carries other IDs, such as national eIDs, bank IDs and identity documents, inside and outside the EU.

In the context of GDPR compliance, the ID Connector addresses several of the technical obligations that arise when an organisation integrates wallet-based identity:

• Verifying issuer signatures against the relevant national trusted lists, which are brought together in the EU List of Trusted Lists.
• Checking revocation status through issuer-provided status information.
• Validating wallet unit attestations to confirm that the presenting wallet runs on a certified wallet solution.
• Enforcing the registered attribute scope so that only the attributes declared in the relying party’s registration under CIR (EU) 2025/848 are requested.
• Supporting selective disclosure so that integrations request only the attributes a service genuinely requires, in line with the data minimisation principle.
• Connecting to a qualified trust service provider for qualified signing where that use case applies.

Organisations in financial services, healthcare, pharma, and government each face a distinct combination of GDPR obligations and sector-specific requirements when deploying wallet-based identity. The ID Connector is built to operate across these contexts. Contact TrustTech to discuss your organisation’s specific situation and find out how the ID Connector fits into your compliance and integration requirements.