Diagnostic logs in Key Vault should be enabled

What does the recommendation "Diagnostic logs in Key Vault should be enabled" check?

Flags any standard Key Vault that has no diagnostic setting streaming the 'AuditEvent' resource log category to a destination (Log Analytics workspace, storage account or event hub). AuditEvent records every data-plane interaction with the vault: who read a secret, retrieved a certificate, signed with a key, or was denied. It checks only that a diagnostic setting exists and is sending these logs somewhere. It does not verify the retention period, whether anyone actually queries the logs, or whether alerts are wired up, and it does not cover Managed HSM, which is governed by a separate recommendation. The underlying built-in policy ('Resource logs in Key Vault should be enabled') is audit only, so it never changes a vault for you: it simply reports the gap and leaves the diagnostic setting to be created.

Why does "Diagnostic logs in Key Vault should be enabled" matter?

Key Vault is where the most sensitive material in a subscription lives: database connection strings, signing keys, TLS certificates. Without AuditEvent logging, a leaked secret or an over-privileged identity quietly reading every secret leaves no trace, so you cannot answer the first question every incident response asks: what was accessed and by whom. The data plane is also invisible to the activity log, which only records management operations, so this is the sole record of reads. When a breach is suspected, the absence of these logs turns a scoped, evidence-led investigation into a worst-case assumption that every secret is compromised and must be rotated, which is far more costly and disruptive. Many regulatory regimes also require a demonstrable access trail for cryptographic material, so a vault without AuditEvent logging can be an audit finding in its own right, independent of any actual compromise.

How do I fix "Diagnostic logs in Key Vault should be enabled"?

1. On the vault, open Monitoring then Diagnostic settings, add a setting, tick the 'audit' category group (or the 'AuditEvent' category) and send it to a Log Analytics workspace you retain for forensics.
2. To script it, run: az monitor diagnostic-settings create --name kv-audit --resource <key-vault-resource-id> --logs '[{"category":"AuditEvent","enabled":true}]' --workspace <log-analytics-workspace-id>
3. To enforce it across the estate, assign the built-in DeployIfNotExists policy that configures diagnostic settings for Key Vault to a Log Analytics workspace, looked up by exact name rather than a pasted GUID: pid=$(az policy definition list --query "[?displayName=='Configure diagnostic settings for Azure Key Vault to Log Analytics workspace'].name" -o tsv) then az policy assignment create --name kv-diag-logs --policy "$pid" --scope <scope> with a remediation task so existing vaults are backfilled.

# 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"