Without verifiable evidence, a SOC 2 audit becomes a guessing game that can cost your organization trust and contracts.
SOC 2 defines five trust service criteria: security, availability, processing integrity, confidentiality, and privacy. Auditors expect concrete proof that each criterion is enforced whenever a user, service account, or automated process touches a system. In practice, many teams rely on ad‑hoc spreadsheets, manual ticketing, or static credential sharing. Those approaches leave gaps: timestamps can be altered, logs may be incomplete, and the very act of granting a secret to a user defeats the purpose of a confidentiality control.
Why soc 2 evidence must be automated
Automation is not a luxury; it is a requirement for a defensible audit trail. SOC 2 auditors look for:
- Who accessed a resource, when, and from which identity.
- What commands or queries were executed, especially those that modify data or configuration.
- Any inline data transformations that protect personally identifiable information.
- Human approvals for high‑risk operations before they reach the target system.
When the evidence is generated at the point of entry, the organization can prove that no privileged information ever reaches an untrusted client. The audit trail also remains tamper‑evident and retained for the period defined by the audit schedule. If you remove the gateway, you lose all of the evidence, and the SOC 2 report may be qualified.
Typical gaps in self‑reflection processes
Many engineering groups perform a "self‑reflection" after an incident: they pull logs from a database, ask a few engineers what happened, and write a post‑mortem. While useful for learning, that retrospective does not satisfy SOC 2 because the evidence was not captured in real time. Common gaps include:
- Static SSH keys or shared service‑account passwords that bypass any approval workflow.
- Direct database connections that bypass a logging layer, leaving query‑level detail invisible to auditors.
- Manual masking of sensitive fields in application code, which can be bypassed or forgotten.
- Audit logs stored on the same host as the workload, making them vulnerable to the same compromise.
These gaps prevent the organization from demonstrating continuous compliance; it can only claim compliance after the fact.
Architectural requirement for trustworthy evidence
To close the gap, the control surface must sit where the request actually traverses the network. The gateway must be able to:
- Authenticate the caller via OIDC or SAML and map group membership to policy.
- Enforce just‑in‑time (JIT) approvals before a privileged command reaches the target.
- Mask or redact sensitive response fields in real time.
- Record the full session, including command input and output, for replay.
- Store the audit records in a location that the requester cannot alter.
Only a data‑path component that sits between identity and infrastructure can guarantee that every interaction is observed and controlled.
Introducing hoop.dev as the data‑path solution
hoop.dev fulfills the architectural requirement by acting as an identity‑aware proxy for databases, Kubernetes clusters, SSH, RDP, and internal HTTP services. It intercepts traffic at Layer 7, applies policy, and forwards the request to the target. Because hoop.dev is the only point that sees the clear‑text command, it enforces the controls listed above.
Specifically, hoop.dev:
- records each session, preserving a replayable audit log;
- applies inline masking to protect confidential columns or fields;
- requires just‑in‑time approval for high‑risk queries before they are sent;
- blocks disallowed commands based on policy rules;
- stores audit evidence outside the target host, ensuring integrity.
hoop.dev generates these outcomes; the underlying identity provider or the target system does not. If you remove the gateway, you lose all of the evidence.
How hoop.dev generates evidence for soc 2
Auditors can verify the following artifacts directly from hoop.dev:
- Identity‑bound session logs: hoop.dev ties every connection to the OIDC token that initiated it, showing who did what and when.
- Command‑level audit trails: hoop.dev captures the exact statements sent to a database or the commands executed over SSH, satisfying the processing‑integrity criterion.
- Inline data masking records: When a response contains PII, hoop.dev masks the field and logs the masking action, providing proof of confidentiality controls.
- Just‑in‑time approval records: For operations flagged as high‑risk, hoop.dev stores the approval workflow with timestamps, reviewer identity, and decision, meeting the security and availability criteria.
- Immutable storage of logs: hoop.dev writes logs to a backend that the requester cannot reach, ensuring audit evidence cannot be tampered with.
Because hoop.dev enforces alone, the organization demonstrates that every privileged action was observed, approved, and recorded – exactly the evidence SOC 2 expects.
Getting started with hoop.dev
To begin generating SOC 2‑ready evidence, follow the getting started guide. The documentation walks you through deploying the gateway, configuring OIDC authentication, and registering a database or SSH target. For deeper insight into masking policies, approval workflows, and session replay, explore the feature documentation.
All of the code is open source. Explore the repository on GitHub to see how the proxy is built and to contribute enhancements.
FAQ
Do I need to replace my existing identity provider?
No. hoop.dev acts as a relying party, consuming tokens from your existing OIDC or SAML provider while adding a control layer on the data path.
Can hoop.dev be used with existing CI/CD pipelines?
Yes. Because the gateway presents the same wire‑protocol endpoints (PostgreSQL, SSH, etc.), pipelines can point to the proxy without code changes, gaining audit and masking automatically.
Retention should match the period defined in your SOC 2 audit scope, typically one to three years. hoop.dev stores logs in a backend you control, so you can set the appropriate lifecycle policy.
