Control Mapping
This page maps the controls for a VeloDB Cloud BYOC deployment to SOC 2 criteria, showing security assessors which controls VeloDB owns and which controls the customer owns.
BYOC (Bring Your Own Cloud) deploys warehouse compute and customer warehouse storage in the customer's cloud account. This placement applies to the customer data plane. It does not mean that every related record remains in the customer VPC or selected region. Control-plane metadata, operational telemetry, logs, support and diagnostic records, query-related records, access evidence, and other operational records are handled according to the applicable DPA, Security Addendum, BYOC Addendum, retention policies, support processes, telemetry documentation, and subprocessor disclosures.
This page covers six control domains: access management, change management, incident response, logging and monitoring, infrastructure provisioning, and vendor management. For each control, it identifies the responsible party, the applicable SOC 2 Trust Services Criteria (TSC), 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 | Responsibility 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) is a customer-owned control that VeloDB's design assumes the customer operates. These controls appear in the right column of each table. If a complementary control is not operating effectively, the paired VeloDB control may not meet its objective.
BYOC Operating Boundary
The boundary determines who can technically perform each control activity.
- Cross-account trust. The customer creates a cross-account IAM role that trusts the VeloDB account ID
757278738533and 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: velodbtag. 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 | Enforces least-privilege access to the Console and warehouse. 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 | Allows mutating cloud actions only on resources with the resource-created-by: velodb tag, preventing VeloDB from modifying 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 VeloDB 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 | Operates provisioned infrastructure without requiring direct changes in the cloud-provider console 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, which you can query through SQL or review in the VeloDB Console. | Review Audit Logging and confirm deployment-specific retention and evidence needs with VeloDB Support. |
| 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 | Supports the documented BYOC availability topology. | Define the high-availability and disaster-recovery topology. Review Reliability and confirm deployment-specific resilience requirements with VeloDB Support. |
| VDB-IP-04 | CC6.1, CC8.1 | Deletes the warehouse during decommissioning. Removing the last warehouse in the VPC also destroys the VeloDB-managed BYOC infrastructure. | Revoke the cross-account role and trust, and delete any remaining customer-owned storage, keys, networking, and private-connectivity resources. 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.
- Maintain 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.
- Manage infrastructure-layer logging and review provider audit logs.
- Set audit retention and collect the evidence your program requires.
- Manage key material and the data-protection, high-availability, and disaster-recovery posture of the account.
- Complete account-side offboarding to revoke access and delete resources after warehouse deletion.
BYOC Exclusions and Assumptions
The following items are 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. Mutating actions performed by VeloDB require the
resource-created-by: velodbtag. Resources without that tag are outside VeloDB's operational control. - Key management. The customer is responsible for owning and rotating customer-managed keys. VeloDB encrypts data at rest and supports a warehouse-level encryption layer that uses the customer's own key. See Encryption at Rest.
- Availability topology. Availability and resilience requirements depend on the deployment. Review Reliability and confirm deployment-specific requirements with VeloDB Support.
- 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 deletes the VeloDB-managed resources that its scoped role is authorized to delete. The customer is responsible for revoking access and deleting any remaining customer-owned storage, keys, networking, and IAM resources.
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 help mapping these controls to a specific assessment questionnaire, contact your VeloDB Cloud account team or use the VeloDB Trust Center.