Privacy by Design in .NET Systems & APIs

Privacy as an engineering discipline is broader than any one regulation. GDPR is the loudest constraint in Europe, but the underlying principles — data minimisation, purpose limitation, storage limitation, integrity, and accountability — show up in HIPAA, ISO/IEC 27701, the AI Act, and every serious internal security standard. The architectural decisions that satisfy one set generally satisfy the rest. The point of this collection is the architecture, not the regulation.

Data minimisation starts in the schema. An Entity Framework User entity that captures birth date, employment status, and marital status “just in case” is a liability the moment somebody requests deletion. Personal data belongs in its own aggregate, attached by reference rather than embedded as columns, with each field tagged for purpose and consent so a query can answer “what may I still process for this person, and why?” The same principle drives EF Core query filters, projected DTOs that strip unrequested fields, and view-model boundaries that refuse to let a database row leak into a response.

Purpose limitation is the API-side counterpart. A password-reset endpoint that returns a full profile, an internal admin tool that exposes every column to every operator, an analytics export that mirrors production schema — each one violates the constraint that data must only be processed for the purpose it was collected for. Resource-based authorisation in ASP.NET Core, field-level access policies, and explicit DTOs per caller intent are the boring mechanics that make purpose limitation enforceable rather than aspirational.

The articles here also cover the operational half: privacy health checks that surface expired consents alongside database connectivity, audit automation that runs at build time so PII added last Tuesday is caught before production, and log scrubbing patterns that keep personal data out of telemetry pipelines that backups and SIEMs would otherwise retain for years.

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.