Control Mapping

Map the controls that govern a VeloDB Cloud BYOC deployment to SOC 2 criteria, so a security assessor can see which controls VeloDB owns and which the customer owns.

BYOC (Bring Your Own Cloud) deploys warehouse compute and customer warehouse storage in the customer's cloud account. That data-plane placement should not be read as a blanket statement that every related record remains in the customer VPC or selected region; control-plane metadata, operational telemetry, logs, support records, diagnostics, query-related records, access evidence, and other operational records are handled under the applicable DPA, Security Addendum, BYOC Addendum, logging and telemetry, retention, support, and subprocessor materials.

This page covers six control domains: access management, change management, incident response, logging and monitoring, infrastructure provisioning, and vendor management. For each control it states the responsible party, the SOC 2 Trust Services Criteria (TSC) it maps to, and a VeloDB control ID.

VeloDB Cloud holds a SOC 2 Type II report covering the control plane and warehouse service. To request the report and other audit artifacts, use the VeloDB Trust Center. For the full framework list, see Compliance and Trust.

How To Read This Mapping

The mapping uses three responsibility tiers, following the shared responsibility model and the BYOC Security boundary.

Tier	Owns in BYOC
Cloud provider	Physical data centers, hardware, and the hypervisor.
VeloDB Cloud	The warehouse software and its operation, the control plane, the orchestration agent, and the scoped cross-account role used to provision and run warehouse resources.
Customer (you)	The cloud account, the VPC, all provisioned resources, identity and key material, network exposure, and infrastructure-layer logging.

Each control carries a VeloDB control ID:

Prefix	Domain
VDB-AC	Access management
VDB-CM	Change management
VDB-IR	Incident response
VDB-LM	Logging and monitoring
VDB-IP	Infrastructure provisioning
VDB-VM	Vendor management

