What SOC 2 Taught Us About Database Audit Logs

Our auditor came back with a note on one of the controls — Administrator account use is logged for retrospective investigation if required. It maps to SOC 2 Trust Services Criteria CC6.1 (logical access), CC6.3 (access changes), and CC7.2 (system monitoring) — the "admin activity" slice of those controls.

The feedback was short:

Thank you for providing log and alert configurations. To complete testing, we need evidence that administrator activity is actually logged (not just that logging is enabled). Could you please provide a sample from GCP Audit Logs showing:

an admin/privileged user,
the action performed,
timestamp, and
affected resource.

Reading it, I realized something we had taken for granted. We had audit logging turned on everywhere. We could show every configuration page in GCP. What we did not have, immediately, was a clean sample of an admin doing an admin thing — captured, queryable, and attributable.

That one note reshaped how I think about audit logs. This post is what I wish I had read before our audit.

"Logging Enabled" Is Not "Audit Evidence"#

Most teams think about audit logs as a configuration problem. Turn on pgaudit. Enable the MySQL general log. Flip on GCP Cloud Audit Logs. Check the box in the SaaS admin panel.

That is the easy half.

The hard half is what the auditor actually asks: can you produce a concrete record, right now, of an administrator performing a privileged action, with user + action + timestamp + affected resource?

Auditors do not grade your configuration page. They grade the log sample you hand them. If your logging is enabled but the log itself is empty, malformed, or missing one of those four fields, the control is incomplete.

The gap almost always lives in one of three places:

Logging is enabled but the events aren't captured — the category of action the admin did isn't one the logger records.
The events are captured but the identity is wrong — a shared service account ran the action, so "who" is ambiguous.
The events are captured but the resource is implicit — the log says "policy updated" but not which policy.

This control is specifically about administrator activity, which is where these gaps are worst. Admin actions tend to be rare, privileged, and hit the layers of the system that product engineers instrument last.

What Auditors Mean by "Administrator Activity"#

In the context of a database access platform like Bytebase, an administrator is anyone who can change the rules by which other users operate. That covers more than you think:

Workspace administrators — provision instances, manage global settings
DBAs — configure environments, set up approval flows, manage masking policies
Project owners — grant database access, assign roles, approve changes in their project
SSO / identity administrators — change authentication configuration, rotate SSO providers
Anyone with a custom role that includes a privileged permission — the long tail

When the control says "administrator account use is logged," it means every one of those roles performing every privileged action needs a log entry with the four mandatory fields.

The auditor is not asking for a firehose of queries. They are asking for the specific slice of activity that changes the security posture of the system — grants, revokes, policy edits, identity changes, and the rare break-glass deployment.

Four Fields, Six Categories#

The auditor's checklist — user, action, timestamp, affected resource — is the minimum. To actually pass this control for a database access platform, every one of the following categories has to produce that same four-field record:

1. Authentication events#

Every login, every SSO handoff, every failed attempt, every session termination. A successful login from a new IP is an audit event. A failed 2FA challenge is an audit event. A session ending by timeout is an audit event — because "when did this admin's session end" is a question auditors will ask during an incident investigation.

2. Role and permission changes#

Grants and revokes at the workspace level, project level, and database level. The record must capture who was granted what permission on what resource by which admin, and when. "Alice granted Bob database prod-orders read access" is one line; the mistake is storing it as "Alice changed a setting."

3. Policy changes#

SQL review rules, approval flow definitions, masking rules, data classification settings, retention policies, allowlists. Every edit is an administrative action that changes what the rest of the platform will do. Each edit needs a before/after, or at minimum a pointer to the change record.

4. Access request decisions#

Who requested access, who granted or denied it, under what justification, with what expiration. This is the audit trail for Just-In-Time access — a pattern auditors increasingly expect, because standing access is a finding in its own right.

5. Data exposure events#

Query exports, masking exceptions (who unmasked what under what approval), sharing a query sheet with an external user. These are the "the data left the safe perimeter" events, and auditors trace them first during an incident response test.

6. Change execution#

Deploys, rollbacks, manual SQL execution in Admin Mode, bypasses of the normal approval flow. Every execution needs a line. Admin Mode in particular — the break-glass path — is where most teams fail, because the break-glass path is exactly when people skip the logging conversation.

Each of these six categories maps to a SOC 2 Trust Services Criterion. CC6.1 covers logical access, CC6.3 covers access changes, CC7.2 covers system monitoring. The "administrator activity" control sits inside your organization's implementation of those criteria and is specifically the "admin" slice.

Why Database-Native Logs Are Not Enough#

When we first looked at this control, the instinct was to point at database audit logs. Postgres has pgaudit. MySQL has the general log. SQL Server has audit specifications. Oracle has unified auditing.

They are all useful. None of them answer the control for a platform.

A database-native log captures the SQL that ran. It does not capture:

Who approved that SQL to run — the approver is outside the database layer
Under what policy the SQL was allowed — the SQL review rules that the statement passed through
Whether the person was accessing on behalf of themselves or via a granted role — the request chain
What access request led to this session — the Just-In-Time history
Why a masking exception was permitted — the approval behind an unmasked read

