Auditing on SQL server should be enabled

What does the recommendation "Auditing on SQL server should be enabled" check?

Flags any Azure SQL logical server whose server-level auditing setting (the 'state' property under Microsoft.Sql/servers/auditingSettings) is not Enabled. Server-level auditing applies to every existing and newly created database on that server regardless of each database's own audit settings, which is why this control targets it. It does not override or replace database-level audit policies: if a database also has its own policy, the two run in parallel and that database is audited twice. It does not check database-level audit policies, nor does it verify that the chosen audit destination (a storage account, Log Analytics workspace or Event Hub) actually retains logs, is reachable or has sensible retention. It also does not cover SQL Managed Instance or SQL Server running on a VM, which have their own auditing surfaces.

Why does "Auditing on SQL server should be enabled" matter?

Without auditing, there is no record of who connected, what queries ran or which permissions changed on databases that frequently hold customer and financial data. When an incident happens, a credential is abused or an insider exfiltrates a table, you have nothing to reconstruct the timeline, scope the breach or prove to regulators what was and was not touched. That gap turns a contained event into an open-ended one: investigators cannot tell whether one row or the whole table left, so the safe assumption becomes the worst case and the disclosure widens accordingly. It can also breach contractual or statutory obligations to retain access logs, which carry their own penalties independent of the original incident. Enabling auditing at the server level means every database inherits the trail by default, so a new database created next quarter is covered without anyone remembering to switch it on, and your detection and response tooling has a consistent stream to query.

How do I fix "Auditing on SQL server should be enabled"?

1. Enable server-level auditing and point it at a durable destination: 'az sql server audit-policy update -g <rg> -n <server> --state Enabled --blob-storage-target-state Enabled --storage-account <storage> --retention-days 90'. To send logs to a workspace instead, use --log-analytics-target-state Enabled with --log-analytics-workspace-resource-id.
2. In the portal, open the SQL server, go to Security, then Auditing, set Auditing to On and choose at least one of Storage, Log Analytics or Event Hub as the target. Confirmed at the server it cascades to all databases.
3. Prevent regressions by assigning the built-in audit policy so new servers are caught: pid=$(az policy definition list --query "[?displayName=='Auditing on SQL server should be enabled'].name" -o tsv); az policy assignment create --name sql-auditing --policy "$pid" --scope <subscription-or-rg-scope>.

# Turn on the security-relevant App Service logs and send them to a workspace.
WS=$(az monitor log-analytics workspace show \
  -g central-logging -n estate-logs --query id -o tsv)

for id in $(az webapp list --query "[].id" -o tsv); do
  has=$(az monitor diagnostic-settings list --resource "$id" \
        --query "length(value)" -o tsv)
  if [ "$has" = "0" ]; then
    az monitor diagnostic-settings create \
      --name to-log-analytics \
      --resource "$id" \
      --workspace "$WS" \
      --logs '[{"category":"AppServiceHTTPLogs","enabled":true},
               {"category":"AppServiceAuditLogs","enabled":true},
               {"category":"AppServiceConsoleLogs","enabled":true}]'
    echo "$(basename "$id"): diagnostic logging enabled to estate-logs"
  fi
done

# Ratchet it shut: built-in policy adds the setting to any new App Service.
az policy assignment create \
  --name deploy-appservice-diag \
  --policy 0c6cd767-1a1d-484b-a897-68e398c03aeb \
  --location uksouth \
  --mi-system-assigned \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"