Database audit logging records who did what, when, and from where. SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR all require it. Most teams turn it on. Plenty of them still fail audits on it.
The reason is that database audit logging is two systems, not one, and teams usually only have the easy half. The infrastructure layer captures actions on the database: provisioning, configuration, backups, network. The workflow layer captures actions inside the database: schema changes, queries, approvals, exports. Cloud providers hand you the first one for free. The second one is yours to build.
The Two Layers
Infrastructure layer
The infrastructure layer audits actions on the database instance itself:
- Provisioning, deletion, resizing
- Parameter group and configuration changes
- Network and firewall rule changes
- Backup, snapshot, restore operations
- IAM grants and revocations at the cloud level
Cloud providers cover all of this by default. AWS RDS routes events to CloudTrail, Google Cloud SQL writes to Cloud Audit Logs, and Azure Database emits to Azure Monitor. If you run your own instances, you get the equivalent from infrastructure-as-code tooling, container audit logs, and OS-level access logs.
The records are well-formatted, retained centrally, and tied to a cloud principal. For most teams, this layer is already a solved problem, which is exactly why it lulls people into thinking they are done.
Workflow layer
The workflow layer audits actions inside the database:
- Schema changes: DDL applied to a database
- Data changes: DML executed against tables
- Read access: SELECT against sensitive tables
- Approvals: who approved which change, and with what justification
- Exports: who pulled which data, and where it went
- Permission changes: roles and privileges granted to users
Each engine ships its own auditing for this: PostgreSQL pgaudit, MySQL audit plugins, SQL Server Audit, Oracle Unified Auditing. They all work, and they all leave the same three gaps that no amount of configuration closes:
- The identity is the database user, not the human. Most applications and ops scripts connect as
app_useroradmin. The log faithfully records the role, which tells you nothing about who was actually at the keyboard. - The context is missing. The log has the SQL but not the ticket, the approver, or the environment. An auditor wants the why, and the why is not in the statement.
- The coverage is fragmented. Each engine logs in its own format. A multi-engine fleet produces a pile of multi-format trails that no SIEM stitches together cleanly.
This is where most audit findings come from.
Why the Split Matters
Auditors rarely ask whether logging is enabled. They ask you to produce evidence of one specific privileged action: an admin promoting a user, a developer changing a schema, an analyst pulling a customer record. Almost every time, that evidence is a workflow-layer event.
So a team can have flawless CloudTrail coverage and still fail SOC 2, because they cannot show a clean record of who ran the SQL that changed the production schema last Tuesday. We wrote up that exact situation in What SOC 2 Taught Us About Database Audit Logs.
The split is also useful for sorting out who owns what. The platform team owns the infrastructure layer. The data and application teams own the workflow layer. Treating audit logging as one thing tends to blur that line, and blurred lines are where accountability goes to die.
What Each Layer Should Capture
Both layers answer the same four questions: who, what, when, where. The fields are just different.
| Field | Infrastructure layer | Workflow layer |
|---|---|---|
| Who | Cloud principal (IAM user, service account) | End-user identity, mapped from SSO — not the DB user |
| What | API call (ModifyDBInstance, RevokeSecurityGroupIngress) | SQL statement (DDL, DML, SELECT) plus approval and export actions |
| When | API call timestamp | Statement execution timestamp |
| Where | Resource ARN or instance ID | Database, schema, table, plus source IP and request ID |
The workflow layer has to carry one thing the infrastructure layer does not: context. Ticket ID, environment, approval chain, change reference. Strip that out and an auditor can see an action happened but has no way to tell whether it was supposed to.
Audit Logging by Compliance Framework
Every framework wants both layers. What changes is where the weight falls.
- SOC 2: Trust Services Criteria CC6.1, CC6.3, and CC7.2 want evidence of administrator activity across both layers. See What SOC 2 Taught Us About Database Audit Logs for what a real audit actually looks like.
- HIPAA: § 164.312(b) requires audit controls over systems holding ePHI. SELECT visibility on PHI tables is the workflow-layer piece that tends to be missing. See also HIPAA data security and retention requirements.
- PCI DSS: Requirement 10 mandates audit trails for all access to cardholder data, with one year of retention and three months kept online. The workflow layer carries most of that burden.
- ISO 27001: Annex A 8.15 requires logging of activities, exceptions, and security events. The scope lines up closely with SOC 2.
- GDPR: Article 30 records-of-processing duties kick in whenever personal data is read, exported, or modified. SELECT and export auditing both live in the workflow layer.
Audit Logging by Database Engine
The infrastructure layer is uniform, since the cloud provider handles it. The workflow layer is where the engines diverge.
- PostgreSQL: Native logging, triggers, logical replication,
pgaudit, and a workflow tool on top. Full walkthrough in the Postgres Audit Logging Guide. - MySQL: General log, audit plugins (Percona Audit, MariaDB
server_audit, MySQL Enterprise Audit), and binlog-based CDC. Picking the plugin is most of the configuration work. - SQL Server: SQL Server Audit at server and database scope. The specifications are granular; the headache is parsing
.sqlauditfiles throughfn_get_audit_file()and getting them into a SIEM. - Oracle: Unified Auditing (12c+) consolidates records into
UNIFIED_AUDIT_TRAIL. The most granular of the four, though the AUDSYS tablespace needs active management or it will surprise you. - Cloud-managed databases: RDS, Cloud SQL, and Azure Database wrap engine-native auditing into their own formats. How faithfully the SQL text and event coverage survive that wrapping varies by provider.
How Bytebase Covers the Workflow Layer
Bytebase sits in front of the database. Any SQL routed through it, whether from the SQL Editor, change workflows, or data exports, is logged before it reaches the engine, with the user's SSO identity, the full SQL text, the target database, the timestamp, and the execution result. Schema changes carry their approval chain along with them. The one thing it does not see is a direct connection that bypasses Bytebase entirely.
For the full record format, the export paths, and how it pairs with engine-native auditing, see How Bytebase Handles Audit Logging.
Common Mistakes
| Mistake | What goes wrong | Fix |
|---|---|---|
| Treating provider logs as the full audit trail | Workflow-layer actions invisible; SOC 2 and HIPAA findings | Add workflow-layer auditing |
| Verbose engine-native logging without filtering | Storage costs spike; signal drowns in noise | Start with DDL, DML, and failed logins; add SELECT only for sensitive tables |
| Shared database accounts | Workflow logs say app_user, not the human | Map every SQL action to SSO identity |
| Skipping SELECT auditing | Cannot prove who read sensitive data | Audit SELECT on PII, financial, and credential tables |
| SQL captured without context | Auditor sees the action but not the justification | Attach ticket ID, approver, environment, and change reference to every record |
| Storing logs on the database host | A DROP DATABASE or breach wipes the trail | Ship to SIEM, S3, or centralized logging |
| No retention policy | Logs fill the disk or rotate before audit | Set retention by framework — SOC 2: 90–365 days, PCI DSS: one year, HIPAA: six years |
| Logs sit in raw files, never reach a SIEM | No alerting, no correlation; evidence gathered manually under audit pressure | Stream audit data to Datadog, Splunk, CloudWatch, or Grafana |
FAQ
Which compliance frameworks require database audit logging?
SOC 2, ISO 27001, HIPAA, PCI DSS, and GDPR all require an audit trail. Each leans on different fields: PCI DSS spells out retention, HIPAA cares about PHI access, SOC 2 cares about administrator activity. See SOC 2 data security requirements and HIPAA data security and retention requirements for the specifics.
Do I still need engine-native auditing if I use Bytebase?
Bytebase covers the workflow layer for SQL that goes through it. If you also have direct connections that bypass it, things like emergency SSH access, application service accounts, or ad-hoc tools, keep engine-native auditing on for that path. Many teams run Bytebase as the primary trail and keep engine-native logs as a backstop.
How does Bytebase handle database audit logging?
Bytebase logs every SQL statement, schema change, approval, and export routed through the platform, tied to the real user's SSO identity. The full record format and export paths are covered in How Bytebase Handles Audit Logging.