A server audit specification selects instance-level actions for recording and attaches them to a server audit object. It can capture login attempts, backup and restore operations, database creation or deletion, permission changes, impersonation, and configuration changes. section 14.5
Mistake: auditing activity but not audit changes
Leaving out AUDIT_CHANGE_GROUP creates a blind spot: an administrator could disable or alter the audit, perform a harmful action, and reenable it. Include audit changes and store records in the Windows security log to support nonrepudiation and limit tampering. section 14.5
Listing 14.7 Creating an audit specification
CREATE SERVER AUDIT SPECIFICATION AdminActivitySpecification FOR SERVER AUDIT AdminActivityAudit ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP), ADD (AUDIT_CHANGE_GROUP), ADD (DBCC_GROUP), ADD (SERVER_OBJECT_PERMISSION_CHANGE_GROUP), ADD (SERVER_PERMISSION_CHANGE_GROUP), ADD (SERVER_PRINCIPAL_IMPERSONATION_GROUP), ADD (SERVER_OBJECT_CHANGE_GROUP), ADD (SERVER_PRINCIPAL_CHANGE_GROUP), ADD (SERVER_OPERATION_GROUP), ADD (SERVER_STATE_CHANGE_GROUP), ADD (SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP) ;
Use the T-SQL definition as a practical starting checklist for privileged-action coverage, including role membership, permissions, impersonation, object changes, and server state. section 14.5
Keep the specification focused: excessive low-level auditing can affect performance on a busy server. Use database audit specifications separately for fine-grained activity such as SELECT statements, creating one in each database that requires coverage. section 14.5
