As we have seen in the 1st part of this article, in order to solve the overarching problem of easy compliance, we had to solve many different problems main of which were:

1. Capturing of what-was-executed and of other auditing events of interest
2. Fault tolerant auditing
3. Centralized storage of audited data and integrity checks
4. Centralized reporting
5. Prevention from tampering of audited data, or exposure when prevention is not possible (e.g. data tampered by trusted user accounts, hacked or otherwise)

In this 2nd part of this article, we will go deeper into solutions that we applied to each of these problems

ApexSQL has a long history in SQL Server auditing space with two tools that either prepare databases for auditing, or actually perform auditing. ApexSQL Trigger automates creation of triggers (among other things) that track data modifications on selected tables, while ApexSQL Log reads the database transaction log, extracting data modifications from it. Both of these tools show who-did-what, achieving it in different ways, with their own relative strengths and weaknesses. But these tools also lack the means to satisfy stringent regulations on data access (including who-saw-what), and out-of-the-box prevention from tampering, and that is why we built ApexSQL Audit: to make compliance with auditing regulations easy