Client: A Southeastern US orthopedic specialty group of roughly 200 users, running a hybrid Azure estate — multiple subscriptions, Microsoft Sentinel, Azure Virtual Desktop, Azure OpenAI, and on-premises domain controllers — that had grown faster than its security governance.
The challenge
An external auditor asked the group to show evidence of centralized audit logging. Our review found a SIEM design that was sound in principle but full of silent gaps:
- Resource-level auditing was effectively absent. There were no diagnostic settings across 13 Key Vaults, 33 storage accounts, the production SQL server, 23 network security groups, and 24 App Services. HIPAA §164.312(b) and NIST AU-12 expect a record of what happens inside those resources. That record did not exist.
- Log ingestion had sprawled to roughly 1,365 GB a month in a single Sentinel workspace, with high-volume tables on the most expensive plan.
- Azure OpenAI traffic meant to stay private was crossing the public internet. The private endpoints resolved to public IP addresses — a serious exposure for a workload next to patient data.
- Security telemetry was kept for only 30 days, with no long-term compliance archive.
What we did
We delivered an assessment mapped to the NIST 800-53 AU control family. We then carried out the fixes as formally change-controlled changes (Engineering Change Notice plus Change Advisory Board sign-off), each with snapshots, verification, and a rollback path.
- Closed the Private Link exposure in development and production by attaching private DNS zone groups to the OpenAI endpoints and correcting VM-level DNS. Verified end to end, with no service interruption.
- Re-engineered log ingestion and retention. High-volume, low-signal tables moved to cheaper plans, noise is filtered at ingest, and a 7-year compliance archive now lives in tiered blob storage.
- Added a governance guardrail: a separate, capped operational workspace, so non-security workloads cannot quietly re-inflate the SIEM.
- Ran a post-change audit six weeks later. It caught two failures that a simple “is the setting still there?” check would never have found.
What the follow-up audit found
Several security tables, once moved to a cheaper plan, were being silently dropped by Sentinel’s detection rules. The queries swallowed the error and evaluated empty data. 33 of 83 detections were running against nothing, and the DNS and threat-intelligence rules had produced zero alerts in 180 days.
We restored the affected tables, recovering 23 detections for about $330 a month and putting 5.1 million security events back in front of the detection rules. The remaining trade-offs were documented as explicit, signed risk acceptance.
We also found that the compliance archive could never move to cold storage because of a blob-type mismatch. We built and ran an idempotent rewrite job that migrated 21,642 blobs (130 GB) with zero errors and 100% verification.
Results
| Outcome | Result |
|---|---|
| Detections restored to live data | 23 of 33 recovered; 5.1M events back in the detection path |
| Long-term compliance archive | 7-year retention at ~$18/month vs. ~$300/month (>90% cheaper) |
| Logging savings identified | ~$33K a year across candidate tables |
| Azure OpenAI exposure | Public-path traffic eliminated in dev and prod, zero downtime |
| Change discipline | Every change under formal ECN / CAB control |
The honest footnote
An early idea — split the SIEM workspace to save money — turned out to save almost nothing, because 99.997% of the data really was security-relevant. We told the client so and kept the split as a governance boundary rather than a cost play. Measured, not assumed.
The client's identity is anonymized. The environment, findings, and results are drawn from a real Hat Boy Software engagement; figures are representative and rounded.