GDPR for identity systems: what the regulation actually requires

What identity teams must support

GDPR confers user rights (access, rectification, erasure, portability, object). Identity systems are usually where those requests are routed because they hold the canonical user record.

The eight obligations to implement

1. Lawful basis tracking. For every data field, why are you processing it? Consent, contract, legitimate interest. Store this with the data, not in a wiki.
2. Granular consent capture. Marketing consent is not the same as cookie consent is not the same as data sharing consent. Capture separately, time-stamped, with audit trail.
3. Right of access. A user-initiated export of their data within 30 days. Build the export pipeline before someone asks.
4. Right to rectification. Users can correct inaccurate data. Profile editing screens count, but only if all derived systems get updated.
5. Right to erasure. "Delete my account" must actually delete (or anonymize beyond reidentification). Backups complicate this — have an answer.
6. Right to portability. Machine-readable export in a common format (JSON usually suffices).
7. Right to object. Users can opt out of specific processing (notably profiling). Honor it in the identity layer.
8. Data residency. Where is the data physically stored? Some customers will require EU-only.

Vendor requirements

User data export API. Account deletion with downstream propagation. Consent capture with audit trail. Data residency controls (EU, US, regional). Audit log of all access to personal data.

Common pitfalls

• Confusing "delete" with "mark inactive" — GDPR is explicit that erasure is erasure
• Not propagating deletions to data warehouses and BI systems
• Treating GDPR as an EU-only concern when CCPA and similar laws now apply globally
• Marketing consent that defaults to opt-in (illegal in EU)
• Failing to log who accessed personal data (Article 30 record keeping)