Compliance deep dive · reviewed 2026-05-22

GDPR identity requirements — Articles 25, 32, and the IAM controls regulators expect

How GDPR's Articles 25 (data protection by design), 32 (security of processing), and 5 (storage limitation) translate to specific IAM controls in 2026.

Authority

European Data Protection Board (EDPB) + national supervisory authorities (CNIL, ICO, BfDI, etc.)

Effective date

GDPR (Regulation (EU) 2016/679) effective May 25, 2018. UK GDPR effective post-Brexit; substantively aligned.

Jurisdiction

EU + EEA + UK

Evidence cadence

Continuous — there is no scheduled "GDPR audit

Scope

Any organization processing personal data of EU / UK / EEA data subjects — regardless of where the organization is based (extraterritorial reach via Article 3).

IAM-relevant controls

The controls that matter for IAM.

Art. 5(1)(f)
Integrity & Confidentiality
What it requires: Personal data shall be processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing.
Evidence example
Access control matrix showing who can access which personal data + audit log of access events.
Art. 5(1)(e)
Storage Limitation
What it requires: Personal data shall be kept in a form which permits identification of data subjects for no longer than necessary.
Evidence example
Identity-account retention policy + automated deletion of dormant accounts + alumni-account retention review.
Art. 25
Data Protection by Design + by Default
What it requires: Implement appropriate technical + organizational measures designed to implement data-protection principles. By default, only personal data necessary for each specific purpose are processed.
Evidence example
Privacy-by-design checklist applied to new IAM features + minimum-necessary access-rights review.
Art. 32
Security of Processing
What it requires: Implement appropriate technical + organizational measures to ensure a level of security appropriate to the risk — including pseudonymization, encryption, confidentiality, integrity, availability, resilience.
Evidence example
MFA enforcement evidence + encryption-at-rest documentation + business continuity plan + tested recovery procedure.
Art. 33
Notification of a Personal Data Breach to the Supervisory Authority
What it requires: Notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach.
Evidence example
Incident response runbook with 72-hour notification trigger + breach decision-log + supervisory authority contacts documented.
Art. 35
Data Protection Impact Assessment (DPIA)
What it requires: Carry out a DPIA before processing operations likely to result in high risk to rights and freedoms of natural persons.
Evidence example
DPIA documentation for high-risk IAM processing (e.g. biometric authentication, profiling, large-scale identity processing).
Art. 17
Right to Erasure (Right to be Forgotten)
What it requires: Data subjects have the right to obtain erasure of their personal data without undue delay.
Evidence example
DSAR workflow + identity-account deletion procedure + downstream propagation log (federated systems, backup-handling).
Art. 30
Records of Processing Activities
What it requires: Maintain a record of processing activities under your responsibility.
Evidence example
RoPA inventory entry for each identity-related processing activity (workforce IAM, customer IAM, audit logging) with retention + recipients.

How GDPR thinks about IAM

GDPR doesn't prescribe specific IAM controls the way NIST 800-53 does. Instead, it requires "appropriate technical + organizational measures" (Article 32) for the risk of the processing. In practice, this means modern IAM hygiene: MFA, access control aligned to least privilege, audit logging, breach response, data-subject rights handling. EDPB guidance + supervisory authority enforcement filled in the specifics over time.

Article 32 — the IAM core

Article 32(1)(b) requires "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services." Article 32(1)(d) requires "a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures." Together these are the GDPR foundation for the IAM program: identity controls implemented, continuously operating, and regularly tested.

Article 25 — privacy by design as an IAM discipline

Article 25 means IAM features must be designed with data protection from the start. For an IAM team, this means:

Default minimum-necessary access (least privilege by default, not opt-in)
Privacy review for new identity-data-collection (e.g. a new social login provider)
Pseudonymization where possible (use opaque user IDs internally; only attach identity at the API boundary)
Audit trails treated as personal data with their own retention + access controls

The right to erasure (Article 17) breaks IAM in interesting ways

Article 17 right-to-erasure is the most operationally challenging article for IAM teams. Issues that surface:

Federated downstream systems — when you delete a user, do all SPs that authenticated via your IdP also delete?
Audit logs — if logs contain PII, must they be selectively scrubbed on erasure?
Backups — full erasure from time-bounded backups isn't always feasible; supervisory authorities accept "blocked" status as a practical solution
Account-history preservation — for fraud / law-enforcement reasons, full erasure may need to be deferred

Common findings

Article 32 — MFA implemented but not on customer authentication, treated as separate from "security of processing"
Article 25 — privacy-by-design checklist exists but isn't applied to identity-product changes
Article 17 — right-to-erasure works for the primary account but doesn't propagate to federated systems / backups / SIEM logs
Article 5(1)(e) — alumni / dormant accounts retained indefinitely without justification
Article 33 — breach-notification clock starts on awareness, but the awareness threshold isn't operationalized in the IR runbook

Penalties

Up to €20M or 4% of global annual turnover, whichever higher (Tier 2 infringements — Art. 83(5)). Lower tier: €10M or 2% (Art. 83(4)). Largest GDPR fines to date include Meta (€1.2B, 2023), Amazon (€746M, 2021), and Instagram (€405M, 2022).

