How IAM Supports GDPR’s Right to Be Forgotten

Deleting a user account takes seconds. Deleting everything your organization knows about that user is a much bigger job. When a customer invokes their right to be forgotten, their profile in your identity provider is only the starting point, because their details also live in your CRM, support desk, billing tool, analytics platform, and a few SaaS apps your marketing team connected last year. Every one of those copies has to be found and dealt with before the legal deadline.

The right to be forgotten, also called the right to erasure, gives individuals the right to ask an organization to delete their personal data under specific conditions. It is set out in Article 17 of the General Data Protection Regulation (GDPR), and organizations generally have one month to respond to a valid request.

Identity and access management (IAM) gives you the control layer to handle these requests consistently. It keeps a central record of user identities, controls who can reach personal data, and coordinates account deprovisioning across connected applications once a deletion request is approved. IAM supports GDPR compliance, but it does not erase every copy of personal data on its own. Data held in application databases, backups, logs, and third-party systems still needs its own deletion process.

What Is the Right to Be Forgotten Under GDPR?

The right to be forgotten under GDPR is an individual’s right to ask an organization to erase their personal data without undue delay. Article 17 defines the right to erasure, and Article 12(3) requires the organization to respond within one month of receiving the request. For complex or high-volume requests, that period can be extended by up to two more months, as long as the individual is told about the extension and the reason within the first month.

The right is not absolute. It applies only when one of the grounds in Article 17(1) is met, and the exceptions in Article 17(3) can limit it. This is why every organization that handles EU personal data needs a defined process for receiving, assessing, and responding to deletion requests. Handling them case by case leads to missed deadlines and inconsistent decisions, and wrongly refusing a valid request can lead to fines of up to €20 million or 4% of global annual turnover, whichever is higher.

When Can Individuals Request Data Erasure?

Under Article 17(1), an individual can request erasure when any one of these six grounds applies:

• The data is no longer necessary for the purpose it was originally collected or processed for.
• The individual withdraws consent, and there is no other legal basis for the processing.
• The individual objects to the processing, and there are no overriding legitimate grounds to continue, or the objection relates to direct marketing.
• The data was processed unlawfully.
• Erasure is required to meet a legal obligation under EU or member state law.
• The data was collected from a child in connection with an online service offered directly to them.

The individual does not need to explain why they want their data erased, and the request can arrive through any channel, including email, a web form, or a support ticket. Responding is free of charge in most cases, so your team has to be ready to recognize a request wherever it lands.

Are There Exceptions to the Right to Be Forgotten?

Yes. Article 17(3) lists five situations where the right to erasure does not apply, to the extent that processing is necessary for:

• Freedom of expression and information
• Compliance with a legal obligation, or a task carried out in the public interest or under official authority
• Public health reasons in the public interest
• Archiving, research, or statistical purposes in the public interest, where erasure would make those goals impossible or seriously impair them
• Establishing, exercising, or defending legal claims

The legal obligation exception is the one most businesses run into. Tax, accounting, and financial regulations often require you to keep invoices and transaction records for several years. In that case, you can erase the rest of the individual’s personal data, limit the retained records to their legal purpose, and tell the requester what you kept and why.

How Does IAM Support GDPR’s Right to Be Forgotten?

IAM supports the right to be forgotten by giving you one place to find a person’s identity, see what they can access, and remove that access across connected systems. It works as the coordination layer for erasure. IAM tells you where the person exists and closes their access paths, while application owners and data teams delete the underlying records.

Centralized Identity Data Management

When identities are spread across separate app logins, finding everything linked to one person means checking each system by hand. Whether your source of truth is Active Directory, Microsoft Entra ID, LDAP, or your IAM platform acting as the identity provider, a centralized directory gives every user a single record with core attributes such as name, email, user ID, and the applications they are provisioned to.

When an erasure request arrives, this unified view becomes your starting map. It shows which accounts exist, which applications hold linked profiles, and which attributes were synced downstream. For customer-facing applications, a customer identity and access management (CIAM) platform plays the same role by keeping end-user profiles, consent records, and preferences in one place.

Automated User Deprovisioning

Automated user provisioning works in both directions. The same connectors that create accounts in downstream applications, including SCIM, REST APIs, LDAP, and direct database connectors, can also disable or delete them. Once an erasure request is approved, IAM can disable the directory account, revoke SSO and application access, end active sessions, and reclaim licenses, either instantly or on a scheduled trigger.

This replaces a chain of manual IT tickets and closes a common gap, where an account is removed from the directory but stays active in an application nobody remembered to check. Automated deprovisioning also logs every provisioning, update, and deprovisioning event, so you have a clear record of which systems received the change. Learn more about how automated user provisioning and deprovisioning work.

Access Control and Data Protection

