Database auditing is an important task that helps to guide the organization and can point out areas that can be improved, the cause of functions that aren’t quite working as intended, or simply monitoring activity for compliance with government or industry policies. At its core, an audit simply logs events that are happening on the server instance or in a database and saves them out as audit files that can be reviewed after the fact. In general, the objective of Security, Compliance and Auditing is that “all data should remain secure”. There are many techniques and tools available to secure, protect and safeguard the data, but how do you know what’s right for your organization?

In this article on SQL Server Auditing Best practices, we will show the best practices that should be followed to have a successful auditing strategy that complies the company audit policies and requirements.

In this article, we will review triggers in SQL Server, different types of trigger events, trigger order and NOT FOR REPLICATION in triggers. A trigger is a database object that runs automatically when an event occurs. There are three different types of events.

This is the last article, but not least, in the SQL Server Audit series. In this series (see TOC at the bottom), we explained deeply the concept of the SQL Server Audit, why it becomes mandatory for each company to have a SQL Server Audit solution to track and log the different types of events at both the SQL Server instance and database levels. We also went through and compare the different methods that can be used to audit the SQL Server instances and databases.

In the previous article of the SQL Server Audit series, SQL Server Audit Feature Components, we discussed the three main components of the SQL Server Audit feature; the SQL Server Audit, the Server Audit Specifications, and the Database Audit Specifications in details. In this article, we will show how to use the SQL Server Audit feature to track, log and review the different operations performed at both the SQL Server and the database levels.

In the previous articles of the SQL Server Audit series (see the TOC at the bottom), we discussed the concept of the SQL Server Audit, why we need an audit solution to track and log the different events performed in our SQL Server instances and databases, and went through the different methods that can be used to audit the SQL Server databases. In this article, we will discuss the SQL Server Audit feature components and how to configure it.

This article will cover SQL Server C2 auditing using C2 audit mode including an introduction, comparison of auditing technologies, configuration and common criteria compliance

This continuation of our SQL Server auditing series is on SQL Server Change Tracking and will cover an overview, enabling, disabling, auditing DML changes including SQL updates and deletes.

This article on Change Data Capture will provide an overview, notes on installation, architecture, enabling and disabling, auditing DML statements and limitations