September 14, 2025 at 6:22 pm
Hello Everyone!
My organization is looking to implement a solution in SQL Server (2019 , 2022) that allows us to monitor all data modifications — INSERT, UPDATE, and DELETE operations — made by human users (e.g., DBAs, analysts, or developers) while excluding changes made by system or application service accounts.
Has anyone implemented a solution like this successfully? Any suggestions for tools, configurations, or best practices that strike a good balance between visibility and performance on a reasonable price if possible?
Thank you in advance!
Regards,
Konstantin
September 15, 2025 at 9:09 am
First question in any and all auditing requirements is
Does this audit need to be legally binding?
Like if it's related to HIPPA / GDPR etc etc data, and you have to stand in a court of law and say, User X, accessed/modified/deleted data Y about Subject Z, and thus you are legally obligated to store that info.
If yes you want an appliance like Imperva or Guardium, something which sits OUTSIDE of the SQL Engine.
Reason for this is that anything INSIDE the engine isn't 100% tamper proof, especially if people have sysadmin like your DBAs.
If you don't have to be legally binding, then the best way would be to get something like https://www.idera.com/products/sql-compliance-manager/ and have your security team be the administrators.
Anyone with any level of access to the server to modify things shouldn't be allowed to be in Compliance, have clear separation of duties. Just another level of protection.
But if you must do this at a SQL level using SQL Audit, it's going to get very very complicated real fast depending how you handle security and how you do the filtering on the audit.
It probably hasn't changed but if you use AD Groups / Entra Groups to control access to the SQL instance, well they are now useless, you cannot audit on a group, but on individuals, so now you need to add each user explicitly into the instance and explicitly into the audit.
Have a new user, add them to instance add them to audit.
Then you have the fact that audit is NOT tamper proof.
Anyone with enough access can stop the audit, do what they want and enable the audit.
OK it will log the audit was stopped but what if that person who stopped the audit wasn't the one who touched the data? You point blame in the wrong place, but then you can ask why they stopped the audit, but you'll never be sure they did touch the data.
If you write to a SQLAudit log file, again anyone with enough access to the log files can then tamper with the file data and corrupt it.
So generally it's best to log to the system / application event log and have a SIEM tool pull the log entries.
Again not tamper proof if someone stops the audit.
So
Legally Binding - Get an appliance
More compliance than legal - Get something like Idera
Can't afford anything like that, do it in SQLAudit, but admin becomes a burden and it's not tamper proof and you need to pay for a SIEM tool.
September 18, 2025 at 8:19 am
Hey,
Thanks a lot for your time and for sharing your insights!
I’ve seen this tool recommended in a few places [Idera], and with your feedback, it’s definitely looking like a solid option now.
Very much appreciated again!
September 24, 2025 at 1:18 pm
Legal issues aside, if you are wanting to setup up something very quickly to see what audits will look like to record, check out the SCHEMA OBJECT ACCESS GROUP audit and specification in SQL server.
Also check out how to write the results to a media (disk, table etc...) and how to filter the results so you are not inundated with every user and system read/write operation.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply