GDPR for identity systems: what the regulation actually requires

GDPR makes your identity system the place where privacy obligations either work or fail. The identity store holds the canonical user record, so it is where data subject requests land, where consent is captured, where biometric and profile data sit, and where an account takeover becomes a reportable breach. This guide maps the articles of Regulation (EU) 2016/679 that bind identity teams to the controls you build, with the deadlines in the text. It is written for IAM owners working with their DPO, not as legal advice. See GDPR for the short definition.

The articles that bind identity teams

Lawful basis and consent

Article 6 lists the six bases. Track them in data, not in a wiki: a consent record should hold the purpose, the wording shown, a timestamp, and the channel. The definition of consent in Article 4(11) requires "a clear affirmative action", and Recital 32 states that "silence, pre-ticked boxes or inactivity" do not constitute consent. Marketing, analytics sharing, and partner data sharing are separate purposes and need separate toggles. See consent management.

Do not use consent where another basis fits. Authenticating a user to deliver the service is processing necessary for the contract; consent to log in creates a withdrawal right you cannot honor.

Data subject rights the identity layer must serve

Articles 15 to 22 cover access, rectification, erasure, restriction, portability, and objection. Under Article 12(3) you have one month from receipt to act.

1. Access (Art. 15). A self-service export of the profile, linked identities, consent history, and sign-in history.
2. Rectification (Art. 16). Profile edits must reach derived systems, not just the identity store.
3. Erasure (Art. 17). Deletion is required on the listed grounds, including withdrawn consent with no other basis and data no longer needed. Article 17(3) keeps exceptions, such as a legal obligation or defending legal claims, so document which records survive and why.
4. Portability (Art. 20). Data the user provided, "in a structured, commonly used and machine-readable format". JSON is the common answer.
5. Objection (Art. 21). For direct marketing the right to object is absolute, and it includes profiling related to that marketing.

Verify the requester without collecting more data. Recital 64 says controllers should use all reasonable measures to verify identity. The EDPB's Guidelines 01/2022 on the right of access (version 2.1) state that login credentials are normally sufficient and that requiring an ID copy from an already authenticated user is disproportionate. Route requests through the signed-in session, add step-up authentication for erasure, and never let a support agent export data on the strength of a phone call. Help desk impersonation is a proven path (help desk social engineering).

Biometrics and identity verification

Article 9(1) covers "biometric data for the purpose of uniquely identifying a natural person". If you run face matching for identity verification or server-side biometric login, you need an Article 9(2) exception (usually explicit consent), a DPIA under Article 35(3)(b) when it is large scale, and a retention limit.

Design matters as much as consent. In Opinion 11/2024 on facial recognition at airports, the EDPB found that only storage where the biometric data, or its encryption key, stays in the individual's hands could be compatible with the integrity and confidentiality principle, and that centralised storage without the user holding the key cannot meet data protection by design and by default. The identity-system reading: prefer passkeys, where the biometric check stays on the user's device and you only receive a signature.

Security, breaches, and records

Article 32 does not name MFA, but it requires security appropriate to the risk and "a process for regularly testing, assessing and evaluating" the measures. For identity that means MFA, defences against credential stuffing, rate limiting on recovery flows, encrypted sensitive attributes, and admin access through PAM.

Article 33 requires notifying the supervisory authority within 72 hours of becoming aware of a breach unless it is unlikely to result in risk, and Article 33(5) requires documenting every breach, notified or not. Article 30 is a different duty: it requires a record of processing activities (purposes, categories of data and recipients, retention limits, a description of security measures), not a log of who accessed data. You still need access logs, but for Article 32 and breach investigation.

Implementation checklist

1. Map every identity attribute to a purpose, lawful basis, and retention period; feed that into the Article 30 record.
2. Remove pre-ticked boxes; split consent by purpose; store consent receipts; make withdrawal one click.
3. Build self-service export (JSON) and deletion, with propagation to analytics, CRM, warehouse, and support tools.
4. Authenticate rights requests through the existing session; add step-up for erasure and export.
5. Write a backup answer: deleted users stay out of restores, or restores replay a deletion queue.
6. Run a DPIA before biometric verification, server-side biometric login, or large-scale risk scoring.
7. Enforce MFA for admins and offer passkeys to users; monitor for stuffing and takeover.
8. Pin tenant data to a region if customers require it; document Chapter V transfer mechanisms for providers outside the EEA. Track other privacy regimes on the regulations calendar.
9. Rehearse the 72-hour breach clock with an account takeover scenario.

Common failure modes

• Password reuse at scale. In the 23andMe incident, about 14,000 accounts accessed with reused passwords exposed profile data on about 6.9 million other users through a sharing feature. Breach-volume math depends on what one account can see.
• Support access as the leak. At Coinbase, paid support staff pulled customer data from internal tools. Scope agent access to the ticket, not the whole user base.
• "Delete" that means "mark inactive". Soft-delete flags fail Article 17 unless the data is erased or anonymised beyond re-identification.
• Deletions that stop at the IdP. Warehouses and BI copies keep the data alive.
• Consent by silence. Pre-ticked marketing boxes fail Article 4(11) and Recital 32.

Vendor requirements

Ask any CIAM provider for: a user export API, deletion with webhook propagation, consent capture with audit trail, regional data residency, admin access logs, and a data processing agreement. Compare options in how to choose a CIAM platform and the identity audit preparation guide.

Fines reflect the split: Article 83(5) sets up to EUR 20 million or 4% of worldwide annual turnover for breaches of the principles, lawful basis, consent, and special category rules; Article 83(4) sets up to EUR 10 million or 2% for obligations including Articles 25 to 39.