Privacy by Design in .NET

Privacy is not enforced by legal teams. It is enforced by how you design database schemas, structure APIs, implement logging, and manage data workflows. Privacy by design means treating personal data as toxic waste requiring systematic containment and controlled disposal.

Most organizations treat privacy as a compliance checkbox. They implement a “right to be forgotten” button, display a privacy policy, and consider the requirement satisfied. In reality, personal data continues flowing through applications unchecked—captured in logs, stored in caches, replicated across databases, archived in backups. A deletion request arrives, but the system cannot actually fulfill it because it was never designed to support data deletion.

Privacy Engineering Practices

Effective privacy implementation requires architectural decisions: separating personal data from operational data, implementing retention policies in code, exposing data access endpoints, tracking data lineage, and designing APIs that respect purpose limitation. These are not add-on features—they are foundational design properties.

ISO/IEC 27701 provides the framework for implementing privacy as a measurable engineering discipline rather than a compliance afterthought.

Your Privacy Docs Are Fiction: Let's Fix That with .NET CLI Tools

Spreadsheet-based privacy audits examine yesterday’s system while today’s code deploys undocumented PII. Build .NET CLI tools that discover all personal data, catch expired consents, and verify deletions. Then fail builds when compliance breaks.

Purpose Limitation in API Design: Leaking Data You Shouldn't

Most APIs expose personal data based on database entities, not caller needs. When a password reset endpoint returns a user’s full profile, purchase history, and marketing preferences, that’s purpose drift. This article shows how to restructure ASP.NET Core APIs around caller purposes using resource-based authorization, consent validation, and field-level access control.

"Just Delete the User": Famous Last Words Before the GDPR Audit

Your PM thinks erasure is a quick database DELETE. Three weeks later, you’ve found user data in seventeen places: production DB, analytics warehouse, Redis cache, Elasticsearch, backup tapes, and that legacy system nobody dares touch. “Delete” actually means orchestrating coordinated erasure across distributed systems, maintaining audit trails, notifying third parties, and proving it worked. This guide shows the fatal patterns I’ve seen fail spectacularly, then walks through proper orchestration with Azure Durable Functions, soft-delete with anonymization, verification checks, and immutable audit logs.

Privacy Health Checks: Beyond Database Connectivity

Your health checks verify database connectivity every 30 seconds. Great. But do they know that 15% of your users have expired consents? Privacy compliance isn’t a documentation exercise—it’s an operational discipline. Same IHealthCheck interface, different questions. Two queries, one ratio, three possible outcomes. Here’s how to build privacy health checks that turn audit questions into dashboard demos.

Nobody Runs Your Cleanup Script (And Regulators Know It)

“Storage is cheap” — until your data retention strategy becomes evidence in a GDPR lawsuit.

After 15+ years in enterprise software, I’ve seen this pattern in project after project: elaborate wiki documentation, a cleanup script nobody runs, and production databases growing exponentially with personal data that should have been deleted years ago. The compliance checkbox is marked, but the actual deletion never happens.

When regulators investigate, they don’t want your policy documents. They want execution logs proving deletion actually happened. Azure Storage lifecycle policies, Cosmos DB TTL, and scheduled Functions give you exactly that — automated retention that runs without human intervention, with full audit trails.

Cookie Banners Won't Save You From ISO 27701

That boolean column you call “consent”? Regulators will laugh at it.

ISO 27701 demands granular, auditable, expiring consent, not cookie theater. Here’s the complete .NET implementation with Entity Framework Core, middleware validation, and Azure Functions that survives an audit.

Stop Hoarding Personal Data in Entity Framework

The classic monolithic User entity—stuffed with birth dates, phone numbers, employment history, and marital status “just in case”—turns into a compliance nightmare the moment someone requests data deletion. You can’t delete without breaking referential integrity. You can’t keep the data without violating GDPR. You can’t anonymize without retaining fields that should never have existed. The solution isn’t complex: separate operational data from personal data, make consent-based fields nullable and purpose-documented, implement soft deletes with query filters, and validate your API boundaries with integration tests that fail when unnecessary fields leak through. Data minimization isn’t regulatory overhead—it’s architectural hygiene that makes your deletion logic straightforward and your audit responses honest.