# Database Audit Logging: Two Layers, One Trail

> Database audit logging has two layers: infrastructure (provider-managed) and workflow (database activity). What each captures, and why compliance requires both.

Adela | 2026-05-05 | Source: https://www.bytebase.com/blog/database-audit-logging/

---

Database audit logging records who did what, when, and from where. [SOC 2](/blog/soc2-data-security-and-retention-requirements/), ISO 27001, [HIPAA](/blog/hipaa-data-security-and-retention-requirements/), PCI DSS, and [GDPR](/blog/database-compliance-for-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

```mermaid
flowchart TB
    Admin(["Cloud admin"]) --> InfraAction["Cloud API call"]
    User(["End user"]) --> WorkflowAction["SQL via workflow tool"]

    InfraAction --> InfraLog["Infrastructure layer<br/>provisioning · config<br/>backups · network<br/>―<br/>CloudTrail<br/>Cloud Audit Logs<br/>Azure Monitor"]
    WorkflowAction --> WorkflowLog["Workflow layer<br/>schema · queries<br/>approvals · exports<br/>―<br/>Bytebase<br/>pgaudit · MySQL audit plugin<br/>SQL Server Audit · Oracle UA"]

    InfraLog --> Evidence["Compliance evidence<br/>SOC 2 · HIPAA · PCI DSS<br/>ISO 27001 · GDPR"]
    WorkflowLog --> Evidence

    style InfraLog fill:#fef3c7,stroke:#b45309
    style WorkflowLog fill:#e0f2fe,stroke:#0369a1
    style Evidence fill:#dcfce7,stroke:#15803d
```

### 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:

1. **Identity is the database user, not the human.** Most applications and ops scripts connect as `app_user` or `admin`. The audit log records the role, not the person.
2. **Context is missing.** The log records the SQL but not the ticket, approver, or environment. Compliance asks for the why.
3. **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](/blog/soc2-audit-logging/).

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](/blog/soc2-audit-logging/) 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](/blog/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](/blog/postgres-audit-logging/).
- **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 `.sqlaudit` files via `fn_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](/blog/bytebase-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](/blog/soc2-data-security-and-retention-requirements/) and [HIPAA data security and retention requirements](/blog/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](/blog/bytebase-audit-logging/).