I ❤️ .NET

Table of Contents

1. What we gonna do?
2. Why we gonna do?
3. How we gonna do?
4. Summary

What we gonna do?

Ever tried to erase a user from your system, only to realize their data is hiding in places you never expected? The Right to Be Forgotten isn't just a checkbox for compliance—it's a high-stakes, all-or-nothing game for anyone storing personal identifiable information (PII) in .NET applications. In this article, we'll break down what it really means to "forget" a user, why it's so tricky, and how to do it right in your ASP.NET Core projects.

Why we gonna do?

Storing PII is a responsibility, not a privilege. Regulations like GDPR give users the right to request complete erasure of their data—no ifs, ands, or backups. But here's the thing: PII isn't just in your main database. It lurks in logs, event stores, request headers, and even offsite backups. Miss a spot, and you could face legal trouble or a costly data breach.

A common misconception? That deleting a user record is enough. In reality, PII can persist in logs, backups, and third-party services. Anonymizing data is only safe if it's truly irreversible. And don't forget: some data (like payment history) may need to be retained for legal reasons, but it must be stripped of all identifying details.

How we gonna do?

Let's get practical. Here's how to implement the right to be forgotten in your .NET applications:

Step 1: Provide a User-Initiated Delete Option

Whether it's a button in the user profile or a support request, users must have a clear way to request deletion. For example, an API endpoint:

[HttpDelete("/api/users/{userId}")]
public async Task<IActionResult> DeleteUser(string userId)
{
    // ...existing code...
    await _userService.DeleteUserAndPIIAsync(userId);
    return NoContent();
}

Step 2: Delete or Anonymize All PII

Your deletion logic must cover every storage location: databases, logs, event stores, backups, and third-party services. For logs, consider hashing or removing PII:

Note: Refer to the Improve Data Security by Redacting Logs in .NET article for detailed strategies on how to handle logs securely.

// Instead of logging raw PII:
_logger.LogInformation($"Order placed by {user.Email} at {user.Address}");

// Log anonymized data:
_logger.LogInformation($"Order placed by userId: {user.Id}");

If you must keep records (e.g., for accounting), strip all identifying details:

// Anonymize order data
order.Name = null;
order.Address = null;
order.Phone = null;
// ...existing code...

Step 3: Don't Forget the Hidden Places

PII can hide in request headers, JWT tokens, backups, and even in-memory caches. Make sure your deletion process covers:

• Application logs and error logs
• Request/response logs (including headers)
• Event stores and message queues
• Offsite/cloud backups
• Third-party analytics or monitoring tools

If you can't guarantee deletion from a location, don't store PII there in the first place.

Step 4: Make Deletion Irreversible

The right to be forgotten should be a one-way street. Hard delete is often safer than anonymization—if you anonymize, make sure it's truly irreversible. Never keep a mapping that could restore the original data.

Summary

The right to be forgotten is more than a legal checkbox—it's a technical challenge that demands discipline and thoroughness. Deleting a user means deleting every trace of their PII, everywhere it might exist. Miss a spot, and you risk compliance failures or worse. Build your systems with deletion in mind, audit your data flows, and always err on the side of caution. When in doubt, forget more, not less.