How should organisations operationalize GDPR access and erasure requests through identity systems?

Why This Matters for Security Teams

GDPR access and erasure requests are not just privacy tasks. They are identity and data governance workflows that must reach every system where a person is represented by an account, token, profile, log reference, or support record. When organisations rely on ad hoc human coordination, requests stall, approvals become inconsistent, and the audit trail becomes fragmented across IAM, HR, CRM, and downstream applications.

That is why mature teams treat the identity layer as the control plane for subject rights. The Ultimate Guide to NHIs shows how identity sprawl creates persistent risk when lifecycle processes are weak, while the OWASP Non-Human Identity Top 10 reinforces the same operational lesson for machine identities: if revocation is not automated and verifiable, exposure lasts longer than intended. For GDPR, the same pattern applies to personal data access and erasure.

In practice, many security teams discover gaps only after a subject request has already been delayed, partially fulfilled, or challenged during audit rather than through intentional privacy-by-design workflow testing.

How It Works in Practice

Operationalising GDPR requests through identity systems starts with identity resolution. The request must map to a verified subject record, then fan out to all systems that store personal data or access entitlements tied to that subject. In practice, that usually means integrating IAM, directory services, HR systems, ticketing, data catalogs, SIEM, and application-specific admin consoles so the process can be executed and evidenced end to end.

For access requests, the workflow should identify what data exists, where it lives, who can see it, and whether the disclosure is lawful and minimal. For erasure requests, the workflow should distinguish between deletion, pseudonymisation, retention exceptions, and records that must remain for legal or security reasons. A good design does not assume one universal answer, because current guidance suggests that controller obligations, processor obligations, and retention law often collide in edge cases.

• Link the request to a verified subject identity and record the basis for identity assurance.
• Route approvals through privacy, legal, and system owners where exceptions apply.
• Trigger provisioning or deprovisioning actions in downstream systems through automation, not manual emails.
• Write immutable logs that show what was requested, what was changed, what was withheld, and why.

This is where identity governance and data governance should converge. The privacy workflow needs the same lifecycle discipline highlighted in Ultimate Guide to NHIs — Key Challenges and Risks, because partial visibility creates partial compliance. NIST’s Privacy Framework and ISO/IEC 27701 both support this lifecycle mindset even though neither replaces legal review. These controls tend to break down when the organisation has fragmented directories, unmanaged SaaS apps, or data copied into export files and analytics systems that were never wired into the request workflow.

Common Variations and Edge Cases

Tighter erasure controls often increase operational overhead, requiring organisations to balance stronger subject-rights execution against retention duties, legal holds, and system complexity. That tradeoff is real, especially in regulated sectors where some records cannot be fully deleted on demand.

One common edge case is partial erasure. A subject may request deletion, but the organisation may need to retain transaction logs, fraud evidence, or statutory records for a defined period. Another is access requests in environments where data is replicated into archives, backups, or analytics platforms. Best practice is evolving here: there is no universal standard for how every replica must be handled, so teams should document the approved approach by data class and system type.

Identity systems also help prevent over-disclosure. Access requests should not expose more data than the requester is entitled to receive, and erasure requests should not silently break records needed for security investigation or service integrity. The 52 NHI Breaches Analysis is a useful reminder that identity failures usually become visible after impact, not before. For GDPR, the same applies when request handling is poorly instrumented: the issue is often not the policy, but the absence of reliable execution evidence.

Related resources from NHI Mgmt Group

• Who is accountable when an attacker reuses valid access to move through systems?
• How should organisations reduce HIPAA violation risk through identity controls?
• What should organisations ask before adopting a cloud identity service?
• What should organisations do when mobile device management and identity policy conflict?