Recovery Services Vault Has No Diagnostic Logging

Azure Recovery Services Vaults sit at the center of your backup and disaster recovery strategy. They hold the backup data for VMs, SQL databases, Azure Files shares, and on-premises workloads protected by MARS or DPM agents. When something goes wrong, the vault is what you reach for. And yet a vault without diagnostic logging is a black box. You can see its current state, but you have no record of what happened to it over time.

The rsv_nologging check catches exactly this situation: a Recovery Services Vault that has zero diagnostic settings configured. No log export, no metric export, nothing leaving the vault for long-term storage or analysis.

---

What this check detects

The check inspects each Recovery Services Vault in your subscriptions and looks at its diagnostic settings. If the vault has no diagnostic setting attached, it fails.

Diagnostic settings on a vault control where its log categories and platform metrics are routed. The available categories include backup job activity, restore activity, alerts, policy operations, and storage configuration changes. When no setting exists, none of that telemetry is captured anywhere durable. The data that the Azure portal shows you in the vault blade is transient and limited, not a substitute for exported logs.

---

Why it matters

Backups are a high-value target. Ransomware operators have learned that deleting or corrupting backups before triggering encryption removes a victim's ability to recover without paying. If an attacker gains access to your vault and deletes recovery points, the diagnostic logs are often the only forensic trail that tells you what was removed and when.

Without logging you lose several things at once:

• Audit trail. No record of who triggered a restore, modified a backup policy, or deleted protected items.
• Recovery assurance. No historical view of whether backup jobs were actually succeeding day to day. A failed nightly job that nobody noticed becomes an unrecoverable gap during an incident.
• Compliance evidence. Frameworks like ISO 27001, SOC 2, and PCI DSS expect demonstrable backup activity logging and retention. An auditor asking for six months of backup job history will not accept "we can see the last few entries in the portal."
• Alerting. You cannot build proactive alerts on backup failures or suspicious deletions if the events never reach a workspace.

Consider a realistic scenario. A finance team's SQL VM is hit by ransomware on a Friday night. On Monday the team goes to restore from the previous week's backup and finds the recovery points gone. With diagnostic logs in Log Analytics, the security team can query AddonAzureBackupJobs, find the delete operations, correlate them to a compromised service principal, and scope the breach. Without logs, the investigation stalls at "the backups are missing and we don't know why."

---

How to fix it

The fix is to attach a diagnostic setting to the vault that routes its logs to a durable destination. A Log Analytics workspace is the most useful target because it supports KQL queries and alerting. You can also send a copy to a storage account for cheap long-term retention or to an Event Hub for streaming into a SIEM.

Option 1: Azure Portal

1. Open the Recovery Services Vault in the Azure portal.
2. Under Monitoring, select Diagnostic settings.
3. Click Add diagnostic setting.
4. Give it a name, for example rsv-to-loganalytics.
5. Under Logs, select allLogs or check the individual backup categories you need.
6. Check AllMetrics if you want metric export as well.
7. Under Destination details, choose Send to Log Analytics workspace and pick the workspace.
8. Click Save.

Option 2: Azure CLI

First grab the vault resource ID and your workspace ID, then create the diagnostic setting:

VAULT_ID=$(az backup vault show \
  --name myRecoveryVault \
  --resource-group myResourceGroup \
  --query id -o tsv)

WORKSPACE_ID=$(az monitor log-analytics workspace show \
  --workspace-name myWorkspace \
  --resource-group myMonitoringRG \
  --query id -o tsv)

az monitor diagnostic-settings create \
  --name rsv-to-loganalytics \
  --resource "$VAULT_ID" \
  --workspace "$WORKSPACE_ID" \
  --logs '[
    {"categoryGroup": "allLogs", "enabled": true}
  ]' \
  --metrics '[
    {"category": "AllMetrics", "enabled": true}
  ]'

Option 3: Terraform

resource "azurerm_monitor_diagnostic_setting" "rsv" {
  name                       = "rsv-to-loganalytics"
  target_resource_id         = azurerm_recovery_services_vault.this.id
  log_analytics_workspace_id = azurerm_log_analytics_workspace.this.id

  enabled_log {
    category_group = "allLogs"
  }

  metric {
    category = "AllMetrics"
    enabled  = true
  }
}

Verify the fix

Confirm the setting exists and is wired to the right destination:

az monitor diagnostic-settings list \
  --resource "$VAULT_ID" \
  --query "[].{name:name, workspace:workspaceId}" -o table

After a backup job runs, query the workspace to confirm data is flowing:

AddonAzureBackupJobs
| where TimeGenerated > ago(24h)
| project TimeGenerated, JobOperation, JobStatus, BackupItemUniqueId
| order by TimeGenerated desc

---

How to prevent it from happening again

Manually attaching diagnostic settings does not scale and tends to drift. The durable fix is policy-as-code so that every vault gets logging automatically, and a CI gate so misconfigured infrastructure never merges.

Azure Policy with DeployIfNotExists

Azure ships a built-in policy that configures diagnostic settings for Recovery Services Vaults to a Log Analytics workspace. Assign it with a deployIfNotExists effect so existing and future vaults are remediated automatically.

# Find the built-in policy definition
az policy definition list \
  --query "[?contains(displayName, 'Recovery Services vaults') && contains(displayName, 'Log Analytics')].{name:name, displayName:displayName}" \
  -o table

# Assign it at the subscription scope with a remediation identity
az policy assignment create \
  --name rsv-diagnostics-enforce \
  --policy "" \
  --scope "/subscriptions/" \
  --location eastus \
  --mi-system-assigned \
  --params '{"logAnalytics": {"value": ""}}'

Then create a remediation task to bring non-compliant vaults into line:

az policy remediation create \
  --name rsv-diagnostics-remediation \
  --policy-assignment rsv-diagnostics-enforce \
  --resource-group myResourceGroup

Gate it in CI/CD

Stop misconfigured vaults before they reach Azure. If you deploy with Terraform, run a policy scan in your pipeline so a vault resource without a paired diagnostic setting fails the build. Tools like Checkov or tfsec can enforce this, or you can write a custom OPA/Conftest rule against the plan output.

# Example: fail the pipeline on policy violations
checkov -d ./infra --framework terraform \
  --check CKV_AZURE_206  # Recovery Services Vault diagnostic logging

---

Best practices

• Pair logging with soft delete. Diagnostic logs tell you when a deletion happened. Soft delete and immutable vaults stop the deletion from being permanent. Use both.
• Centralize the destination. Send vault logs from every subscription to a single shared Log Analytics workspace owned by the security team, so investigations do not require hopping between tenants.
• Retain for your compliance window. Log Analytics is good for active querying, but for multi-year retention required by some frameworks, archive to a storage account with an immutability policy.
• Build alerts on the data. Once logs flow, create alert rules for backup job failures and for delete operations against protected items. Logging without alerting only helps after the fact.
• Scope access tightly. Restrict who can modify or delete diagnostic settings and backup policies. The fewer principals with vault write access, the smaller your attack surface.
• Audit regularly. Re-run this check on a schedule. Diagnostic settings can be removed, workspaces can be deleted, and assignments can drift. Continuous validation catches regressions.

Backup is the last line of defense, and a backup system you cannot observe is one you cannot trust. Turning on diagnostic logging for your Recovery Services Vaults is a small, low-cost change that pays for itself the first time you need to answer the question "what happened to our backups?"