Security & trust
This page separates controls that are implemented today from readiness work that is still in progress. It is not a certification, audit opinion, or substitute for buyer diligence.
Last reviewed July 24, 2026
Implemented safeguards
Specific language matters. Every control below describes what the service does today, stated no more strongly than the evidence behind it supports.
Customer data is encrypted in transit over TLS and encrypted at rest through managed-provider protections. Designated third-party integration credentials receive an additional Google Cloud KMS protection layer with versioned, purpose-bound keys.
Authentication, workspace-scoped authorization checks, database row-level security, and storage access policies are used to separate customer workspaces and constrain access.
The production application targets Google Cloud Run in the us-east1 region. Other subprocessors have their own contractual and configuration-dependent processing locations.
Application secrets are kept out of client bundles and privileged service credentials are limited to server-side paths. Enterprise identity requirements can be reviewed during procurement.
The codebase includes automated dependency scanning and security-focused application controls. White Shoe is continuing to expand operating evidence, independent testing, and formal control documentation.
White Shoe does not train its own foundation model on customer content. Model-provider data handling depends on the applicable provider contract and configuration; current subprocessors are disclosed in the DPA.
Assurance status
| Area | Current status | What that means |
|---|---|---|
| SOC 2 | Readiness program | White Shoe does not currently have a SOC 2 report. Policies and controls are being prepared for a future assessment. |
| Independent penetration test | Planned | No completed independent penetration-test report is represented on this page. |
| Incident response | Being formalized | Response procedures and playbooks are being documented and exercised. Contractual and legal notification duties apply after an incident is assessed. |
| Auditability | Selected events | Application and infrastructure logs cover selected security and operational events; this is not presented as universal immutable audit logging. |
| Retention and deletion | Purpose-dependent | Retention varies by data category, customer instruction, contractual need, backup behavior, and legal obligations. Requests can be submitted through support. |
Direct answers
No. White Shoe does not currently have a SOC 2 report. It has an active readiness program, but readiness work is not certification and does not establish Type II operating effectiveness.
White Shoe does not train its own foundation model on customer content. Third-party model-provider handling depends on the relevant contract and configuration, which is why White Shoe discloses subprocessors rather than making a universal statement about every model.
Customer data is encrypted in transit over TLS and encrypted at rest through managed-provider protections. Designated third-party integration credentials receive an additional Google Cloud KMS layer. The service decrypts content in order to perform the processing a user requests.
The production application targets Google Cloud Run in us-east1. Processing by other disclosed subprocessors may occur in locations governed by their contracts and the configuration used for the service.
Yes. Enterprise prospects can request the current security packet, discuss identity and data-handling requirements, and review available evidence. White Shoe will distinguish implemented controls from planned work.
Procurement and diligence
Ask for the current security packet, subprocessor details, or a requirements review. White Shoe will identify any evidence gaps directly.