A complementary control (CUEC, a customer-owned control that VeloDB's design assumes is operating) appears in the right column of each table. If a complementary control does not operate, the paired VeloDB control may not meet its objective.

BYOC Operating Boundary

The boundary determines who can technically perform each control activity.

• VeloDB trust. The customer creates a cross-account IAM role that trusts the VeloDB account ID 757278738533 and requires the external ID from the VeloDB console. On Google Cloud and Azure, the equivalent is a customer-created service account or managed identity bound to a custom role. See BYOC on AWS, the GCP guide, and the Azure guide.
• Tag-scoped permissions. The deployment role can create, modify, and terminate compute, load balancing, and lifecycle resources. Mutating actions are conditioned on the resource-created-by: velodb tag. VeloDB cannot act on resources that do not carry that tag.
• Data credential. A separate instance-profile role grants the warehouse read and write access to the customer's object storage bucket, scoped to that bucket.
• Orchestration agent. A VeloDB Agent virtual machine runs inside the customer VPC. It and every VeloDB-created resource carry the tags listed in Cloud Resource Precautions.
• Private connectivity. Control-plane traffic uses PrivateLink (AWS), Private Service Connect (GCP), or Private Link (Azure), so warehouse traffic stays on the cloud-provider backbone.

The customer can revoke the cross-account role at any time.

Control Mapping By Domain

Each row lists the VeloDB control, its primary SOC 2 criteria, the VeloDB-owned activity, and the complementary control the customer must operate.

Access Management

Control ID	SOC 2 TSC	VeloDB-owned control	Customer complementary control (CUEC)
VDB-AC-01	CC6.1, CC6.3	Operates console and warehouse access on least-privilege roles. Reaches the data plane only through the scoped cross-account role and instance-profile role.	Create the cross-account role with the issued external ID, attach only the documented policy, and restrict who can edit that role.
VDB-AC-02	CC6.2, CC6.3	Manages registration, modification, and removal of VeloDB personnel access to the control plane and warehouse service.	Manage your own console users, database users, and roles, including timely removal. See Identity and Access.
VDB-AC-03	CC6.1	Conditions mutating cloud actions on the resource-created-by: velodb tag, so VeloDB cannot modify untagged resources.	Own the cloud account root and IAM boundary. Do not broaden the role policy beyond the documented scope.
VDB-AC-04	CC6.6, CC6.7	Offers private connectivity and IP allowlist controls for warehouse endpoints.	Configure network exposure, security groups, and allowlists. Decide whether endpoints are public. See Network Security.
VDB-AC-05	CC6.7	Encrypts data in transit using the cloud provider's hardware layer on private paths, plus protocol-level encryption where supported. See Encryption in Transit.	Choose connection protocols and private versus public paths. Own client-side TLS configuration.

Change Management

Control ID	SOC 2 TSC	VeloDB-owned control	Customer complementary control (CUEC)
VDB-CM-01	CC8.1	Develops, tests, reviews, and releases warehouse and control-plane changes through a secure development and release process. See Security Program.	Schedule and accept warehouse upgrades and configuration changes through the console at times that fit your change windows.
VDB-CM-02	CC8.1	Versions the BYOC provisioning templates and the cross-account policy, and shows the current policy in the creation wizard.	Review template and policy changes before applying them. Apply updates through the documented workflow, not by editing VeloDB-created resources.
VDB-CM-03	CC8.1	Requires no direct console changes to provisioned infrastructure during normal operation. Documents which resources must not be modified.	Do not modify or delete VeloDB-created IAM permissions, virtual machines, storage buckets, security groups, or private endpoints. Such changes can make the warehouse unrecoverable. See Cloud Resource Precautions.

Incident Response

Control ID	SOC 2 TSC	VeloDB-owned control	Customer complementary control (CUEC)
VDB-IR-01	CC7.3, CC7.4	Detects, triages, and responds to security and availability incidents affecting the VeloDB Cloud service and warehouse software.	Run your own incident-response process for your cloud account, including events visible only in your provider logs.
VDB-IR-02	CC7.4, CC7.5	Coordinates recovery of the warehouse service and notifies affected customers.	Designate contacts, monitor notifications, and perform account-side recovery actions that only the account owner can take.
VDB-IR-03	CC7.4	Acts on VeloDB-tagged resources through the cross-account role during an incident, within the documented scope.	Handle actions outside that scope, such as rotating customer-owned keys, adjusting account guardrails, or restoring resources you modified directly.

Logging And Monitoring

Control ID	SOC 2 TSC	VeloDB-owned control	Customer complementary control (CUEC)
VDB-LM-01	CC7.2, CC4.1	Records control-plane organization activity, including member, role, billing, and warehouse lifecycle actions, as Activity Logs.	Review organization activity logs and export the evidence your program requires. See Audit Logging.
VDB-LM-02	CC7.2	Records SQL and query activity in the __internal_schema.audit_log system table, queryable by SQL or in the console.	Set the audit retention window to match your compliance needs. Collect or forward the records you must keep.
VDB-LM-03	CC7.1, CC7.2	Monitors the health and operation of the warehouse service it runs.	Own infrastructure-layer logging. In BYOC, provider events come from your own logging service, such as AWS CloudTrail or Google Cloud Audit Logs. VeloDB does not own those logs.

Infrastructure Provisioning

Control ID	SOC 2 TSC	VeloDB-owned control	Customer complementary control (CUEC)
VDB-IP-01	CC6.1, CC8.1	Provisions warehouse compute, load balancing, storage lifecycle, and networking through versioned templates and the scoped role. Tags every created resource.	Prepare the VPC or VNet and subnets. Own account quotas and guardrails. Approve provisioning by creating the role and running the template.
VDB-IP-02	A1.1, A1.2	Configures warehouse storage on your object storage bucket, with bucket versioning recommended. Manages warehouse data protection at the service layer.	Own the durability posture of your account, including object storage configuration and any same-region backup you need for data protection.
VDB-IP-03	A1.2	Provisions BYOC warehouses single-AZ today; multi-AZ is in development.	Own high-availability and disaster-recovery topology. Multi-AZ provides high availability, same-region backup provides data protection, and cross-region export provides disaster recovery. See Reliability.
VDB-IP-04	CC6.1, CC8.1	At decommissioning, deletes the warehouse. Removing the last warehouse in the VPC also destroys the BYOC infrastructure.	VeloDB cannot delete your resources. Revoke the cross-account role and trust, remove private-connectivity resources, and delete storage, keys, and networking. See the Offboarding Guide.

Vendor Management

Control ID	SOC 2 TSC	VeloDB-owned control	Customer complementary control (CUEC)
VDB-VM-01	CC9.2	Maintains a vendor and subprocessor program and publishes the subprocessor list. In BYOC, the infrastructure runs in your own cloud account. See Subprocessors.	Assess VeloDB as your vendor. Maintain your own agreement with the cloud provider whose account hosts the deployment.
VDB-VM-02	CC9.2, CC2.3	Publishes certifications, audit reports, and trust materials, and supports due diligence through the Trust Center.	Perform periodic vendor reviews using the SOC 2 report, this control mapping, and other trust artifacts.

Customer Complementary Controls

VeloDB's controls assume the customer operates the following complementary controls. Each one is always required in a BYOC deployment.

• Create and protect the cross-account role, service account, or managed identity, scoped with the issued external ID and limited to the documented policy.
• Manage console users, database users, and roles, including timely removal of access.
• Own the cloud account boundary, and do not modify or delete VeloDB-created resources outside the documented workflows.
• Configure network exposure, security groups, allowlists, and private versus public connectivity.
• Own infrastructure-layer logging, and review provider audit logs.
• Set audit retention and collect the evidence your program requires.
• Own key material and the data-protection, high-availability, and disaster-recovery posture of the account.
• Run account-side offboarding to revoke access and delete resources after warehouse deletion.

BYOC Exclusions And Assumptions

The following items sit outside VeloDB's direct control in a BYOC deployment.

• Cloud account ownership. The customer owns the account, the root credentials, and all account-level guardrails. VeloDB acts only through the scoped, revocable role.
• Infrastructure-layer logs. Provider audit logs, such as CloudTrail or Cloud Audit Logs, are produced and retained by the customer. VeloDB control reporting does not cover the customer's provider-side logging.
• Tag-scoped reach. VeloDB mutating actions are conditioned on the resource-created-by: velodb tag. Resources outside that tag are outside VeloDB's operational control.
• Key management. Key ownership and rotation for customer-managed keys sit with the customer. VeloDB encrypts data at rest and supports a warehouse-level layer with the customer's own key. See Encryption at Rest.
• Availability topology. BYOC warehouses are single-AZ today; multi-AZ is in development. Availability targets are planning guidance for the customer's resilience design, not a commitment, and topology is the customer's responsibility.
• Direct console operations. Modifying or deleting VeloDB-created resources from the cloud-provider console is outside the supported model and can cause unrecoverable warehouse states.
• Decommissioning. VeloDB cannot delete resources in the customer account. Final cleanup of storage, keys, networking, and IAM is the customer's responsibility.

Evidence

Evidence	Source
SOC 2 Type II report, ISO 27001 certificate, DPA or security addendum	VeloDB Trust Center or the VeloDB Cloud account team
Cross-account and data-credential permission scope	BYOC on AWS, GCP, Azure
Control-plane and SQL audit evidence	Audit Logging
Infrastructure events in BYOC	Customer cloud-provider audit logs
Shared-responsibility boundary	BYOC Security, Security Overview
Offboarding and resource deletion	Offboarding Guide

For a walkthrough mapped to a specific assessment questionnaire, contact your VeloDB Cloud account team or use the VeloDB Trust Center.

Related Documentation

• BYOC Security
• Security Overview
• Compliance and Trust
• Audit Logging
• Network Security