Database audit logs tell you what ran. Platform audit logs tell you who authorized it, under what policy, and whether that authorization is still valid. A SOC 2 auditor asking "show me a week of admin activity with user + action + timestamp + resource" needs the second one.

If your architecture is application → database, with nothing in between, the database log is most of what you have and you instrument around it. If there is a platform between users and the database — Bytebase, Okta Privileged Access, StrongDM, Teleport, a homegrown bastion — that platform needs its own audit log that is at least as rigorous as the database's.

What We Built in Response#

After the auditor's note, we did two things.

First, we audited our own audit log. We took the six categories above and walked through each one to see whether a query against the log could reproduce the user + action + timestamp + resource tuple for every event type. A handful of admin actions — mostly in SSO configuration and workspace-level settings — were captured but in an older, less structured format. We normalized them.

Second, we made the log easier to hand to an auditor. Bytebase's Audit Log now supports filtering by user, action type, resource, and time range in the GUI, and export to JSON or CSV for ingestion into a SIEM. When the next audit cycle comes around, the evidence is a filtered export, not a screenshot of a config page.

The concrete change was small. The mental model change was larger. "Logging enabled" is a system property. "Audit evidence" is an artifact — and you have to produce it on demand. The design decision that follows is: every admin-class action in the system must produce a log record by construction, not as a side effect.

That was our own compliance story — Bytebase as a company passing its own SOC 2 audit. But the same lesson applies to our customers. Bytebase sits between developers and databases — every schema change, data query, access grant, and policy edit flows through the platform. Bytebase's Audit Log gives teams the same four-field record (user + action + timestamp + resource) for every database operation, so when their auditor asks "who changed the production schema on March 14, and who approved it?" the answer is a filtered export, not a scramble through Slack and Jira.

If You're Evaluating a Database Access Platform#

If you are buying a database access platform and you care about SOC 2, ask the vendor:

Show me a sample audit log export. Not a config page. Not a screenshot. A real export with at least a week of activity.
Can I filter to just administrator activity? If the answer involves grep, the log is not structured enough for audit.
Does the log include: user identity, action name, timestamp, and affected resource — on every row? If any row is missing one of those, the log fails the control on that row.
How long is the retention, and is it tamper-evident? SOC 2 does not prescribe a specific retention period, but 12 months is a common baseline and some auditors want 7 years for specific control categories.
Can I export to a SIEM? If the platform log lives only in the vendor's UI, you cannot correlate it with the rest of your security telemetry, which auditors increasingly expect.
Are break-glass paths (Admin Mode, emergency access, bypass roles) logged with the same fidelity as normal paths? This is the most common gap.

The Checklist#

If you are going through SOC 2 right now, here is the short version of what the administrator activity control requires:

Every admin role in the system is enumerable (workspace, project, database, custom)
Every privileged action each of those roles can perform has a corresponding log entry type
Every log entry captures user, action, timestamp, affected resource — no exceptions
The log is queryable by user, by action, by resource, by time range
A week-long sample can be exported and handed to an auditor without post-processing
Break-glass paths are logged with the same four fields
Retention is at least 12 months and is tamper-evident
The log can be ingested into your SIEM

The difference between "we have logging" and "we can pass the audit" lives in whether you can put a check next to every line above, today, without scrambling.

FAQ#

Can I use GCP Audit Logs / AWS CloudTrail / Azure Monitor as my audit log?#

For infrastructure-level administrator activity, yes. Those cloud audit logs capture IAM changes, resource creation, console logins, etc. They do not capture application-level administrator activity — role grants inside your SaaS, SQL review policy edits, or access request approvals. For a database access platform, you need the platform's own audit log in addition to the cloud-native log.

Is database audit logging enough for SOC 2?#

It's necessary for database-layer activity but not sufficient. Database logs miss the platform-level context — approvals, access requests, policy changes, identity events — that SOC 2 controls on logical access and monitoring require. If your architecture has a platform layer between users and the database, the platform layer needs its own audit log.

How much retention do I need?#

SOC 2 doesn't mandate a specific retention period — auditors look at what your own policy states and whether you meet it. Twelve months is the common default; regulated industries often require longer (SOX, HIPAA, PCI DSS each have their own stricter requirements). Whatever you commit to in your policy, your log infrastructure must actually deliver.

What's "tamper-evident"?#

An audit log that can detect after-the-fact modification. Implementations range from append-only storage (immutable S3 buckets, WORM) to cryptographic chains (each log entry includes a hash of the previous). SOC 2 doesn't prescribe the mechanism; auditors want to see that deletion or modification would be detectable.

What about non-admin user activity?#

Separate controls. The administrator activity control is specifically about privileged accounts. General user activity (queries, data access) falls under other controls — CC6.1 (logical access) for authentication, CC6.7 (data transmission) for exfiltration paths, CC7.2 (monitoring) for anomaly detection. The principle is the same: log enablement is necessary but not sufficient; evidence is what passes audit.