What’s the issue?
SQL Server Audit captures activity through action groups, each covering a category of events. A server audit specification defines which groups are collected, and only the events in those groups are recorded, so the value of an audit depends entirely on which groups were selected when it was configured.
A small set of groups covers the activity most relevant to detecting and investigating a security incident: FAILED_LOGIN_GROUP for authentication failures, SERVER_ROLE_MEMBER_CHANGE_GROUP for changes to server role membership, SERVER_PERMISSION_CHANGE_GROUP for grants and revokes of server-level permissions, SERVER_PRINCIPAL_CHANGE_GROUP for logins being created, altered, or dropped, and AUDIT_CHANGE_GROUP for changes to the audit configuration itself.
This check identifies instances where SQL Server Audit is running but is not capturing one or more of these groups, detected by reviewing sys.server_audit_specification_details.
Why is this a problem?
Without these groups, the audit records activity that may satisfy a compliance checkbox while missing the events that actually matter during an investigation. An audit that captures schema changes and data access but not permission grants cannot answer the first question asked after an incident: how the attacker gained the access.
Each missing group leaves a specific blind spot. No failed login data means brute-force activity is invisible, no principal or permission change data means privilege escalation leaves no trace, and no role membership data means an account added to sysadmin appears no different from one that was always there.
AUDIT_CHANGE_GROUP is the one that protects the rest. Without it, an attacker with sufficient privileges can alter or disable the audit specification, remove the groups that would have recorded their activity, and leave no record that the audit configuration was ever changed.
What should you do about this?
Review the current configuration by querying sys.server_audits, sys.server_audit_specifications, and sys.server_audit_specification_details to see which action groups are being collected and confirm the audit and its specification are both enabled.
Add the missing groups with ALTER SERVER AUDIT SPECIFICATION [SpecName] ADD (FAILED_LOGIN_GROUP); and equivalents for each. The specification must be disabled before it can be altered and re-enabled afterward, so plan the change accordingly.
Confirm the audit destination has capacity for the additional volume, particularly for failed logins on a busy instance, and that file rotation and retention are configured so the audit cannot fill its volume. Verify the audit data is actually being reviewed, since a well-configured audit that no one reads provides no detection value.