# Azure SQL Database Auditing Not Enabled > ZopNight flags an Azure SQL database when the discoverer-stamped audit_enabled flag reads exactly "false", meaning server-level auditing is off and no queries, logins, or changes are being logged. Rule RC-1331 rates this medium severity, abstains when the flag is absent, and the fix, server-level auditing, covers every database on the server at once. Source: https://zop.dev/integrations/azure/recommendations/azure-sql-database-auditing-not-enabled Updated: 2026-08-19 --- ## The forensic gap an auditor will find first With auditing off, an Azure SQL database keeps no record of who queried it, who logged in, or what changed. When something goes wrong (a data leak, a dropped table, an access-review question), there is nothing to reconstruct from. Most compliance frameworks that touch databases (SOC 2, PCI DSS, HIPAA) expect database event logging, and "auditing: disabled" is one of the fastest findings an assessor can write up. The exposure is not that an attacker gets in more easily; the exposure is that nobody can prove what an attacker, or an insider, did once inside. ## Detection is proved, not inferred ZopNight does not guess from tags or naming. The Azure discoverer reads the live server auditing settings through the ARM API and stamps the result into resource metadata as `audit_enabled`. Rule RC-1331 fires only when that flag is exactly `"false"`. When the flag is absent, whether from an enrichment gap or a permission problem, the rule abstains rather than speculating. An earlier version of this rule read a customer-controlled tag with a key no producer ever wrote, so it could never fire; the current gate reads provider truth only. Everything the detection needs is covered by the built-in **Reader** role. ## One server setting, every database covered Azure SQL auditing set at the server level is inherited by all databases on that server, which is why the discoverer captures the server-level state. Fixing it once at the server fixes current databases and every database created later. The class-level remediation is strictly better than enabling auditing database by database. You choose a destination (storage account, Log Analytics workspace, or Event Hub) and a retention period that matches your compliance requirements. ## Check a server's auditing policy yourself ```bash az sql server audit-policy show \ --resource-group --name \ --query "{state:state, storageEndpoint:storageEndpoint, retentionDays:retentionDays}" ``` `state: Disabled` reproduces exactly what the rule saw. ## What the finding costs Nothing is saved by fixing this: the recommendation carries $0 and lives in the compliance category. Auditing itself has a cost consequence worth knowing up front: logs written to a storage account or Log Analytics accrue storage charges that scale with query volume and retention, so pick a retention window deliberately rather than defaulting to forever.