Retain Azure audit and activity logs

Extending SQL audit retention to 90 days costs almost nothing. The only incremental Azure spend is the storage that holds a few extra weeks of audit records, and audit logs are small relative to the data they describe. There is no per-server licence, no premium tier to buy, and no compute charge: you are changing a number on a configuration object. For the overwhelming majority of servers this is a free change, and the cost question is narrow enough to dismiss in a sentence.

Frame the finding as a line on the risk register rather than a compliance checkbox. A SQL server holding regulated or customer data with a 7-day audit window carries a real expected loss: if a breach is discovered a month later, the trail needed to scope it, notify the right people and defend the response is already gone. An empty test server with the same finding carries almost none. Map each failing server to the data behind it and prioritise by what the missing trail would actually cost you.

The arithmetic is one-sided. Keeping 90 days of audit logs is a rounding error on the storage bill. The downside of keeping 7 is that, in the one scenario where the trail matters most, you cannot answer the questions a regulator, an insurer or a court will ask: who accessed this data, and when? That is the asymmetry that makes this an easy approval.

Priya is the finance partner supporting the platform team's SOC 2 push. The security report lands with the audit-retention recommendation failing on six SQL servers across two older subscriptions. The instinct is not to wave through a remediation budget; it is to ask what the change actually costs. The answer is almost nothing: extending audit retention from 7 days to 90 adds only the storage for a few extra weeks of small log files, with no licence and no compute attached. There is no spend decision here worth a meeting.

Priya asks the team to map each failing server to the data behind it. Two hold live payment records, one is a reporting replica of customer data, and the rest are staging or test servers nobody would investigate. The list is reframed on the risk register: the three customer-data servers are high expected-loss items to extend today at trivial cost, because they are exactly the servers where a missing trail would turn a contained incident into an unbounded one, and the test servers are low-value drift to sweep up for tidiness. The finance pack reads: 'All six findings close for the price of a few weeks of log storage; the value is that on the three servers that matter, we can still answer who-touched-what if a breach surfaces late.'

The cost model here is asymmetric in a way that is rare for security work. Keeping 90 days of SQL audit logs costs a trivial amount of storage, and keeping 7 creates a tail risk that only ever materialises at the worst possible time. Each failing server is one where a late-discovered breach could not be scoped, and while the probability of any single incident is low, the cost when it lands is dominated by exactly the questions a short trail cannot answer.

The documented cost of an unscopeable breach is large: mandatory notification under tight regulatory windows, the over-notification penalty when you cannot tell who was affected, forensics that run longer and cost more without a clean trail, legal defence and customer churn. Against that, the remediation is a few extra weeks of cheap log storage. The finance role is to attach expected loss to each failing server, weighted by the sensitivity of the data it holds, so the work is prioritised by what the missing trail would cost rather than by the order the report lists it.

Audit retention is the control that decides whether an incident is investigable. Breaches are routinely discovered weeks or months after the fact. If the database audit trail only goes back a fortnight, the answer to the most important question, who accessed this data and when, is simply gone, and 'we cannot say' is the worst possible thing to tell a regulator or a customer.

The leadership question is not 'are we auditing?' It is 'when something goes wrong, how far back can we actually see?' The defensible end state is that every SQL server keeps at least 90 days of audit trail, and that the setting is enforced by policy rather than left to whoever configured each server.

This is not a cost decision. Keeping 90 days of audit logs is essentially free. It is a governance decision about whether the estate can answer the forensic question by design, or only on the servers where someone happened to set the number high enough.

After an industry peer disclosed a breach they could only partially scope, because their database logs did not reach back far enough, the CEO asked the obvious question at the next review: if we were breached and found out two months later, could we tell who accessed what? The honest answer at the time was that it depended on the server, because audit retention had been set by whoever built each one, and some windows were as short as a week.

The team's response was to stop treating retention as a per-server setting and start treating it as a guardrail. They listed every SQL server, found the ones auditing to storage with a window under 90 days, raised each to at least 90, and then assigned an Azure Policy so that any server configured below the line is flagged and brought into line automatically. The next time the CEO asked the question, the answer had changed from 'on some servers, maybe' to 'yes, every server keeps at least 90 days, and policy keeps it that way.' That shift, from a number someone happened to set to a guarantee the platform enforces, is the one-line confidence signal this capability delivers, and it costs almost nothing in Azure spend to reach.

Nearly every painful breach disclosure has the same subtext: the organisation could not fully say what was taken, because the evidence had aged out. A too-short audit window is the configuration that guarantees that outcome. Keeping at least 90 days, and enforcing it by policy, is the capability that makes the forensic question answerable rather than a guess.

The cost of getting this wrong is large and well documented, while the cost of fixing it is a rounding error on the storage bill. This is the rare class of control where the risk of inaction is severe and the cost of action is negligible, which is exactly the trade leadership should be quickest to approve.