Audit setup

A decision tree that, depending on what you want to audit (logins/sessions, DDL/schema changes, data access or privilege changes), enables auditing for that scope on the right database engine, then gives the steps for reading the records and for retention/rotation.

What do you want to audit?

Choose the audit scope. Auditing everything creates noise and cost; narrow it to your needs. Do you want to track login/session events, DDL/schema changes, data access (DML/SELECT) or privilege changes (GRANT/REVOKE)?

• Logins / sessions (login, connect)
• DDL / schema changes (CREATE/ALTER/DROP)
• Data access (DML / SELECT)
• Privilege changes (GRANT / REVOKE)
• Reading audit records and retention / rotation

Login / session auditing

Records successful and failed logins: who connected, from where and when. It is the foundation for detecting unauthorized access and brute-force attempts. Enable the relevant policy per engine, then read and retain the records.

DDL / schema change auditing

Records schema changes such as CREATE/ALTER/DROP. Used to detect unauthorized object changes, hidden tables/backdoors and schema drift.

Data access (DML / SELECT) auditing

Records read/write access (SELECT/INSERT/UPDATE/DELETE) to sensitive tables. Because it can generate high volume, limit auditing to sensitive objects. It is critical for leak detection and compliance (KVKK/GDPR).

Privilege change (GRANT / REVOKE) auditing

Records privilege and role changes (GRANT/REVOKE, role assignment, user creation). It is the foundation for detecting privilege escalation and backdoor accounts; usually low-volume but high-value auditing.

Reading audit records and retention / rotation

Auditing is only useful when the records are read and retained. Define here how to query the records, where they are kept, and the retention/rotation policy that keeps their growth under control.