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 enable it. Many still fail audits on it.
The gap is structural. Database audit logging is two systems, not one. 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 ship the first. The second is yours to build.
The Two Layers
Infrastructure layer
The infrastructure layer audits actions on the database instance:
- 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 this by default. AWS RDS routes events to CloudTrail. Google Cloud SQL writes to Cloud Audit Logs. Azure Database emits to Azure Monitor. Self-hosted instances get equivalent coverage from infrastructure-as-code tooling, container audit logs, and OS-level access logs.
Records are well-formatted, centrally retained, and tied to a cloud principal. This layer is mostly a solved problem.
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, with what justification
- Exports — who pulled which data, where it went
- Permission changes — roles and privileges granted to users
Each engine ships its own auditing: PostgreSQL pgaudit, MySQL audit plugins, SQL Server Audit, Oracle Unified Auditing. All four leave three structural gaps that no amount of configuration closes:
- Identity is the database user, not the human. Most applications and ops scripts connect as
app_useroradmin. The audit log records the role, not the person. - Context is missing. The log records the SQL but not the ticket, approver, or environment. Compliance asks for the why.
- Coverage is fragmented. Each engine logs differently. A multi-engine fleet produces multi-format trails that no SIEM unifies cleanly.
The workflow layer is where most audit findings live.
Why the Split Matters
Auditors don't ask "is logging enabled." They ask for evidence of a specific privileged action: an admin promoting a user, a developer changing a schema, an analyst pulling a customer record. That evidence is almost always a workflow-layer event.
A team can have complete CloudTrail coverage and still fail SOC 2 because they cannot produce a clean record of who ran the SQL that changed the production schema last Tuesday. We wrote up that experience in What SOC 2 Taught Us About Database Audit Logs.
The split also clarifies ownership. The platform team owns the infrastructure layer. Data and application teams own the workflow layer. Bundling them muddies accountability.
What Each Layer Should Capture
Both layers must answer the same four questions: who, what, when, where. The fields differ.
| 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 must also carry context — ticket ID, environment, approval chain, change reference. Without context, an auditor sees an action but not its justification.
Audit Logging by Compliance Framework
Every framework demands both layers. The emphasis shifts.
- SOC 2 — Trust Services Criteria CC6.1, CC6.3, CC7.2 require evidence of administrator activity across both layers. See What SOC 2 Taught Us About Database Audit Logs for what a real audit looks like.
- HIPAA — § 164.312(b) requires audit controls over systems containing ePHI. SELECT visibility on PHI tables is the workflow-layer pivot. 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 online. The workflow layer carries the burden.
- ISO 27001 — Annex A 8.15 requires logging of activities, exceptions, and security events. Scope aligns closely with SOC 2.
- GDPR — Article 30 records-of-processing duties apply whenever personal data is read, exported, or modified. SELECT and export auditing live in the workflow layer.
Audit Logging by Database Engine
The infrastructure layer is uniform: the cloud provider handles it. The workflow layer differs sharply per engine.
- PostgreSQL — Native logging, triggers, logical replication,
pgaudit, and a workflow tool. Full walkthrough in the Postgres Audit Logging Guide. - MySQL — General log, audit plugins (Percona Audit, MariaDB
server_audit, MySQL Enterprise Audit), binlog-based CDC. Plugin selection drives most of the configuration burden. - SQL Server — SQL Server Audit at server and database scope. Audit specifications are granular; the operational difficulty is parsing
.sqlauditfiles viafn_get_audit_file()and shipping to a SIEM. - Oracle — Unified Auditing (12c+) consolidates records into
UNIFIED_AUDIT_TRAIL. The most granular engine; the AUDSYS tablespace needs active management. - Cloud-managed databases — RDS, Cloud SQL, and Azure Database wrap engine-native auditing into provider formats. SQL-text fidelity and event coverage vary by provider.
How Bytebase Covers the Workflow Layer
Bytebase sits in front of the database. SQL routed through Bytebase — SQL Editor, change workflows, data exports — is logged before it reaches the engine, with the user's SSO identity, full SQL text, target database, timestamp, and execution result. Schema changes carry the approval chain. Direct database connections that bypass Bytebase are not captured.
For the full record format, 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 emphasizes different fields: PCI DSS specifies retention, HIPAA emphasizes PHI access, SOC 2 emphasizes administrator activity. See SOC 2 data security requirements and HIPAA data security and retention requirements for specifics.
Do I still need engine-native auditing if I use Bytebase?
Bytebase covers the workflow layer for SQL routed through it. If you also have direct database connections that bypass Bytebase — emergency SSH access, application service accounts, ad-hoc tools — keep engine-native auditing on for that path. Many teams run Bytebase as the primary trail and 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. Full record format and export paths are covered in How Bytebase Handles Audit Logging.