#Data Protection by Cell
Status: Available. What the platform does to protect data in API exchange, how the three cells differ, and which norms the measures in the United Kingdom and Indonesia rely on.
Purpose: to help you describe the protection of the exchange in your own documentation and risk assessment. The page describes the technical properties of the platform; the legal assessment for your case is made by you and your lawyer.
#Contents
#What is common to all cells
| Property | How it works |
|---|---|
| Connection | API exchange runs over HTTPS (TLS 1.2 and 1.3), using the server's operating system facilities |
| Minimization | without the fields= parameter, personal data does not arrive in responses, and a named field arrives separately (Minimization and Field Selection) |
| Disclosure log | every disclosure of personal data is recorded in a log without values (Cells and Data) |
| Webhook signature | each event is signed with the platform key (JWS, Ed25519), and the recipient verifies the sender's authenticity using the JWKS key set (Webhooks) |
| Thin events | a webhook contains only the type, time, and object identifier; your system requests the data through the API |
| AI models | before text is sent to a model, personal data is masked (Protecting Personal Data from Leaking into AI Models) |
| Isolation | each cell has its own database, keys, and secrets; a key is valid only in its own cell |
#Cell RU
- API exchange runs over HTTPS. For the security of the exchange, the platform relies on minimization: request only the fields you need.
- The webhook signature confirms that the platform sent the message and that it has not been altered. This is a check of the sender's authenticity, not concealment of the content.
- The disclosure of personal data is recorded in the disclosure log.
- Personal data is issued over the API only to recipients located in the Russian Federation: for the
conversations:*andleads:*scopes, a narrow list of allowed IP addresses and the Russian Federation as the receiving system's country are mandatory, otherwise403 pii_transfer_not_allowed(Transferring Personal Data). - The JWE format for personal data fields is not offered on the RU cell.
The platform does not provide services for protecting communication channels; if your threat model calls for special channel protection, apply it on your side or use the connection provided by your communications provider.
The obligations of the personal data operator remain with you as the tenant; the platform acts as a processor on your instruction.
#Cell EN (United Kingdom)
On top of TLS 1.2 and 1.3, the EN cell can return personal data field values in the JWE format (RFC 7516) to a public key that you have registered (JWE Format): ECDH-ES+A256KW (P-256, P-384, X25519) or RSA-OAEP-256 (2048 bits or more) with A256GCM. Only the holder of the private key can read such fields, including on your proxies, in queues, and in logs.
Reference norms:
- UK GDPR, Art. 5(1)(f) and Art. 32: security of processing, taking risk into account; encryption is named explicitly among the example measures (Art. 32(1)(a)). The obligation lies on both the controller and the processor.
- UK GDPR, Art. 34(3)(a): data subjects may be left un-notified of a breach if the data is unintelligible to outsiders, for example because of encryption. Notifying the ICO under Art. 33 remains in force.
- ICO and NCSC: the guidance uses proven algorithms rather than home-grown cryptography, TLS 1.2 or 1.3, keys of sufficient length, and key management. The key profiles on the EN cell were chosen with these recommendations in mind.
- Data (Use and Access) Act 2025 changed the regime for transferring data abroad (the "data protection test" for the level of protection); the Art. 32 provisions on security were not changed.
This is one of the protection measures. The JWE format does not change who is the controller and who is the processor, and does not make a transfer outside the United Kingdom anything other than a transfer. Key management and incident response on your side remain with you.
#Cell ID (Indonesia)
On top of TLS, the ID cell can return personal data field values in the JWE format to a public key that you have registered (JWE Format): ECDH-ES+A256KW on P-384 or X25519, or RSA-OAEP-256 / RSA-OAEP-384 with keys of 3072 bits or more; content encryption A256GCM. These algorithm families are present in the BSSN list of Indonesian cryptographic algorithms (BSSN Decree 443/2025, Kepka BSSN 443/2025).
Reference norms:
- Law No. 27/2022 on Personal Data Protection (UU PDP), Art. 35-39: the controller and the processor ensure data security through technical and organizational measures proportionate to the level of risk. The format helps to meet these obligations.
- Art. 46: notification of a protection breach within 3×24 hours.
- Art. 56: transferring data abroad requires an equal or higher level of protection, or safeguards, or consent.
- Government Regulation 33/2026 (PP 33/2026), in force 16 January 2027: Art. 123 names encryption among the technical measures; Art. 162 takes the data format (open, masked, or encrypted) into account when assessing a cross-border transfer.
The feature is not a cryptographic module that has undergone BSSN assessment under BSSN Regulation 11/2024. It does not replace your risk assessment, breach notification, and meeting the requirements on cross-border transfer.
Where the ID cell physically runs. The ID cell's servers are hosted in the United Kingdom (a shared host with the EN cell, but separate processes, databases, and secrets). From the standpoint of Indonesian law, this is a transfer of data abroad on the controller's part: assess it under Art. 56 UU PDP and, from 16 January 2027, under Art. 160-167 PP 33/2026. The JWE format is taken into account in such an assessment but does not replace it.
#Summary table
| RU | EN | ID | |
|---|---|---|---|
| HTTPS (TLS 1.2 and 1.3) | yes | yes | yes |
Field selection fields= | yes | yes | yes |
| Personal data disclosure log | yes | yes | yes |
| Webhook signature (JWS, Ed25519) | yes | yes | yes |
| Masking of personal data before the model | yes | yes | yes |
| JWE format for personal data fields | no | yes | yes |
| Restriction of personal data disclosure to recipients in the Russian Federation | yes | not applicable | not applicable |