It increases privacy exposure, complicates compliance and creates more value in the data than the transaction requires. A better model is selective disclosure, where the relying party receives only the specific verified fact needed for the check and nothing else.
Why asking for extra identity data changes the trust and privacy equation
Collecting more identity data than a transaction needs changes the risk profile before any security control is applied. It widens the set of personal attributes you must protect, expands the impact of a breach or misuse, and can turn a simple verification step into a higher-value data store that is harder to justify, govern and retain.
The practical issue is not only volume, but purpose. When the same business outcome can be achieved by proving one fact, such as eligibility, age range, or account ownership, collecting the full record creates unnecessary exposure and can make downstream use harder to defend.
How selective disclosure reduces exposure without weakening verification
Selective disclosure changes the design of the check, not the assurance goal. The relying party receives only the specific verified statement it needs, which reduces unnecessary retention, narrows misuse potential, and makes the data flow easier to explain to customers, auditors and privacy reviewers.
This approach is strongest when the verification question is narrow and the business process is clear. If the consumer only needs a yes or no, or a single attribute, the organisation should avoid designs that expose full identity profiles, reusable documents or broad personal datasets just because they are available.
In practice, that means separating identity proof from attribute revelation. A strong identity verification process can still support selective disclosure when it uses Identity Data Privacy and Consent Guide principles such as minimisation and purpose limitation, while keeping the disclosure tied to the exact business need.
What organisations should check before collecting more than the minimum
Start with the purpose test: identify the exact decision the business needs to make, then list the smallest set of attributes that can support that decision. If the team cannot explain why a field is required, it is usually a sign that the field is being collected for convenience, not necessity.
Then check whether the same outcome could be achieved through a verified claim rather than raw data. That matters for privacy, but also for lifecycle management, because unnecessary attributes tend to spread into logs, reports, integrations and secondary systems. Good identity design treats those extra copies as part of the control problem, not as harmless duplication.
Where identity attributes must be correlated across systems, keep the source-of-truth discussion focused on accuracy and necessity. Identity Data Quality and Identity Fabric Guide is useful here because it shows how attribute quality and authoritative sources affect whether you can trust the data you already hold, rather than compensating by collecting more.
Risk and Threat Considerations
Over-collection creates a larger privacy blast radius and makes the transaction more attractive if the data is reused, breached or requested for secondary purposes. It also increases the chance of compliance drift, because once extra fields exist, teams often start using them outside the original justification.
Failure mechanism: The organisation collects identifiable attributes that are not needed for the decision, stores them in more places than intended, and loses control over retention, access and reuse. That weakens minimisation, increases exposure to misuse, and makes later purpose-limitation arguments harder to defend.
Impact: More data than necessary increases legal and regulatory scrutiny, raises breach consequences, and creates unnecessary trust pressure because the customer must hand over more of themselves than the service actually requires.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | A.5.1 — Privacy by design | Extra identity data directly affects minimisation and purpose limitation for personal data. |
| A.5.5 — Data minimisation | The question is fundamentally about collecting more personal data than needed. | |
| A.5.4 — Retention and deletion | Over-collection increases retention exposure and lifecycle governance burden. | |
| Recommendation — Minimise requested attributes to the verified fact needed for the transaction. Collect only the identity data required to satisfy the specific business purpose. Set shorter retention for identity data that is not essential to the decision. | ||
| NIST SP 800-53 Rev 5 | DM-1 — Data minimization and retention | The subject is directly about limiting identity data collection to what is necessary. |
| Recommendation — Limit collection and retention to the minimum identity attributes the use case requires. | ||
| NIST SP 800-63 | 5.1 — Identity proofing | Selective disclosure depends on proving only the needed identity attribute or fact. |
| Recommendation — Use identity proofing outcomes that disclose only the claim the relying party needs. | ||
Practitioner Guidance
What to prioritise: Treat every requested attribute as a control decision, not a product preference. If the business outcome can be supported by a verified statement instead of the underlying raw data, prefer the statement and remove the field from the transaction flow.
What to verify: Before approving a data request, verify who consumes the field, where it is stored, how long it persists, and whether the same check can be satisfied with a narrower attribute set. If the answer is unclear, the request is not ready for production use.
Common mistake: Teams often assume more identity data means better assurance. In reality, extra fields usually improve convenience more than confidence, while increasing the number of places where privacy, retention and access control must be enforced.
Practitioner takeaway: The safest identity design is usually the one that proves the needed fact and withholds everything else, because unnecessary data turns a simple verification into a broader governance and exposure problem.