What evidence do you need to satisfy a soc 2 auditor when a service account runs queries against BigQuery?
Most teams grant a service account a static key, embed that key in CI pipelines, and let the job connect directly to the data warehouse. The key never changes, the job runs with full privileges, and the audit logs live only in BigQuery’s own activity stream. If a breach occurs, you can see that a query ran, but you cannot prove which pipeline triggered it, whether a human approved the request, or if sensitive columns were exposed.
This reality meets the basic requirement that an identity exists, but it leaves three critical gaps. The request still travels straight to BigQuery, bypassing any central control point. No real‑time approval step exists, so a rogue job can launch destructive commands. No masking occurs, so sensitive fields are returned in clear text. And because the connection is not mediated, you cannot capture a complete, immutable record of the session for later review.
Why soc 2 evidence matters for machine identities
SOC 2 expects organizations to demonstrate that access to critical systems is both authorized and auditable. For non‑human identities, the auditor looks for artifacts that answer:
- Who initiated the request?
- When did the request occur?
- What data was accessed and what was returned?
- Was any privileged operation approved by a human?
- Were sensitive fields protected from exposure?
Without a gateway in the data path, none of these questions can be answered with confidence. The raw BigQuery logs provide timestamps and the service account name, but they do not capture the exact SQL payload, the result set, or any approval workflow.
hoop.dev as the enforcement layer
hoop.dev solves the problem by becoming the only point where traffic to BigQuery is allowed to pass. It sits between the service account and the warehouse, inspects each wire‑protocol message, and applies policy before the query reaches the target.
When a request arrives, hoop.dev checks the identity against the groups defined in your identity provider. If the request matches a policy that requires human sign‑off, hoop.dev pauses the query and routes it to an approver. Once approved, the gateway forwards the query to BigQuery using a credential that only the gateway knows.
During execution, hoop.dev records the full session: the exact SQL statement, the parameters, and the response rows. It can mask columns that are marked as sensitive, ensuring that downstream logs never contain raw credit‑card numbers or personal identifiers. After the session ends, hoop.dev stores a log entry that includes the requestor, the approver (if any), the timestamp, and the masked result set.
Artifacts that satisfy a soc 2 audit
Because hoop.dev owns the data path, it can generate the following evidence automatically:
- Session logs – a chronological record of every query, including the full request payload and the masked response.
- Approval records – a signed audit trail showing which human approved privileged operations, with timestamps.
- Identity bindings – a mapping of service‑account tokens to the logical identity that initiated the request.
- Masking reports – a summary of which fields were redacted in each session, proving that sensitive data never left the gateway in clear text. Examples of fields that might be masked include ssn and credit_card.
- Access control snapshots – the policy version that was in effect at the time of each request, demonstrating that the system enforces least‑privilege rules.
These artifacts map directly to the common criteria in SOC 2’s Trust Services Criteria for security, availability, and confidentiality. An auditor can trace a single data breach back to a specific session, see who approved it, and verify that the data was masked according to policy.
High‑level deployment steps
To start generating these artifacts, follow the hoop.dev getting started guide. The process involves:
- Deploying the gateway in the same network segment as your BigQuery service.
- Configuring OIDC authentication so that service accounts receive tokens that hoop.dev can verify.
- Registering BigQuery as a connection, letting the gateway hold the service‑account key.
- Defining policies that require approval for write‑heavy queries and that mask columns such as ssn or credit_card.
- Enabling session recording and audit log export to your SIEM or log archive.
The hoop.dev learning hub contains deeper explanations of policy syntax, masking rules, and how to integrate the audit stream with existing compliance tooling.
FAQ
How does hoop.dev prevent a service account from bypassing the gateway?
Because the credential to reach BigQuery lives only inside the gateway, the service account never possesses a direct secret. Network policies can be set to allow traffic to BigQuery only from the gateway’s IP, ensuring that all queries must flow through hoop.dev.
Can I retroactively generate soc 2 evidence for queries that ran before hoop.dev was deployed?
No. The enforcement outcomes, session logs, masking reports, and approval records, are created only when the gateway is in the data path. Historical queries that bypassed the gateway cannot be reconstructed with the same level of detail.
Explore the hoop.dev source on GitHub
