ISO Standards for .NET Developers

ISO standards stopped being a compliance-department problem the moment developers started writing the infrastructure. ISO/IEC 27001, ISO/IEC 27017, and ISO/IEC 27701 define the controls; the Bicep template, the Key Vault reference, and the AuthenticationHandler decide whether the controls actually hold. The articles in this collection translate the standards into the .NET and Azure decisions that implement them, control by control.

The three standards overlap deliberately. 27001 defines the Information Security Management System — access control, cryptography, operations, incident response — and is the one most enterprise contracts require. 27017 adds cloud-specific controls on top: shared-responsibility boundaries, administrator separation, virtual network isolation, the assumptions that on-premises 27001 guidance leaves implicit. 27701 layers privacy onto 27001 and is how the standard becomes GDPR-relevant: consent management, data subject rights, purpose limitation, data minimization.

Articles map controls to working code. Access Control (A.9) becomes ASP.NET Core authorization policies and Azure RBAC role assignments. Cryptography (A.10) becomes Data Protection key isolation and Key Vault-backed key wrapping. Operations Security (A.12) becomes audit log shipping to Application Insights with retention policies that survive a tenant move. Each article picks one control, explains what the auditor will look for, and shows the implementation that produces evidence rather than paperwork.

The companion series at iso-standards series walks the controls in publication order. This tag aggregates every article that touches an ISO control, including the cross-cutting pieces on Infrastructure as Code, supply chain security, and incident response that map to multiple standards at once. The recurring theme: compliance lives in the codebase, not in the policy document.

Your Azure SQL Is Public Right Now. ISO 27017 Demands You Fix It

Your Azure SQL Is Public Right Now. ISO 27017 Demands You Fix It

That SQL Server you deployed last week? Publicly accessible. That Storage Account? Same story. Azure defaults are security theater. ISO 27017 calls this a compliance violation, and your next audit will too. Stop trusting “cloud-native” to mean “secure” and start implementing VNets, Private Endpoints, and NSGs before your data becomes someone else’s problem.
Your Encryption Is Broken — .NET Data Protection Done Right

Your Encryption Is Broken — .NET Data Protection Done Right

Every developer who has tried simple encryption with XOR and hardcoded keys eventually faces the audit that exposes their house of cards. I’ve watched production systems fail compliance assessments because someone believed base64 encoding was good enough or that compilation obscures secrets. The .NET Data Protection API exists precisely because Microsoft’s cryptography team spent years solving problems most developers don’t know they have. This isn’t about learning yet another library—it’s about understanding why professional implementations outperform clever hacks, and how Azure Key Vault integration transforms theoretical security into auditable compliance.
Your appsettings.json Is a Compliance Violation

Your appsettings.json Is a Compliance Violation

Hardcoded secrets aren’t just bad practice—they’re ISO 27017 violations with real consequences: failed audits, denied insurance claims, contractual penalties. That connection string in your appsettings.Production.json? It represents a compliance gap your organization probably doesn’t even know exists. Azure Key Vault with Managed Identity isn’t an optional security enhancement—it’s the minimum viable implementation of standards you already claim to follow.
Audit Logging That Survives Your Next Security Incident

Audit Logging That Survives Your Next Security Incident

Your audit logs probably won’t survive a real security incident. Most implementations log too much, protect too little, and provide zero value when something breaks at 2 AM. Here’s how to fix that with structured logging that actually works.
Your [Authorize] Attribute Is Compliance Theater

Your [Authorize] Attribute Is Compliance Theater

Your [Authorize] attributes give you a false sense of security. ISO 27001 auditors see right through it.

I’ve reviewed dozens of ASP.NET Core apps that authenticate flawlessly — then scatter role strings across business logic, skip audit logs, and wonder why they fail compliance. Here’s the pattern that kills audits, and how to actually fix it.