QueryProxy

SOC 2 and database access controls

A SOC 2 report is an auditor’s opinion on whether your controls met the criteria you chose to be assessed against. No tool produces that opinion. A tool can produce evidence: records showing that a control did what your policy says it does. QueryProxy helps with evidence for one narrow area, who reaches your production databases and what they do there.

This page is not legal or audit advice. Your auditor decides which criteria apply to you and what counts as sufficient.

Which SOC 2 criteria does database access touch?

SOC 2 reports use the AICPA Trust Services Criteria. Their 2017 edition, with revised points of focus issued in 2022, is the current published version (checked on 2026-10-13). Security is the common category, and its logical access criteria are numbered CC6. The ones relevant here:

  • CC6.1 covers logical access security: restricting access to systems and information.
  • CC6.2 covers registering and authorizing users, and removing access when it is no longer authorized.
  • CC6.3 covers access based on roles, least privilege and segregation of duties.
  • CC7.2 covers monitoring system components for anomalies and security events.

The criteria text is the authority here, not this summary. Read it in the AICPA’s Trust Services Criteria publication (the download needs a free account), and ask your auditor which points of focus they test.

What evidence can QueryProxy produce?

QueryProxy helps with evidence for these controls. It does not satisfy a criterion by itself.

Control area What QueryProxy produces What it does not cover
Restricting access to databases (CC6.1) Developers never hold the production credential; it sits encrypted (AES-256) in QueryProxy (approval workflow reference). A developer reaches only the connections a DBA granted. TOTP two-factor authentication can be required for administrators, DBAs or all users (configuration). Network controls, database-side grants and the security of the host running QueryProxy.
Granting and removing access (CC6.2) Grants and logins are written to the audit log. Onboarding and offboarding, identity verification and periodic access reviews. QueryProxy does not run them.
Roles and segregation of duties (CC6.3) Four roles (Admin, DBA, Developer, Auditor). A DBA cannot approve their own request. An administrator’s override of that rule is flagged in the audit log. The Auditor role reads the trail without seeing result rows. Deciding who should hold which role, and checking that the assignments are still right.
Monitoring activity (CC7.2) Every step writes an audit entry: submission, decision with channel, execution start and finish with duration and affected rows, result downloads, logins, grants and configuration changes. The audit log can be exported as CSV. Alerting, anomaly detection and incident response. The audit log is a record, not a monitor.

The approval step produces the artifact many auditors ask for: a request, its exact SQL, a named approver who is not the requester, and the outcome. The approval workflow page explains how a request travels; the workflow reference lists the roles and the audit entries. Masking of stored results is covered in the masking reference. For what a trail should record, see the audit trail post; for decisions taken in chat, see approving SQL queries in Slack and Teams.

What stays with your organization?

QueryProxy does not write your policies or run your controls. Still yours:

  • The access control policy and the decision about who becomes a DBA or Auditor.
  • User registration and removal. Remove a leaver from QueryProxy and from your identity provider; the audit log will show what they did, not that you removed them in time.
  • Periodic access reviews, and keeping their records.
  • Retention of the audit log and of result files. The documentation names no retention period for the audit log, and result files follow a period you configure. Pick the periods your audit needs.
  • Protecting the host, the reverse proxy and the application’s own database. Behind a reverse proxy, list it in TRUSTED_PROXIES or the audit log records the proxy’s address instead of the user’s.
  • Everything outside database access: change management, vendor management, availability and the other trust service categories.

What are the limits?

  • The audit log covers requests made through QueryProxy. A person who reaches the database by another route leaves no entry in it.
  • “Cannot be edited” describes the application. It is not a guarantee against someone with direct access to the database that stores the log.
  • Masking is rule-based and applied while results are written. It reduces what is stored, and it only masks what your rules match. See dynamic data masking.
  • A SOC 2 report covers your organization’s controls over a period. Using QueryProxy does not give you a report.

When do you not need this?

If you have no production database holding customer data, or one person is the only operator, there is nobody to approve and nothing for an auditor to sample in this area. If your auditor already accepts evidence from a bastion host or a database-native audit extension for these controls, QueryProxy may add little. The comparison with a bastion host shows what changes. The question QueryProxy answers is narrower: can you show who asked, who approved and what ran, for every production statement.

For the wider picture, read what database access control is. Teams that handle card data can read the PCI DSS page, and the ISO 27001 page maps the same evidence to Annex A.

Frequently asked

Does QueryProxy make us SOC 2 ready for database access?
No tool does that. An audit examines your controls over a period, and the auditor decides what is sufficient. QueryProxy helps by producing evidence for database access, such as approvals and an append-only audit trail, that you can show to your auditor.
Which SOC 2 criteria does QueryProxy touch?
Mainly the logical access criteria CC6.1, CC6.2 and CC6.3, and the monitoring of system activity under CC7.2. It records grants and approvals and keeps production credentials away from developers. Registration and removal of users, and the review of access, stay with your process.
What does an auditor see in QueryProxy?
The Auditor role has read-only access to the audit log, its CSV export, and each request's SQL, status, requester, reviewer and approval trace. It cannot view or download result rows, and it cannot see connections, approvals or masking settings.
Can the audit log be edited or deleted?
Not through the application. Audit rows are immutable at the model layer, which refuses updates and deletes. Someone with direct access to the underlying database is outside that guarantee, so protect that access as well.
How long is the audit log kept?
The documentation does not state a retention period for the audit log, so this page does not either. Result files are pruned after a configured retention period. Decide the retention your audit needs and verify how your installation behaves.

Arrow keys to move, Enter to open.