Security & Compliance Engineering
Compliance becomes engineering the moment the auditor asks for evidence and the evidence has to come from a system the developer wrote. Authentication logs, key rotation timestamps, deployment approvals, data-deletion confirmations — every artifact the audit consumes is produced by code, configured by IaC, or absent because nobody decided who owned it. The articles in this collection treat compliance as a control-flow problem in the codebase rather than a document-management problem in SharePoint.
Compliance-as-code content covers the mechanics. Bicep and Terraform modules that enforce the network-isolation and encryption controls instead of leaving them to a reviewer’s checklist. GitHub branch protection and required-reviewer configuration that produce the change-control evidence A.12.1 expects. Dependabot and provenance attestations that satisfy the supply-chain expectations of recent standards without an external scanner stitched on top.
Audit-trail articles focus on what makes a log entry acceptable as evidence. Application Insights with immutable retention, structured logging that survives a schema change without losing correlation, and audit categories separated from operational logs so privacy-relevant events can be retained and queried independently. A log that cannot be queried by control reference during an audit is not an audit trail.
Evidence generation gets explicit treatment. CLI tooling that produces machine-readable compliance verification, health checks that surface privacy-control state alongside operational state, and incident response playbooks codified as GitHub Actions rather than maintained as a Word document nobody opens during the actual incident.
For the ISO/IEC standards that frame most of this content, see the iso-standards tag. The recurring theme here is broader: GDPR, HIPAA, and the ISO family are different vocabularies for the same engineering problem — building systems whose behavior matches their documentation, automatically and continuously.

AKS Disaster Recovery: Why Your Untested Backup Will Fail
Your cluster will fail. The question is not if, but when, and whether you can recover before customers notice. Most organizations discover their backup strategy does not work during an actual outage, when recovery time matters most and manual heroics cannot save you.
If you run Azure Kubernetes Service (AKS) in production, you need a recovery plan that engineers can execute half asleep at 2 AM. We will go through what to back up, how Velero works in day-to-day operations, when Azure Backup for AKS is enough, and how to design realistic failover with measurable Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
The goal is simple: repeatable recovery procedures you have already tested, not a document that looks good in Confluence but fails during an incident.

Audit Logging That Survives Your Next Security Incident

Why ISO Standards Actually Matter for .NET Developers