Evidence cadence

Continuous — there is no scheduled "GDPR audit." Supervisory authorities investigate in response to complaints, breaches, or sector-wide reviews. Evidence must be retrievable on demand within reasonable timeframes (typically days to a few weeks).

Practitioner notes

What the policy doesn’t tell you.

GDPR is risk-based — the appropriate level of security under Article 32 depends on "state of the art, costs of implementation, nature, scope, context, and purposes of processing." For most enterprise IAM, this means at least MFA + encryption + audit logging + breach response.
The EDPB has issued specific guidance on MFA in recent years — risk-based authentication is increasingly expected for high-risk processing (large-scale, sensitive data, financial).
CNIL (France) is the most active GDPR enforcer for identity-related findings. The largest IAM-adjacent fines have come from CNIL.
For US companies, GDPR compliance often comes via the SCC (Standard Contractual Clauses) + Data Privacy Framework + technical safeguards. IAM is part of the technical safeguard story.
The intersection with NIS2 matters: organizations subject to NIS2 already have IAM control requirements that satisfy much of Article 32.

Need help with this framework?

We deliver IAM control programs for GDPR IAM.

Talk to a compliance leadCross-framework crosswalkAudit checklists

The controls that matter for IAM.

Art. 5(1)(f)

Integrity & Confidentiality

What it requires: Personal data shall be processed in a manner that ensures appropriate security, including protection against unauthorized or unlawful processing.

Evidence example

Access control matrix showing who can access which personal data + audit log of access events.

Art. 5(1)(e)

Storage Limitation

What it requires: Personal data shall be kept in a form which permits identification of data subjects for no longer than necessary.

Evidence example

Identity-account retention policy + automated deletion of dormant accounts + alumni-account retention review.

Art. 25

Data Protection by Design + by Default

What it requires: Implement appropriate technical + organizational measures designed to implement data-protection principles. By default, only personal data necessary for each specific purpose are processed.

Evidence example

Privacy-by-design checklist applied to new IAM features + minimum-necessary access-rights review.

Art. 32

Security of Processing

What it requires: Implement appropriate technical + organizational measures to ensure a level of security appropriate to the risk — including pseudonymization, encryption, confidentiality, integrity, availability, resilience.

Evidence example

MFA enforcement evidence + encryption-at-rest documentation + business continuity plan + tested recovery procedure.

Art. 33

Notification of a Personal Data Breach to the Supervisory Authority

What it requires: Notify the competent supervisory authority within 72 hours of becoming aware of a personal data breach.

Evidence example

Incident response runbook with 72-hour notification trigger + breach decision-log + supervisory authority contacts documented.

Art. 35

Data Protection Impact Assessment (DPIA)

What it requires: Carry out a DPIA before processing operations likely to result in high risk to rights and freedoms of natural persons.

Evidence example

DPIA documentation for high-risk IAM processing (e.g. biometric authentication, profiling, large-scale identity processing).

Art. 17

Right to Erasure (Right to be Forgotten)

What it requires: Data subjects have the right to obtain erasure of their personal data without undue delay.

Evidence example

DSAR workflow + identity-account deletion procedure + downstream propagation log (federated systems, backup-handling).

Art. 30

Records of Processing Activities

What it requires: Maintain a record of processing activities under your responsibility.

Evidence example

RoPA inventory entry for each identity-related processing activity (workforce IAM, customer IAM, audit logging) with retention + recipients.

How GDPR thinks about IAM

Article 32 — the IAM core

Article 25 — privacy by design as an IAM discipline

Article 25 means IAM features must be designed with data protection from the start. For an IAM team, this means:

Default minimum-necessary access (least privilege by default, not opt-in)

Privacy review for new identity-data-collection (e.g. a new social login provider)

Pseudonymization where possible (use opaque user IDs internally; only attach identity at the API boundary)

Audit trails treated as personal data with their own retention + access controls

The right to erasure (Article 17) breaks IAM in interesting ways

Article 17 right-to-erasure is the most operationally challenging article for IAM teams. Issues that surface:

Federated downstream systems — when you delete a user, do all SPs that authenticated via your IdP also delete?

Audit logs — if logs contain PII, must they be selectively scrubbed on erasure?

Backups — full erasure from time-bounded backups isn't always feasible; supervisory authorities accept "blocked" status as a practical solution

Account-history preservation — for fraud / law-enforcement reasons, full erasure may need to be deferred

What the policy doesn’t tell you.

GDPR is risk-based — the appropriate level of security under Article 32 depends on "state of the art, costs of implementation, nature, scope, context, and purposes of processing." For most enterprise IAM, this means at least MFA + encryption + audit logging + breach response.

The EDPB has issued specific guidance on MFA in recent years — risk-based authentication is increasingly expected for high-risk processing (large-scale, sensitive data, financial).

CNIL (France) is the most active GDPR enforcer for identity-related findings. The largest IAM-adjacent fines have come from CNIL.

For US companies, GDPR compliance often comes via the SCC (Standard Contractual Clauses) + Data Privacy Framework + technical safeguards. IAM is part of the technical safeguard story.

The intersection with NIS2 matters: organizations subject to NIS2 already have IAM control requirements that satisfy much of Article 32.