Data protection and GDPR

This page explains how data protection works on SOIS, who is responsible for what, and what you must do when you build on the platform. It complements the Privacy Policy and the public data-rights request form.

Who controls the data

SOIS is multi-tenant, so responsibility depends on where the data lives.

  • Network operators are controllers. When an organisation runs a branded network on SOIS, that organisation is the data controller for the personal data its tenants and customers put into it. SOIS acts as a processor on their behalf.
  • SOIS is controller for the data of accounts created directly with us and for this website.
  • Tenants decide what personal data enters their own workspace and why.

Each network has its own database and storage. Tenants are isolated and never share data with one another.

Data-rights requests

People can exercise their rights (access, rectification, erasure, portability, objection, restriction) in two ways:

  1. Through the operator. If they use a branded network, the request goes to that operator, who is the controller. SOIS, as processor, helps fulfil it.
  2. Through SOIS directly. The public form at sois.ai/legal/gdpr routes a request to the SOIS data team for accounts and data we control.

The request webhook

The public form posts to a Cloudflare Pages Function, which forwards the request server-side to the SOIS backend:

POST /api/data-request
Authorization: Bearer <shared secret>
Content-Type: application/json

{
  "kind": "data_rights_request",
  "type": "access | rectify | delete | export | object | other",
  "name": "...",
  "email": "...",
  "account": "...",
  "details": "...",
  "locale": "en-US",
  "country": "GB",
  "received_at": "2026-05-24T00:00:00Z"
}

The notification address is configured server-side only and is never exposed in page HTML. The endpoint validates the bearer secret, writes an audit log line, and notifies the data team. Requests are answered within the timeframe the law requires.

What this means when you build an extension

If your extension stores or processes personal data, design it so the controller can meet their obligations:

  • Minimise. Collect only what the feature needs. Put business fields inside the entity data JSON, and avoid storing personal data you do not use.
  • Be deletable. Personal data must be removable. Use soft deletes for user-facing records and make sure an erasure request can reach the rows your extension owns.
  • Be portable. Where you hold personal data, make it exportable in a common format.
  • Honour consent and permissions. An agent only ever acts within the permissions of the person it acts for. Never widen access to personal data beyond what the tenant has granted.
  • Keep secrets in the vault. Credentials and tokens belong in the encrypted password vault, retrieved only when an action needs them. Never log personal data or secrets.
  • No cross-extension leakage. Do not read another extension's data except through a governed integration contract the tenant has consented to.

International transfers and retention

Data may be processed in countries outside the user's own. Where it is, appropriate safeguards such as standard contractual clauses apply. Personal data is retained only as long as needed for the purpose it was collected for, then deleted or anonymised. Workspace content is removed on account closure, subject to legal requirements.

In short

  • Operators are controllers; SOIS is the processor for their networks.
  • Tenants are isolated; each network has its own database.
  • Data-rights requests reach the right controller, through the operator or through the SOIS form.
  • Build extensions to be minimal, deletable, portable, permission-aware, and secret-safe.