Erasure is easier when fewer people and systems handle personal data in the first place. Role-based access control (RBAC), attribute-based access control (ABAC), and the principle of least privilege limit user access provisioning to the roles that genuinely need personal data. Just-in-time (JIT) provisioning goes a step further by granting access only when a task requires it. Together, these controls reduce the number of places an individual’s data can spread through exports, shared drives, and spreadsheets.

Multi-factor authentication (MFA) and adaptive access policies protect the accounts that can view or export personal data, using context such as IP address, device, and location to decide when to ask for more proof. These controls support GDPR’s data minimization and security of processing requirements, and they make the scope of every future deletion request smaller and easier to trace.

Audit Trails and Compliance Reporting

GDPR’s accountability principle requires you to demonstrate compliance, not just achieve it. IAM access logs, session tracking, and workflow records show when a request was received, who approved it, when accounts were disabled, and which applications confirmed deprovisioning. Exportable audit reports turn that history into evidence you can share during a review.

These records give you evidence for regulators and a clear answer for the individual. Keep the erasure record itself lean by using a request ID and the minimum identifying details, so the evidence of deletion does not become a new store of personal data.

How to Handle GDPR Data Erasure Requests Using IAM

A reliable erasure workflow separates two jobs that are easy to confuse. Deprovisioning removes a person’s accounts and access. Data deletion removes their personal data from the systems that store it. IAM handles the first job directly and coordinates the second, and the six steps below are designed to fit inside the one-month window for a valid right to erasure GDPR request.

Step 1: Verify the Requester’s Identity

Before you act, confirm that the request comes from the individual or from someone authorized to act for them. A fraudulent request could wipe a genuine customer’s account or confirm to an outsider that a person exists in your systems.

Match the level of verification to the risk. For a signed-in user, a request submitted from their account after MFA is usually enough. For an emailed request, match it to the address on file and send a confirmation link. Ask only for the information you need to confirm identity, so the verification step does not collect more personal data than necessary.

Step 2: Identify Accounts and Personal Data

Start with the central identity record to list every account linked to the person, including directory entries, SSO-connected applications, provisioned SaaS accounts, and customer profiles. Then look beyond IAM, into application databases, data warehouses, marketing tools, support tickets, logs, and backups. A data inventory that records where personal data sits and how it flows between systems makes this step much faster.

Search by every identifier the person may have used, such as alternate email addresses, phone numbers, and customer IDs. A single missed identifier is one of the easiest ways for personal data to survive an erasure request.

Step 3: Assess the Erasure Request

Work with your privacy or legal team to confirm whether one of the Article 17(1) grounds applies and whether any exception allows you to keep some of the data. The output should be a decision for each data category: erase it, retain it with a documented legal reason, or restrict it to a specific purpose.

If you refuse the request in full or in part, tell the individual why within the response deadline and let them know they can complain to a supervisory authority.

Step 4: Revoke Access and Deprovision Accounts

Once the request is approved, disable the directory account in your IAM platform. Revoke SSO and application access, end active sessions, revoke tokens and API keys, remove group and role memberships, and push deprovisioning updates to every connected application.

Disable first and delete later. If you delete the central identity record before downstream systems confirm their actions, you lose the reference you need to track the remaining tasks. Provisioning connectors typically let you choose whether a deprovisioning event disables or deletes the account in each application, so set that option to match your retention rules and delete the IAM record as the final step.

Step 5: Coordinate Data Deletion Across Systems

Route deletion tasks to the owners of each system that stores personal data, such as application owners, data engineering, marketing operations, and support. Include the third-party processors that hold data on your behalf, and send them deletion instructions under your data processing agreements. GDPR also requires you to inform recipients you disclosed the data to, unless that proves impossible or involves disproportionate effort.

Backups need a clear rule. If you cannot delete data from a backup immediately, put it beyond use, make sure it is not restored into live systems, and let it expire on your normal backup rotation.

Step 6: Verify Completion and Maintain Evidence

Confirm that every deletion task is closed, that the identity can no longer authenticate, and that accounts in connected applications are gone. Document any data you retained, along with its legal basis and retention period.

Send the individual a confirmation that explains what was erased and what was kept. Then store a minimal compliance record of the request, the decision, and the completion date as evidence for future audits.

Role of Identity Lifecycle Management in GDPR Compliance

Identity lifecycle management governs a digital identity from creation, through every role or profile change, to final removal. For GDPR, the final stage carries the most risk, because it is where access is closed and where personal data either gets cleaned up or quietly lingers. Applying identity lifecycle best practices to erasure requests turns deletion into a repeatable process instead of a one-off project.

1. Automating Identity Deactivation and Removal

Lifecycle workflows run on triggers. An exit recorded in an HR system such as Workday, BambooHR, or SAP SuccessFactors, a customer account closure, or an approved erasure request can each start a workflow that deactivates the identity, revokes access, and schedules final deletion after a defined grace period. This is the same joiner-mover-leaver (JML) logic that drives HR-driven provisioning, applied to the leaver stage.

