Compliance
Certifications, data handling, residency, subprocessors, retention and the shared responsibility model.
Certifications
| Standard | Status | Scope |
|---|---|---|
| SOC 2 Type II | Target | Platform, all regions |
| ISO/IEC 27001 | Target | Platform, all regions |
| ISO/IEC 27017, 27018 | Planned | Cloud controls, PII in cloud |
| GDPR | Applicable | Processor; DPA with SCCs available |
| DPDP Act (India) | Applicable | Data fiduciary obligations for bom1 |
| HIPAA | Planned | BAA on Enterprise, restricted to designated regions |
| PCI DSS | Not pursued | Do not process cardholder data in a session |
Report requests go to compliance@workspaces.build. Reports are available under NDA.
Data classification
| Class | Examples | Where it lives |
|---|---|---|
| Customer content | Session filesystems, logs, recordings, browser profiles, secrets | The session's region only. Never leaves it |
| Customer metadata | Session IDs, states, usage quantities, placement decisions | Global, for billing and the API |
| Account data | Organization, members, keys, billing details | Global |
| Platform telemetry | Host metrics, capacity, placement scores | Global, no customer content |
The split is the question every regulated customer asks: content is regional, metadata is global. The fact that a session existed and consumed 402 seconds is in the global billing store; what it did is not.
Residency
{
"residency": {
"mode": "pinned",
"regions": ["fra1"],
"applies_to": ["sessions", "volumes", "snapshots", "recordings", "logs"],
"allow_cross_region_copy": false
}
}
Enforced at four layers: admission refuses a create in a disallowed region; the placer filters disallowed regions before scoring; the storage layer refuses to materialise content outside the allowed set; and the usage API keeps aggregates regional where the policy requires it.
A cross-region snapshot copy that would violate residency is refused with residency_violation, not
silently honoured.
Retention
| Data | Default | Configurable | Deletion |
|---|---|---|---|
| Session filesystem (scratch) | Destroyed at session end | No | Immediate, block trim |
| Volumes | Until deleted | — | On request, immediate |
| Snapshots | Until deleted or expires_at | Yes, per snapshot or by rule | Immediate |
| Recordings | 7 days | 1–365 days | Immediate |
| Run logs | 7 days | 1–90 days | On schedule |
| Session metadata | 90 days | No | On schedule |
| Usage events | 13 months | No | Required for billing disputes |
| Invoices | 7 years | No | Statutory |
| Audit log | 7 years | No | Statutory |
| Browser profiles | Until deleted | — | Immediate |
Deletion is a tombstone plus key destruction for encrypted data, followed by block reclamation. Encrypted data whose key is destroyed is unrecoverable immediately, which is the practical meaning of deletion for anything that has been replicated.
Subprocessors
| Subprocessor | Purpose | Regions | Content access |
|---|---|---|---|
| Datacentre operators | Physical hosting | Per region | None — encrypted at rest and in transit |
| Payment processor | Billing | Global | Billing data only |
| Email provider | Transactional email | Global | Email addresses and message content |
| Error tracking | Platform errors | Global | Platform telemetry only; scrubbed of customer content |
| Status page provider | Status publication | Global | None |
The current list is at workspaces.build/subprocessors. Customers on the notification list get 30
days' notice before a new subprocessor is engaged, with a right to object.
Shared responsibility
| Platform | Customer | |
|---|---|---|
| Physical security | ✅ | — |
| Host and hypervisor patching | ✅ | — |
| Tenant isolation | ✅ | — |
| Platform floor enforcement | ✅ | — |
| Encryption at rest and in transit | ✅ | — |
| Availability and SLOs | ✅ | — |
| Egress policy content | Mechanism | Rules |
| CLI and tool allowlists | Mechanism | Contents |
| Tool handler safety | Built-ins | Their own handlers |
| Tier selection | Boundaries | Choosing the right one |
| Secret scoping | Vault and injection | Which tiers, which TTL |
| API key hygiene | Storage and revocation | Distribution and rotation |
| What the agent is told to do | — | ✅ |
| End-user authentication | — | ✅ |
| Data put into a session | — | ✅ |
The line is clear: the platform guarantees the boundary, the customer decides what to put inside it and what it may reach.
Processing personal data
If sessions process personal data:
- Sign the DPA. Available in the console; SCCs included for transfers out of the EEA.
- Pin residency to the regions your lawful basis covers.
- Disable recordings, or set a short retention — a recording of a logged-in session is personal data in a form that is hard to subject to a deletion request.
- Scope
end_user_idto a pseudonymous identifier, not an email address. It appears in usage exports and invoices. - Avoid personal data in
labelsandmetadata. They are global metadata, retained for 13 months, and present in billing records. - Use short-lived secrets so a credential grant is bounded in time.
Data subject requests
curl -sS "$WB_BASE_URL/end-users/eu_customer_4821/data-export" \ -H "Authorization: Bearer $WB_API_KEY" curl -sS -X DELETE "$WB_BASE_URL/end-users/eu_customer_4821?delete_content=true" \ -H "Authorization: Bearer $WB_API_KEY"
Deletion removes the end-user record, their volumes, snapshots, recordings and browser profiles.
Usage events are retained in pseudonymised form — end_user_id is replaced with a one-way hash
— because the aggregate is needed for billing records that are themselves a statutory obligation.
This is documented in the DPA rather than left as a surprise.
Incident notification
| Severity | Notification |
|---|---|
| Confirmed breach of customer content | Affected customers within 24 hours; regulators per statutory deadline |
| Suspected breach under investigation | Affected customers within 72 hours |
| Platform vulnerability, no exploitation | Disclosed with the fix, or within 90 days |
| Availability incident | Status page in real time |
Breach notifications go to the organization's security contacts, which are set separately from billing contacts for exactly this reason.
Audit evidence
curl -sS "$WB_BASE_URL/audit/export?period=last_quarter&format=jsonl" \ -H "Authorization: Bearer $WB_API_KEY" -o audit.jsonl
The audit log is hash-chained and tamper-evident. Each entry carries prev_hash and hash, so a
full export can be verified independently:
jq -r '[.prev_hash, .hash] | @tsv' audit.jsonl | ./verify-chain
This is what turns "we have logs" into evidence an auditor accepts, and it is why break-glass entries are in the same chain as everything else.