What’s the issue?
SQL Server Audit is the modern auditing framework introduced in SQL Server 2008, used to capture server-level and database-level events for compliance, security monitoring, and forensic purposes. An audit configuration consists of a Server Audit object that defines where the audit data is written (file, Windows application log, or Windows security log) and one or more Server Audit Specifications and Database Audit Specifications that define which events to capture.This finding identifies instances where one or more SQL Audits are currently active. Active audits are not necessarily a problem, but they warrant review to confirm they are still needed and configured appropriately.
SQL Audits are widely used to satisfy compliance requirements (PCI DSS, HIPAA, SOX) and to support security investigations, but they can also produce significant overhead if configured to capture too much.
Why is this a problem?
SQL Audits have a meaningful performance and storage cost depending on what they capture. An audit specification that includes high-frequency events such as BATCH_COMPLETED_GROUP or every successful access to common objects can produce enormous volumes of data, consume CPU and I/O on the SQL Server host, and fill disk volumes if directed to file output without proper size management.Forgotten audit configurations are a common source of operational issues. Audits that were created during a past compliance project, security investigation, or troubleshooting effort sometimes continue running long after their original purpose has ended, accumulating data and overhead with no offsetting benefit. Without periodic review, these audits can persist for years and quietly consume significant resources.
The output destination also matters operationally. File-based audits can fill the configured directory and, depending on how the audit is configured to handle write failures, can either silently lose audit data or shut down the SQL Server service to prevent unaudited activity (which is the default for ON_FAILURE = SHUTDOWN). Either outcome is problematic if not anticipated.
Audit file permissions are another consideration. The directory where audit files are written should be restricted to the SQL Server service account and the security team that reviews the audit data, with no broad access. Audit files contain sensitive event data and should be protected at rest with the same care as any other sensitive log.
What should you do about this?
Review active audits with sys.server_audits and the related audit specification views, and review each one with the team to confirm it is still required, what it is capturing, and where the output is written. Remove audits that are no longer needed by disabling and dropping them along with their specifications.For audits that remain active, review the captured event groups to confirm they are appropriately scoped. Audits should capture the specific events required for compliance or security purposes, not broad event groups that produce excessive volume. Common reductions include filtering to specific databases, specific principals, or specific actions rather than capturing all activity.
Verify the audit destination configuration. For file-based audits, confirm the directory has appropriate permissions, has sufficient free space, and has rotation and retention configured (MAX_FILES, MAX_SIZE, MAX_ROLLOVER_FILES) so it cannot fill the volume. Confirm the ON_FAILURE behavior matches your operational tolerance, since SHUTDOWN and FAIL_OPERATION have very different consequences.