Skip to content

Data residency & subprocessors

Venturi uses a dedicated, single-tenant data plane and a separate control plane. The data plane runs either in your cloud account (self-hosted) or in a Venturi-operated, single-tenant environment pinned to your contracted residency lane (SaaS). This page describes the boundary, region pinning, provider connectors, and subprocessors for both modes.

Where your data lives

Your data stays in the contracted tenant boundary

In self-hosted mode, per-tenant data stays in your cloud account. In SaaS mode, it stays in the dedicated Venturi-operated tenant environment and residency lane named during onboarding. Neither mode pools operational data with another tenant. See Deployment modes.

The customer-side onboarding modules target AWS, Azure, and Google Cloud. Your security team reviews the infrastructure-as-code modules before deployment. See the onboarding guides for each cloud.

Control-plane and aggregation residency

The Venturi control plane runs region-pinned. EU-origin data, including opt-in anonymized telemetry, is processed in-region or under GDPR Chapter V safeguards (Standard Contractual Clauses), never silently routed cross-region. Venturi’s residency stance is single region plus SCCs.

Cross-tenant aggregation residency

The cross-tenant Aggregation environment is a separate, Venturi-managed VPC that no tenant data plane can read, and it is region-pinned as part of the customer-onboarding baseline.

  • De-identification before egress. All tenant-identifying attributes are anonymized before any data leaves the dedicated tenant data plane; the training pipeline reads only from the aggregation environment, never from tenant data planes.
  • Per-jurisdiction residency filtering. EU tenants do not contribute to non-EU aggregations, and vice versa.
  • Consent-gated. Aggregation is off by default and requires explicit, scoped, revocable permission.

See Tenant isolation for the full aggregation model.

Region-aware processing

At onboarding, residency is set by the contracted residency lane: the region is pinned at deployment, and residency routing fails closed, so an export, aggregation, or support grant that would cross the lane is refused and audited. The canonical event schema carries a region field, and the deployment carries a data-center-region configuration, which drive region-aware processing and the per-jurisdiction filters. A discrete customer-facing residency control (inference_geo) is on the post-onboarding roadmap; it is not part of the onboarding baseline. See Compliance.

Provider connectors

Venturi enriches attribution from provider-account reporting where you supply the credentials. Every connector only reads. Match the credential to the exact provider product and data source. Use native read-only permissions wherever available; a credential’s name or prefix does not establish its permissions. Venturi restricts provider requests to an allowlist of documented read endpoints, independently of the credential’s wider capabilities.

Connector Read-only enforcement Notes
GitHub / Okta / cloud billing Read-only scopes or roles Read-only org/team/billing metadata polling.
Anthropic admin-key usage/cost The connector sends only GET requests to documented read endpoints Requires an Anthropic Admin API key, which only an organization member with the admin role can create; workspace API keys do not work. Covers Claude API usage in your Anthropic organization; the Usage and Cost API is not available to individual accounts or to Claude Platform on AWS organizations. Claude usage through Amazon Bedrock is billed by AWS and reaches Venturi through the AWS connector.
OpenAI API Platform reporting / audit logs A dedicated organization Admin API key with only the required read permissions, plus the connector’s read-endpoint allowlist An organization owner creates the key and selects permissions for the integration: grant Usage: Read for usage and cost reporting, and for audit logs set Audit Logs Scope to Read and enable audit logging before collecting it. Usage and cost reporting do not require audit logging. API Platform keys and ChatGPT workspace Admin keys are separate credentials for separate products. See OpenAI’s Admin and Audit Logs API.
Workspace opt-in router n/a Default state: nothing is ingested until an organization owner explicitly opts a workspace in.

Your provider credential stays in tenant-controlled storage

Provider credentials are stored per-tenant, KMS-encrypted, inside your trust boundary; the Venturi control plane never observes one in plaintext. The connector presents the credential over TLS only to the selected provider’s approved authentication and read endpoints. Create a dedicated credential with the narrowest permissions for the selected reporting surface. Anthropic Admin API keys can authorize organization-management operations as well as reporting; do not infer read-only capability from the sk-ant-admin prefix. OpenAI organization Admin keys support permission selection, including Usage: Read for usage and cost reporting and Read for audit logs. Venturi sends only GET requests to the allowlisted reporting and inventory endpoints. Cloud IAM write-denies protect cloud-authorized operations; they do not restrict a bearer key presented directly to an external provider. Verify the exact provider policy and connector egress boundary separately. Do not test an administrative write against production data. See Technical diligence. Nothing is ingested until you explicitly opt a workspace in, and the provider’s own permissions still govern visibility.

Subprocessors

Because each data plane is single-tenant and the control plane carries no raw tenant data, Venturi’s subprocessor surface is intentionally minimal. This page names the subprocessor categories; it does not publish the vendor list.

Subprocessor category Role
Data-plane cloud provider In self-hosted mode, your provider under your agreement. In SaaS mode, the provider and region named in your tenant’s subprocessor list.
Control-plane hosting Hosts the signed pricing-catalog sync, the software-release check, and (opt-in) anonymized telemetry.
Support tooling Handles the support cases you open with Venturi.
Research and training tooling Used only for the consent-gated Aggregation VPC, for customers who opt in to de-identified aggregation.

Where to get the subprocessor list

The tenant-applicable subprocessor list is dated and versioned. It names each applicable vendor, purpose, data categories, processing region, and transfer safeguard, and it covers the control plane and the tenant data plane. You receive it in two places, because the exact list depends on deployment mode, region, and enabled connectors:

  • In-product: the tenant Trust Center (Security & Compliance / Compliance / Trust Center, under Data processing, then Subprocessors) shows the current list and every earlier version with its effective date. Tenant Admins and security reviewers can retrieve it; see Complete the trust-center review.
  • Onboarding diligence pack: the list current at onboarding, alongside the Data Processing Agreement (DPA). See the onboarding diligence pack.

Each proposed addition or replacement is risk-assessed before data flows. Subscribed customer security contacts receive the Article 28(2) change notice in advance, with the objection window defined in the DPA, and the Trust Center shows the new list version with its effective date. The tenant list is the authority for actual vendors and regions.

Give feedback on this page

Sign in to send feedback. Opens in a new tab.

Copy page details 
Docs feedback: Data residency & subprocessors
Page: https://docs.venturi.systems/security/residency-and-subprocessors/