SQL servers should have vulnerability assessment configured

What does the recommendation "SQL servers should have vulnerability assessment configured" check?

Flags any single Azure SQL logical server (Microsoft.Sql/servers) that does not have SQL vulnerability assessment configured to scan its databases for misconfigurations and weak settings. It checks only that the scanner is switched on and able to run, not that the findings have been triaged or resolved: a server with hundreds of open findings still passes this control as long as assessment is configured. It targets logical servers, not Azure SQL Managed Instance flexible deployments or Azure Database for MySQL and PostgreSQL flexible servers, which carry their own separate recommendations.

Why does "SQL servers should have vulnerability assessment configured" matter?

A SQL server drifts out of a safe baseline quietly: a permission gets widened during an incident, transparent data encryption is left off a new database, auditing is disabled to chase a performance problem. Without a recurring vulnerability assessment, nobody sees that drift until an auditor or an attacker does. The scan compares each database against a hardening baseline and surfaces excessive permissions, missing encryption and risky configuration as actionable findings, so a weakness that would otherwise sit unnoticed for months becomes a tracked item with an owner. For a database holding customer or regulated data, that gap is the difference between catching a misconfiguration in a weekly report and explaining it in a breach notification.

How do I fix "SQL servers should have vulnerability assessment configured"?

1. Enable the Microsoft Defender for Azure SQL plan on the subscription, which is the prerequisite for the scanner: az security pricing create --name SqlServers --tier Standard.
2. Configure vulnerability assessment in the express model so it needs no customer storage account: turning the Defender for Azure SQL plan on enables it automatically for new databases, and you can confirm or enable it per server under the database's Defender for Cloud blade in the Azure portal, then run an on-demand scan to seed the baseline.
3. Make it the default at scale by assigning the built-in audit policy so any new server without assessment is reported: pid=$(az policy definition list --query "[?displayName=='Vulnerability assessment should be enabled on your SQL servers'].name" -o tsv); az policy assignment create --name sql-va-configured --policy "$pid" --scope /subscriptions/<subscription-id>.

# Step 1: close coverage gaps. Enable the scanning plans on the subscription.
SUB="/subscriptions/00000000-0000-0000-0000-000000000000"

az security pricing create --name VirtualMachines --tier Standard
az security pricing create --name SqlServers       --tier Standard
az security pricing create --name Containers       --tier Standard

# Step 2: list the machines that still have no assessment solution attached.
az security assessment list \
  --query "[?metadata.displayName=='Machines should have a vulnerability assessment solution' && status.code=='Unhealthy'].resourceDetails.id" \
  -o tsv

# Step 3: ratchet it shut. Enforce that the plans stay enabled estate-wide,
# so no new subscription can become an unscanned blind spot. Assign the
# built-in initiative 'Configure Microsoft Defender for Cloud plans'
# (DeployIfNotExists), which turns the Servers, SQL and Containers plans
# back on wherever they are missing.
az policy assignment create \
  --name enable-defender-plans \
  --display-name "Configure Microsoft Defender for Cloud plans" \
  --policy-set-definition f08c57cd-dbd6-49a4-a85e-9ae77ac959b0 \
  --scope "$SUB" \
  --mi-system-assigned --location uksouth