A database audit is the systematic recording and review of database activity: who connected, which statements they ran, which objects and rows they read or changed, when, from where and with what result. In database security, auditing provides accountability and evidence, complementing preventive controls such as database roles, row-level security and database encryption, which limit access but do not record how access was used.
The term covers both the audit trail, the stored log of events, and the audit process, the periodic examination of that trail and of database configuration against policy. Regulations and standards such as PCI DSS, HIPAA, SOX and GDPR commonly require some form of database auditing for systems that hold payment, health, financial or personal data.
How database auditing captures activity
Database auditing captures activity by intercepting events inside or around the database engine and writing a structured record for each event that matches an audit policy. A typical record contains the user and role, client address, application name, timestamp, statement or action type, target object, and success or failure.
Collection happens at one of several layers, and each layer sees a different slice of reality. Engine-level auditing sees every statement, including those from administrators, while network-level monitoring sees traffic without adding work to the database server.
| Approach | How it works | Strength | Limitation |
|---|---|---|---|
| Native engine auditing | Built-in audit feature writes events per policy | Complete view, including privileged users | Overhead on the database server |
| Trigger-based auditing | Triggers copy changed rows to history tables | Captures old and new values | Misses reads; can be disabled by owners |
| Log-based capture | Reads the transaction or binary log | No query overhead | Sees changes only, not reads |
| Database activity monitoring | Agent or network sensor inspects traffic | Separation from database administrators | Encrypted or local traffic needs agents |
Native features include the PostgreSQL pgAudit extension, SQL Server Audit, Oracle unified auditing and the audit plugins of MySQL and MariaDB. Each lets administrators define policies by user, object and action rather than logging everything.
What a database audit policy should record
An effective database audit policy records events with security or compliance meaning and leaves out routine noise. Auditing every SELECT on a busy system can generate gigabytes per hour and bury the events that matter.
| Event category | Examples | Typical priority |
|---|---|---|
| Authentication | Logins, failed logins, logouts | Always record |
| Privilege changes | GRANT, REVOKE, role membership changes | Always record |
| Schema changes | CREATE, ALTER, DROP of tables or users | Always record |
| Sensitive data access | Reads of card, health or salary tables | Record for named objects |
| Data modification | INSERT, UPDATE, DELETE on regulated tables | Record, often with row identifiers |
| Routine application reads | Catalog and product queries | Usually excluded |
Privileged users deserve the strictest coverage, because administrators can bypass application controls. Their activity should be recorded regardless of object, and the records should be stored where those same administrators cannot alter or delete them.
Database audit compared with related security controls
A database audit is a detective control: it does not stop an action but makes it visible and attributable. Neighboring controls in database security are mainly preventive.
| Control | Type | Question it answers |
|---|---|---|
| Database audit | Detective | Who did what, when and from where |
| Database role | Preventive | Which actions a user may perform |
| Row-level security | Preventive | Which rows a user may see or change |
| Database encryption | Preventive | Whether stolen files or backups are readable |
| Change data capture | Integration | Which rows changed, for downstream systems |
Change data capture and auditing are often confused. Change data capture streams data changes for replication or analytics and usually does not record reads, failed attempts or the human identity behind an application connection, all of which an audit needs.
Protecting and using the audit trail
An audit trail is only valuable if it is complete, tamper-resistant and actually reviewed. Most compliance failures concern the second and third points rather than collection itself.
- Forward audit records promptly to a separate log system or SIEM under a different administrative domain.
- Use append-only or write-once storage and integrity checks such as hash chaining.
- Synchronize clocks with NTP, so events from several servers can be correlated.
- Define retention periods per regulation, commonly one year or longer, with recent months readily searchable.
- Configure alerts for high-risk events, such as privilege grants outside change windows or bulk exports of sensitive tables.
Applications that connect through one shared service account weaken attribution. Passing the end user’s identity as a session attribute or application context lets the audit record show which person triggered a statement, not only which application.
Performance impact and common mistakes
Audit overhead depends on event volume and destination, not on the feature itself. Narrow policies writing asynchronously typically add a few percent of load, while statement-level auditing of every query on a busy OLTP system can cost far more and fill disks quickly.
| Mistake | Consequence | Fix |
|---|---|---|
| Auditing everything | Storage growth, slow queries, unreadable logs | Policy limited to sensitive objects and actions |
| Logs stored on the database server | Administrators can erase evidence | Forward to a separate system |
| Logging full statements with literals | Sensitive values copied into logs | Mask or parameterize logged values |
| No review process | Breaches discovered months later | Scheduled reviews and automated alerts |
In simple terms
A database audit works like the visitor log and security cameras of a records office. It does not stop anyone from entering. It notes who came in, which files they opened and what they changed.
If something goes wrong, the log shows exactly what happened and who was responsible. For the log to be trusted, it must be kept somewhere the visitors cannot reach. Someone must also actually read it from time to time.
A practical example
A regional health insurer stores claims and diagnoses in a PostgreSQL database. To meet its regulatory obligations, the security team enables pgAudit with a policy that records all logins, all role and schema changes, every administrator statement and every read of the diagnosis and patient tables.
Audit records stream to a separate log platform that database administrators cannot modify, and an alert fires when any account reads more than 5,000 patient rows in an hour. Three months later, the alert flags a support employee exporting patient lists outside working hours. The trail shows the exact queries, times and client address, which allows the insurer to revoke access within the hour and document the incident for regulators with complete evidence.