The same logic applies to employees and customers. Former employees can submit erasure requests too, and a lifecycle workflow helps you treat both groups consistently while applying the different retention rules each one needs.

2. Managing Identity Changes Across Applications

With user lifecycle management, connected applications receive provisioning and deprovisioning updates through SCIM, REST APIs, LDAP, and pre-built connectors. When an identity is disabled or removed in the central directory, that change flows to every integrated cloud and on-premises application without manual follow-up.

Applications with no native provisioning support need extra attention. Direct database connectors can often reach them. Where they cannot, flag the application in the workflow and assign a manual task with a named owner and a deadline, so it does not drop out of the erasure process.

3. Supporting Data Retention Policies

Deletion workflows must check retention rules before removing anything. Define retention periods by data category, such as billing records kept for the period tax law requires or security logs kept for a set investigation window.

Tag every retained item with its legal reason and expiry date, then delete it automatically when that date arrives. GDPR’s storage limitation principle means retained data still needs an end date, even when an exception allows you to keep it for now.

Challenges of Implementing the Right to Be Forgotten with IAM

IAM makes erasure requests far more manageable, but some gaps are common across implementations. Planning for them early keeps your response inside the deadline.

1. Fragmented identity data

Personal information is often stored across many applications, each with its own user ID and profile fields. Without a mapping between the central identity and each application account, some records will be missed.

2. Incomplete deprovisioning

Removing a central account does not always remove access in every connected system. Applications outside your provisioning setup can leave orphaned accounts, and identity artifacts such as MFA enrollments, recovery codes, and verification records can stay behind after the main profile is gone.

3. Data retention requirements

Tax, financial, employment, and security rules may require you to keep certain records. Teams need clear guidance on what to keep, for how long, and who signs off on each exception.

4. Third-party dependencies

Processors such as payment providers, email platforms, and support tools may hold copies of personal data. Each one needs separate deletion instructions and a way for you to confirm the work was done.

5. Verification and auditability

Regulators expect proof that a request was assessed and completed. Without workflow records, it is hard to show which systems were cleared, which data was retained, and why.

Best Practices for Managing GDPR Erasure Requests

The practices below help you handle erasure requests consistently, meet the one-month deadline, and keep clear evidence for every decision.

1. Maintain an inventory of identity systems and connected applications

List every directory, identity provider, and application that stores user data, along with its owner and how it connects to IAM. Review this inventory whenever a new application is added.

2. Define a documented process for receiving and assessing requests

Set up a single intake channel, a verification standard, and a named owner for legal assessment. Train support and sales teams to recognize erasure requests that arrive through other channels.

3. Automate account deprovisioning where possible

Connect high-use applications to your IAM platform through SCIM provisioning, APIs, or pre-built connectors, so one approved request revokes access everywhere at once.

4. Coordinate identity workflows with application-level data deletion

Link deprovisioning to deletion tasks for each data owner, so account removal and data erasure move forward together instead of as separate projects.

5. Establish retention rules for backups, logs, and legally required records

Document how long each data category is kept, why, and how it is deleted or put beyond use once that period ends.

6. Monitor request status and document completion or exceptions

Track each request against its deadline, record retained data and its legal basis, and keep a minimal completion record for audits.

Wrapping Up

The right to be forgotten is easy to state and harder to deliver, because one person’s data rarely sits in one place. IAM gives you the foundation to respond with confidence. It shows you where an identity exists, revokes access across connected applications, and records each step as evidence. Pair it with a clear assessment process, retention rules, and data deletion tasks for every system owner, and erasure requests become a routine workflow that fits inside the one-month deadline.

miniOrange supports both sides of this process. miniOrange IAM centralizes identities and automates provisioning and deprovisioning across 6,000+ pre-built integrations, backed by RBAC, MFA, and audit-ready logs. miniOrange Data Privacy covers the data side with DSAR workflows for erasure, data discovery, and retention management. You can deploy in US, EU, India, or Australia cloud data centers, or on-premises.

FAQs

1. Does deleting a user account erase all personal data?

No. Deleting an account removes login and access, but personal data can remain in databases, logs, backups, and third-party systems until each one is cleared.

2. Can IAM automate GDPR data deletion requests?

IAM automates the identity side, including deactivation, access revocation, and deprovisioning. Deleting the data inside each application needs a separate deletion process or that system’s own deletion tools.

3. Are organizations always required to delete personal data when requested?

No. Erasure applies only when an Article 17(1) ground is met, and organizations can keep data under an Article 17(3) exception, such as a legal obligation.

4. How does identity lifecycle management support the right to erasure?

It links erasure requests to automated workflows that deactivate identities, revoke access, and push deprovisioning updates to connected applications.