Turn on diagnostic logging for Azure resources

Turning on a diagnostic setting is free; the cost sits entirely downstream in where the logs land and how long you keep them. Log Analytics charges per gigabyte ingested and retained, an Event Hub charges for throughput, and a storage account is the cheapest tier of all. So unlike most compliance work, this one does carry a real, recurring Azure cost, and the finance job is to make that cost deliberate rather than letting it surprise you on the bill or, worse, leaving logging off to avoid it.

The cost is also controllable. Not every category needs to go to the same place. The high-value security categories, HTTP and audit logs from an internet-facing App Service, justify Log Analytics so you can query them fast during an incident. Bulkier, lower-value categories can go to cheap storage for retention, or be left off. The lever is per-category routing, not an all-or-nothing switch, so the bill scales with the value of the evidence rather than the raw volume.

The risk side is stark. Without logs, the cost of an incident is not just the breach itself but the inability to scope it. You cannot tell an auditor, a regulator or a customer what was accessed, so you have to assume the worst, which is the most expensive assumption there is. A modest, predictable logging bill is the price of being able to say precisely what did and did not happen.

Priya is the finance partner supporting the platform team through SOC 2. The recommendation reads 'Diagnostic logs in App Service should be enabled' across most of the company's web apps, and unlike the storage or firewall findings she has signed off before, this one comes with a price tag, because the logs have to go somewhere and that somewhere charges per gigabyte. Her first move is not to wave through an open-ended logging budget; it is to ask what each app actually warrants. The internet-facing checkout API justifies its HTTP and audit logs flowing to Log Analytics, where the team can query them in seconds during an incident. The internal admin tool and the bulkier console categories can go to cheap storage for retention, or stay off.

Priya asks the team to estimate ingestion volume per app and per category before turning anything on, so the recurring cost is forecast rather than discovered. The picture that comes back is reassuring: the security-relevant categories on the handful of customer-facing apps are a modest, predictable monthly figure, and the long tail of internal apps can retain to storage at a fraction of the cost. The finance pack reads: 'Logging on the customer-facing apps costs a small, forecastable amount per month and is the evidence the SOC 2 auditor will ask for; the alternative, an incident we cannot scope, has no upper bound. We are buying the ability to investigate, and we are routing each category to match its value.'

This is one of the few security controls where the remediation carries a genuine recurring cost, which makes the framing matter more, not less. The cost is the log destination: per-gigabyte ingestion and retention in Log Analytics, throughput on an Event Hub, or the much cheaper storage tier. The finance role is to make that cost deliberate and proportional, routing the high-value security categories on exposed resources to fast, queryable storage and the bulky low-value ones to cheap retention or off, so the bill tracks the value of the evidence rather than the raw volume.

Against that controllable, predictable cost sits an uncontrolled one. The documented cost of an incident you cannot scope includes worst-case breach notification across your entire customer base because you cannot prove who was unaffected, extended forensics that yield nothing because the records were never kept, and the regulatory and reputational consequences of telling a regulator 'we do not know.' A small monthly logging bill is cheap insurance against the most expensive sentence in incident response, and the finance role is to make sure the bill is sized to the evidence, never zeroed out to save money.

Logging is the capability you only notice when it is missing, and the moment you notice is the worst possible one: during an incident, when the question is 'what did they touch?' and the honest answer is 'we do not know, because nothing was recording.' Defender for Cloud flags the gap before that moment arrives, one resource at a time.

The leadership question is not 'are we collecting logs somewhere?' It is 'if something happens on our most exposed resources, can we reconstruct it?' For an internet-facing App Service that means the HTTP and audit logs are flowing to a destination you retain, so an investigation has source material rather than a dead end.

This one does cost a little to run, which makes it a genuine decision rather than a free win. The decision is whether the ability to investigate is worth a small, predictable monthly figure. Framed against the cost of a breach you cannot scope, it nearly always is.

When a peer company disclosed a breach and admitted in the same breath that it could not say which customer records had been accessed, the difference between a contained incident and an open-ended crisis became obvious to the board. The reason that company could not scope its breach was not exotic: the logs on the affected systems had never been collected, so there was nothing to investigate after the fact.

The team's response was to stop treating logging as something each project remembered or forgot and start treating it as a property of the platform. They listed every internet-facing App Service, confirmed each had a diagnostic setting routing its HTTP and audit logs to a retained workspace, and then assigned an Azure Policy that automatically adds the setting to any new App Service that lacks one. The next time the board asked 'if we are breached, can we tell customers exactly what was touched?', the answer moved from 'we hope so' to 'yes, the activity on our exposed systems is recorded and retained by default.' That shift, from logging by good intentions to logging by design, is the confidence signal this capability delivers, and it is bought for a small and predictable running cost.

The breaches that become reputational disasters are usually the ones the company cannot explain. When a board has to tell customers and regulators 'we were breached and we cannot tell you what was accessed,' the damage compounds, because uncertainty forces the broadest and most alarming disclosure. The root cause is almost always the same: the logs were not being kept, because logging was off by default and nobody decided otherwise.

This control is the rare one with a real, if modest, running cost, so it is a deliberate decision rather than a free win. The decision is whether the ability to scope an incident precisely is worth a small, predictable monthly figure. Set against the cost of a breach you cannot bound, it is one of the cheapest forms of insurance leadership can buy, and one of the few that pays out exactly when everything else is going wrong.