# Database Access Control for SOC 2: CC6, CC7, and CC8 at the Database

> Map key SOC 2 criteria in CC6, CC7, and CC8 to example database access controls and audit evidence, including who can read production data.

Tianzhou | 2026-09-17 | Source: https://www.bytebase.com/blog/database-access-control-for-soc2/

---

SOC 2 does not hand you a control list. The [Trust Services Criteria](https://www.aicpa-cima.com/resources/download/2017-trust-services-criteria-with-revised-points-of-focus-2022) state outcomes, you write the controls, and the auditor evaluates their design and operation. In a Type II report, testing covers the examination period. For controls tested by sampling, the auditor needs a complete population of relevant events, such as access requests, production changes, or employee departures, from which to select samples.

For database access, three groups of criteria are especially relevant. CC6 covers logical and physical access, CC7 covers system operations, including monitoring and security events, and CC8 covers change management. A schema migration workflow addresses the change side. CC6 also raises questions about reads: who can query production data, who approved that, and what record is left.

## Where the criteria land

The table maps selected criteria to example controls for database access. The implementation and evidence depend on your system, risks, and documented controls; SOC 2 does not prescribe one access architecture.

| Criterion | What it says | Example database controls | Typical evidence |
| --- | --- | --- | --- |
| CC6.1 | Logical access security over protected information assets | Human database activity attributable to an individual; sensitive columns classified and restricted; no shared production credentials distributed to engineers | The list of users with production database access, with roles; the authentication configuration (SSO, MFA); a sample session traced to a person |
| CC6.2 | Register and authorize users before issuing credentials; remove credentials when access is no longer authorized | Database access issued from a request with an approver; access removed when the person leaves or changes teams | A sample of new-access tickets with approvals; the HR termination list matched against access removal dates |
| CC6.3 | Authorize, modify, and remove access based on role, with least privilege and segregation of duties | Grants to roles, scoped to the databases and tables the role needs; the person who writes a change does not approve it | The role-to-permission matrix; the periodic access review with sign-off; a sample of role changes with approvals |
| CC6.6 | Protect against threats from outside the system boundary | No database port open to the internet; engineers reach production through one controlled entry point, not from a laptop with a connection string | Network and firewall configuration; the list of paths that can reach the production database |
| CC6.7 | Restrict the transmission, movement, and removal of information | Limits on exporting query results; masked values for people who do not need the clear data; TLS on connections | The export policy and a sample of export approvals; the masking policy; the TLS configuration |
| CC7.2 | Monitor system components for anomalies | Query-level logging tied to the person, covering reads and failed access attempts, sent where someone reviews it | A log sample showing user, action, timestamp, and affected resource; alert rules and a sample alert |
| CC7.3 | Evaluate security events to decide whether they are incidents and take appropriate action | Assign an owner to triage database security events; record the classification, impact assessment, and action taken | An event ticket with the reviewer, decision, supporting log records, and any escalation or remediation |
| CC8.1 | Authorize, design, test, approve, and implement changes | Production schema migrations and administrative data changes go through a request, testing, review, approval, and recorded deployment, with a defined emergency procedure | The population of changes subject to the control for the period; a sample with ticket, test results, reviewer, approver, and deployment record; evidence that direct changes are blocked or detected |

The CC8.1 examples concern migrations and administrative changes; routine application transactions do not each need a separate change ticket. If your report includes the Confidentiality category, C1.1 (identify and protect confidential information) also draws on classification and masking work.

Evidence needs its own preparation: a configured control alone does not demonstrate that it operated throughout the examination period. Keep complete populations and the records that support testing.

## What the auditor actually tests

We went through this ourselves for our SOC 2 Type II report. Three lessons carry over to any database team.

1. Configuration alone does not prove the control operated.

   Our auditor's note on the administrator-activity control read: "we need evidence that administrator activity is actually logged (not just that logging is enabled)." They wanted a log sample with four fields: the privileged user, the action, the timestamp, the affected resource. A screenshot of the logging settings page did not close the control. The full account is in our [SOC 2 audit log post](/blog/soc2-audit-logging/).

1. Shared logins without individual attribution weaken access control and monitoring.

   Engine-native logs record the database user. When five engineers share `app_ro`, that record alone cannot identify the person. Individual database identities or an access layer that records the authenticated person can provide attribution. In either design, provisioning and revocation need controls supporting CC6.2.

1. Standing access adds work to the access review.

   CC6.3's points of focus include periodic review of access roles and rules. Define a review schedule and retain the decisions and evidence of any resulting revocations. If grants live in each engine's system catalog, the review may start with a script per engine and a spreadsheet to merge them. Temporary access can shorten the standing-access list, but the roles, approval rules, and temporary grants still need oversight.

## The read path is part of CC6

A change-management pipeline supports CC8.1 and the change-related permissions under CC6.3: who may deploy, who must approve. It does not by itself answer who can run `SELECT` against the customers table. Read access also calls for controls supporting CC6.1, CC6.2, CC6.3, CC6.7, and CC7.2. Four useful controls for the read path are:

1. No database passwords distributed to engineers. The database password lives in the access layer, and engineers sign in with SSO. This centralizes authentication, but SSO alone does not deactivate accounts. Connect offboarding through SCIM or another deprovisioning process, and verify that existing sessions, tokens, and alternate access paths stop working when access is revoked.
2. Just-in-time access in place of standing access. Production read access is requested with a reason, approved, and expires. Each request is a CC6.2 authorization record, and the set of requests is the population the auditor samples.
3. Approval scoped to the query for the sensitive cases. For a one-off production lookup, the approval covers one read-only statement, not a role. The approver sees exactly what will run.
4. Masking for everyone who does not need the clear value. Classify the sensitive columns once, then mask them for people querying without an exemption. This is least privilege at the column, and it supports CC6.7 because masked data is what leaves in an export.

## The database work

A practical implementation sequence:

1. Inventory which databases and columns hold customer data. CC6.1 applies to "protected information assets," and you define them.
2. Remove shared production logins for humans. Every session carries a name from SSO, with MFA.
3. Grant to roles, scoped by project and environment. Keep standing production roles to the few who need them daily.
4. Route everything else through request, approval, and expiry. Include exports.
5. Connect offboarding to account deactivation and access revocation, including existing sessions and alternate login paths. Define a revocation deadline appropriate to the risk and verify it is met. Auditors may match the HR departure list against removal records.
6. Send production changes through one reviewed path, and have a way to show that nothing went around it.
7. Define log coverage and retention for your risks and evidence needs. For human production queries, capture the four fields above, protect the logs from unauthorized changes, and retain the records needed to support testing across the examination period. Rehearse the request: pick a date and reconstruct one engineer's production activity.
8. Put the access review on the calendar and keep the sign-off.

## Where Bytebase fits

Bytebase covers the human-to-database path. Engineers sign in through [SSO](https://docs.bytebase.com/administration/sso/overview) and never receive the database credentials. Production access is a scoped role or a [just-in-time request](https://docs.bytebase.com/security/database-permission/just-in-time) that is approved and expires on its own. [Dynamic masking](https://docs.bytebase.com/security/data-masking/overview) hides sensitive columns in the SQL Editor, schema and data changes go through a reviewed [change workflow](https://docs.bytebase.com/change-database/change-workflow), and the [audit log](https://docs.bytebase.com/security/audit-log) records queries, exports, approvals, and permission changes under the person's name.

Where it stops: Bytebase governs what goes through it. The application's own connection, a DBA on the host, and a BI tool pointed at a replica are outside its view. Cover those paths with engine-native auditing for monitoring under CC7.2 and network controls for boundary protection under CC6.6.

For a first step, pull the list of humans who can access a production database today, directly or through an access layer, and check whether each person's access traces to an approval. That is a useful starting point for testing your controls under CC6.

## Related reading

- [SOC 2 Audit Log Requirements: Lessons From Our Own Audit](https://www.bytebase.com/blog/soc2-audit-logging/)
- [SOC 2 Data Security and Retention Requirements](https://www.bytebase.com/blog/soc2-data-security-and-retention-requirements/)
- [Database Access Control for PCI DSS: Requirements 7, 8, and 10 at the Database](https://www.bytebase.com/blog/database-access-control-for-pci-dss/)
- [Database Access Control for HIPAA: The Security Rule at the Database](https://www.bytebase.com/blog/database-access-control-for-hipaa/)
- [Just-in-Time Database Access](https://www.bytebase.com/blog/just-in-time-database-access/)