Atlas ApexAtlasApex

GDPR · Identity Lens

GDPR

Identity is how the data subject is recognised, how their rights are enforced, and how a personal-data breach is detected.

Full name
General Data Protection Regulation (Regulation (EU) 2016/679)
Region
European Union (extraterritorial)
Applies to
Any organisation processing personal data of individuals in the EU, regardless of where the organisation is established. Extraterritorial reach via Article 3.

GDPR has been in force since 25 May 2018 and remains the reference regime for personal-data protection. Most identity programmes treat it as a CIAM concern, but the data-protection principles (Article 5), security-of-processing duty (Article 32), and breach-notification regime (Articles 33-34) all touch identity directly — both customer-facing and workforce.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

Article 5 — Principles relating to processing of personal data

Lawfulness, fairness, and transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality. Identity records (account profiles, audit logs, biometrics, MFA enrolment data) are personal data and have to be designed against each principle.

Article 25 — Data protection by design and by default

Privacy controls have to be built into the system, not bolted on. For identity, this is the strongest legal basis for purpose-limited identifiers, attribute minimisation, just-in-time disclosure, and selective verification.

Article 32 — Security of processing

Pseudonymisation, encryption, confidentiality, integrity, availability, resilience, and the ability to restore access. Identity is implicated in every one of these — particularly resilience and restorability, which are the most commonly missed.

Articles 15-22 — Data-subject rights

Right of access, rectification, erasure, restriction, portability, and objection. Each one requires the identity layer to authenticate the data subject reliably (without imposing disproportionate friction) and to act on linked accounts across systems.

Articles 33-34 — Personal-data breach notification

Notification to the supervisory authority within 72 hours of awareness. Identity-driven breaches (credential theft, federation failure, account takeover) need to be detected and assessed against that window, which forces the identity team to participate in the privacy incident pipeline.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

Audit logs treated as security data with no GDPR retention review — they hold rich personal data and need their own lifecycle.

MFA enrolment data (phone numbers, biometric templates) processed without a clear lawful basis or storage-limitation policy.

Account-deletion flows that remove the user record but leave logs, sessions, and federated identities behind.

Data-subject access requests routed through support email, with no authenticated path. Either the response is over-broad (privacy risk) or impossible to satisfy (compliance risk).

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

Identity architecture documented as a personal-data processing system in the record of processing, with explicit purposes per attribute.

DSAR flows integrated with the IdP so the data subject is authenticated to a defined assurance level before personal data leaves the platform.

A retention model that ties identity events (audit logs, MFA factors, recovery codes) to specific articles, so legal can defend the period.

Need a GDPR-ready identity baseline?

We start with an assessment that maps your identity controls to GDPR requirements, then design and operate the gaps.

Book a Conversation