How to Pass a SOC 2 Review With a Self-Hosted Voice Agent

A self-hosted voice agent passes a SOC 2 review like any in-house application. It sits inside your system boundary, so your own access, change, monitoring and vendor controls cover it, and there is no platform vendor report to collect. Show where call data lives, who can open it, how agent changes are tracked and what still leaves.

Key Takeaways

• A self-hosted voice agent sits inside your SOC 2 scope, under your own controls.
• No Dograh report exists for your install, because Dograh does not operate it.
• Hosted models and the carrier go through vendor review, and telemetry gets switched off.

This post is part of our guide to compliant AI voice agents. The guide's section "Security reviews: SOC 2 scope and audit evidence" puts the scope point in one line: "Self-hosted, the voice agent is software inside your own system boundary." Here are the controls that line puts on you, and the evidence an auditor asks for, in Dograh, an open-source, self-hostable voice agent platform.

What a SOC 2 report covers, and whose it is

A SOC 2 report is about a service organization, the company that runs a system for its customers. The AICPA describes SOC as "a suite of service offerings CPAs may provide in connection with system-level controls of a service organization or entity-level controls of other organizations." Its SOC 2 guide is titled "Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy."

With a hosted voice vendor, the vendor is the service organization. You collect its report, then read which subservice organizations it carves out, such as the carrier and the speech and language model providers. The auditor did not test those, so you collect their reports too.

Self-hosted, the voice agent is an application you run. Dograh supplies the software and does not operate your install, so there is no Dograh SOC 2 report to request. Your own SOC 2 scope takes the agent in, and your controls have to cover it like any other system that holds personal data. Self-hosting moves that work onto your team.

IBM's 2026 Cost of a Data Breach study, based on breaches at 602 organizations, put the global average cost of a breach at $4.99 million. A voice agent holds recordings and transcripts of every call, so it belongs on the same list as your CRM.

Where call data lives in a self-hosted install

An auditor's first question is where the data sits, and a self-hosted install keeps it all in storage you control. Installed with Docker Compose, Dograh keeps call records in PostgreSQL, with links to each call's recording and transcript, its logs and the fields the agent extracted. The recordings and transcripts go to the bundled MinIO object storage by default, or to your own S3-compatible bucket with ENABLE_AWS_S3=true.

The bundled MinIO starts with the default credentials minioadmin unless you set MINIO_ROOT_USER and MINIO_ROOT_PASSWORD, so set both before the first real call. Recording upload is on by default and can be switched off only for the whole server, with ENABLE_CALL_RECORDING_UPLOAD=false. Transcripts are still saved. There is no retention setting and nothing is deleted automatically, so your retention policy and deletion process are the control the auditor tests.

The live audio is a separate question. Dograh is the orchestration layer: it runs the call flow, tools and telephony, and the speech and language models are a separate layer you choose. The call audio stays in-house only when the speech and language models run on your own servers too. Dograh starts every account on its own managed models. To keep call audio away from Dograh, open Models, switch the Organization default to BYOK with your own speech and language providers (or local models), and check that no agent has its own model override. Our data residency checklist for voice AI lists every other place call data can go.

Open Source Alternative to Vapi / Retell

Self-hosted voice agent platform — no per-minute fees

dograh-hq/dograh

Star on GitHub

Access control: close the open defaults

A fresh install is set up for a quick start, so a few defaults need closing before an auditor looks. Signup is open by default. After you create the first account, set ENABLE_SIGNUP=false in .env and re-run ./start_docker.sh, because a plain docker compose restart does not apply .env changes.

Sign-in uses the built-in local provider, email and password with a signed token, unless you switch on Stack Auth for social logins. Audit logs are listed on Dograh's Enterprise plan, and SSO and SAML sit on the same plan. On a self-hosted install, your own infrastructure's access logs show who reached the servers and the database, or opened a stored recording.

The quickstart also opens a public trycloudflare.com tunnel to the API, so you can test calls from anywhere. A production install uses your own domain and ingress instead. The rest is your usual access review, which covers who holds server and database access and how quickly leavers lose it. The first-hour checklist in our open-source alternative to Vapi post covers the same defaults from the setup side.

Change management: agent versions an auditor can see

Change management asks whether you can show what changed and when, and Dograh keeps the records for that. Each agent's definition is versioned as draft, published or archived, with a version number and a published date. Edits sit in a draft until someone publishes them.

Each call record also stores the agent version it ran and a snapshot of its model settings. So when an auditor picks a call from three months ago, you can show the exact prompt and models that handled it, even if the agent has changed since. Our post on building an auditable voice AI stack shows how these records answer a reviewer's questions one by one.

The platform itself changes only when you pull new images, so upgrades go through your own change process. Dograh's code is open under the BSD-2-Clause licence, so your reviewers can read every line of a release before it handles a call.

Monitoring and vendor management

Monitoring covers both the calls and the system. A QA node scores each step of a call with its own tags, a 1-10 score, sentiment and a summary, and its Sample Rate picks a random share of live calls to review.

If you turn on tracing, each call's trace goes to the Langfuse project you configure, so host Langfuse yourself or leave tracing off. Server and container logs go to your own log stack and alerting, like any other application.

Vendor management covers what still leaves your boundary. Telemetry is on by default in the Docker setup. Set ENABLE_TELEMETRY=false, and remove POSTHOG_API_KEY from the api service in docker-compose.yaml (or set it to an empty value). Then list the rest: hosted model providers, the phone carrier and every endpoint an HTTP API tool or webhook sends data to.

Because you self-host Dograh inside your existing compliance perimeter, you don't need a separate vendor review for Dograh. The speech and language model providers you choose may still need their own review, unless those models run on your servers too. How this shortens a buying process is in why procurement stalls on closed voice vendors.

Dograh Cloud handles the security work for you. Self-hosted Dograh has no per-minute platform fee (servers, model keys and phone minutes still cost); Dograh Cloud has a 1¢-a-minute platform fee. Confirm your scope and control mapping with your SOC 2 auditor before the observation period starts.