They work together when the identity flow is built so only necessary personal data is requested, transmitted, and stored. In practice, that means the system should prove the needed condition without collecting unrelated attributes. When architecture enforces that rule, compliance becomes a property of the flow, not a manual policy.
How the minimisation rule changes EUDI Wallet architecture
GDPR minimisation is not just a legal constraint added after design, it shapes the wallet flow itself. The wallet should be able to satisfy a relying party with the smallest necessary set of attributes, rather than exposing a full identity record by default. That pushes teams toward purpose-specific disclosure, selective presentation, and attribute-level decisioning instead of broad data release.
For an eudi wallet flow, the practical design question is whether the verifier needs proof of a condition or a copy of the underlying data. If the condition can be proven without revealing unrelated identifiers, dates, or profile fields, the architecture should prefer that path. Digital Identity, eID and Identity Wallets Guide is useful here because it frames wallets around verifiable credentials, selective disclosure and cross-border identity use.
This is why minimisation works best when it is built into the credential format, presentation policy, and verifier request model. If those layers are designed well, the organisation does not need a separate manual review step to ask whether too much data was collected. The data flow already answers that question by construction.
Where GDPR Article 5 and the wallet trust model meet
GDPR minimisation and EUDI Wallet design meet at the point where the wallet decides what to release, to whom, and for what purpose. The wallet ecosystem depends on trust between issuer, wallet holder, and verifier, but GDPR still requires that the disclosed payload stay tied to the specific transaction. That means the trust model must be narrow enough to support verification without turning every interaction into broad identity transfer.
For practitioners, the important distinction is between a credential being valid and every field in it being necessary. A wallet can contain richer data than the verifier receives, but the release step should be constrained to the minimum evidence needed for the use case. EU General Data Protection Regulation (GDPR) is the governing baseline for this design choice, especially the principles around minimisation and data protection by design.
This becomes especially important when the wallet is used across borders or across sectors, because the same credential can support many transactions with different disclosure needs. Good design therefore separates issuance from presentation and avoids turning one reusable identity artifact into a universal data export.
Design patterns that make minimisation real
Minimisation becomes enforceable when the system uses design patterns that reduce data at the source, not only after collection. The strongest patterns are selective disclosure, pairwise identifiers where appropriate, purpose-bound verifier requests, and credential schemas that omit unnecessary attributes in the first place. A wallet that stores less, reveals less, and asks less is much easier to keep aligned with privacy requirements.
This is also where policy and engineering meet. A verifier request should be machine-readable enough to constrain the response, and the wallet should be able to reject overbroad requests or present only the minimum attributes that satisfy the proof. Privacy by Design Guide for Engineering Teams is a strong companion reference because it ties Article 25 thinking to engineering patterns such as pseudonymisation, deletion and retention enforcement.
When teams get this wrong, the usual failure is not a dramatic breach, but slow over-collection. One overly broad verifier request, one convenience-driven schema, or one fallback path that returns full attributes can quietly turn a privacy-respecting wallet into a data-sharing mechanism. The architectural goal is to make the minimal path the easiest path.
Risk and Threat Considerations
Over-disclosure creates both compliance risk and security exposure. If wallet flows routinely reveal more attributes than a verifier needs, the organisation increases profiling risk, linkage risk across services, and the blast radius of any downstream misuse of the disclosed data.
Failure mechanism: Broad credential schemas, overly permissive verifier requests, or weak presentation controls cause the wallet to transmit unnecessary personal data, and that data can then be retained, correlated, or repurposed outside the original purpose.
Impact: The result can be unlawful processing, unnecessary exposure of sensitive attributes, and loss of user trust, even when the wallet authentication step itself is functioning correctly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
GDPR and ISO/IEC 27001:2022 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.15 — Data protection by design and by default | Minimisation and selective disclosure are central to this wallet flow. |
| A.5.34 — Privacy and protection of PII | EUDI Wallet transactions process personal data and require bounded disclosure. | |
| Recommendation — Design wallet flows to disclose only the attributes needed for each transaction. Limit collection, transmission and storage to the minimum necessary personal data. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | Wallet data needs classification so disclosure rules match sensitivity and purpose. |
| Recommendation — Classify wallet-held attributes and restrict disclosure by sensitivity and purpose. | ||
Practitioner Guidance
What to verify: Check whether each wallet transaction can be satisfied with a minimal attribute set, and whether the verifier can state exactly why each requested field is needed. If the request cannot justify each attribute, treat that as a design defect rather than a user preference issue.
What good looks like: The issuer, wallet, and verifier all support the same minimal disclosure path, with no fallback that silently widens the data set. In a mature implementation, compliance is visible in the transaction design, not enforced later by policy exception handling.
Practitioner takeaway: The right test is not whether the wallet can carry more identity data, but whether it can prove the needed condition without exposing more than the transaction requires.
Related resources from NHI Mgmt Group
- Guide: Identity Data Privacy and Consent Guide
- Why do IAM and data governance need to work together for GDPR?
- Why is it important to integrate identity and data governance?
- How should teams design EUDI Wallet authentication if biometrics cannot be the sole factor?
- Why do DSPM and data access governance need to work together?