Data Encryption

overview data encryption protects sensitive customer and interaction data at rest across voice and digital channels when bring your own key (byok) encryption is enabled for a contact center, the platform encrypts call recordings, chat/voice transcripts, message attachments, and select customer pii (like phone numbers) using keys that are ultimately protected by an external secret manager — never by a key stored in plain form inside the product database or codebase secret manager and key hierarchy byok encryption uses a two tier (envelope) key model secret manager (master key) — the platform currently supports hashicorp vault as the external secret manager one vault connection (endpoint + auth details) is registered for the deployment, and the platform calls it to fetch the current master key no other secret manager type is selectable today — registering any value other than hashicorp is rejected data encryption keys (deks) — the master key is never used to encrypt customer content directly instead, it wraps/unwraps a data encryption key that is generated automatically the first time a given call, interaction, or configured context needs to be encrypted only the wrapped (encrypted) dek is stored in the product database — the plaintext dek exists only in memory while content is being encrypted or decrypted, and is re derived from vault on demand if vault is unreachable or returns an invalid response, encryption/decryption for that content fails safe (the operation is rejected) rather than falling back to an unencrypted key once fetched, a decrypted dek is cached briefly (on the order of minutes) to avoid calling vault on every single encrypt/decrypt operation a change to the master key or a context's encryption state can take a short time to propagate for that reason architecture at a glance the same four step pattern applies every time content is encrypted or decrypted, no matter which service is doing it — only the setup (top) happens once; everything below the divider happens on every call or interaction sequencediagram autonumber participant admin as 👤 administrator participant cms as ⚙️ cms\<br/>(configuration plane) participant svc as ☁️ content service\<br/>(voice/vla, chat & digital, or appserver) participant vault as 🔐 hashicorp vault\<br/>(master key) participant db as 🗄️ product database rect rgb(244, 248, 255) note over admin,cms setup — once, during onboarding admin >>cms register vault connection (endpoint + auth details) admin >>cms enable byok and per channel toggles end rect rgb(242, 249, 244) note over svc,db runtime — every call or interaction svc >>cms read byok toggle and vault connection details svc >>vault wrap / unwrap this context's dek vault >>svc plaintext dek (held in memory only) svc >>svc aes encrypt or decrypt the content svc >>db store the wrapped (encrypted) dek and the encrypted content end figure steps 1–2 happen once per deployment, when an administrator (or exotel professional services during onboarding) registers the vault connection and turns on byok steps 3–7 repeat for every single call or interaction the content service — voice/vla for recordings, chat & digital for transcripts and attachments, or appserver/framework for customer pii — reads its configuration from cms, exchanges only the wrapped key with vault, decrypts or encrypts the content in memory, and writes back the wrapped key the plaintext dek and the master key never touch the database, and the master key never leaves vault what gets encrypted under byok content key scope where it applies voicelog / call recordings one dek per call voice logger & archival (vla) — recording files/streams are encrypted before being written to archival storage chat and voice call transcripts one dek per interaction digital interaction archival and transcription pipeline chat/email attachments and other interaction media one dek per interaction media handling for chat, email, and other digital channels customer phone number (voice calls) dek resolved per process encrypted before being stored with the call's leg details customer name and phone (chat) dek resolved per process encrypted before being stored with the chat room / chat campaign customer details customer phone numbers and similar fields elsewhere dek resolved per process (or other configured hierarchy context) used, for example, to decrypt a customer's number when generating a voicelog download filename digit (dtmf) encryption, video recording encryption, and web access password encryption (see configuration parameters below) are separate, purpose built mechanisms and are not part of the vault backed byok key pipeline above how it works an administrator (or exotel professional services, during onboarding) registers the secret manager connection for the deployment — the vault endpoint and authentication details the administrator enables byok for the contact center and turns on the channel specific toggles for the content types that should be encrypted (attachments, custom fields, video recordings, voicelog archives) from that point on, the platform generates and manages the per call / per interaction encryption keys automatically — there is no manual per recording or per interaction key management for admins or agents when an agent, supervisor, or integration uploads or downloads protected content (e g plays back a recording, opens a transcript, downloads an attachment), the platform encrypts or decrypts it transparently using the key for that context certificate and key lifecycle steps for the secret manager itself (generation, distribution, rotation of the master key) follow your organization's security policy; exotel services can assist with initial enablement prerequisites encryption feature licensed for the tenant a reachable hashicorp vault instance with the master key available at the configured endpoint — this is the only supported secret manager type privileges contactcenter\ encryption configuration view encryption configuration (and related modify privileges when exposed in your build) for per context encryption settings; system\ vault auth details view vault auth details / system\ vault auth details add modify vault auth details for the vault connection itself backup and dr procedures updated to include key material — losing the vault master key makes all wrapped deks (and therefore all byok encrypted content) unrecoverable access & permissions surface ui access path notes byok toggle partial system or contact center preference (system configuration) gates the whole vault backed encryption pipeline; can be set globally (system) or per contact center secret manager (vault) connection api only get/post/put/delete /v1/vault auth details no dedicated administrator console screen was found for this in the current build — set up via api, typically during onboarding per context encryption configuration api only (read) get /v1/encryption configuration?context type=\&context id= returns the wrapped dek reference for a given contact center / process / campaign context; no admin write endpoint or ui screen was found digit encryption (dtmf) partial system configuration + admin apis separate mechanism from the vault/byok pipeline above voicelog encryption mode partial system / archiver configuration works with vla and interaction archiver privilege scope purpose contactcenter\ encryption configuration view encryption configuration contact center view per context encryption configuration system\ vault auth details view vault auth details system view the secret manager (vault) connection details system\ vault auth details add modify vault auth details system add, update, or remove the secret manager (vault) connection system\ dacx system admin digit encryption get key system dtmf / digit encryption key access system\ dacx system admin digit encryption get decrypted digits system decrypt collected digits (restricted) neither vault auth details privilege is pre assigned to a named role in the default role/permission mapping — grant them deliberately to the administrators responsible for the secret manager connection configuration parameters key / parameter description how to configure constraints / allowed values sample byokencryptionenabled master switch for vault backed customer managed key encryption system preference (applies to all contact centers) or contact center preference (overrides system for that cc) boolean; requires byok license; default false true vault connection ( apiendpoint , authdetails , vaulttype ) secret manager endpoint, auth headers, and vault type used to fetch the master key post / put /v1/vault auth details (one connection per deployment) vaulttype must be hashicorp ; any other value is rejected vaulttype "hashicorp" attachmentencryptionenabled encrypt email/chat attachments at rest process or campaign preference boolean true videorecordingencryptionenabled encrypt stored video kyc / video chat recordings process preference boolean true encryptionkey wrapped dek reference for a context (call, interaction, process, etc ) managed automatically; readable via encryption configuration api managed per context; versioned; generated on first use (managed by security team) voicelogencryptionmode voicelog archive encryption mode system configuration + vla mode enum per deployment aes enablepasswordencryptiononwebaccess encrypt passwords on web access channel system preference boolean true interaction custom field encryption and certificate management follow the same encryption configuration hierarchy; enable only after key material is provisioned and validated in a non production environment limitations hashicorp vault is the only supported secret manager in this build — other vault/kms backends cannot be selected only one secret manager connection can be registered per deployment; it is not scoped per contact center no administrator console ui was found for the secret manager connection or for viewing per context wrapped keys — both are api only in the current codebase decide byok at setup time, not after the fact enabling byok only encrypts content going forward — it does not retroactively encrypt existing data, and there is no supported way to dynamically switch byok on or off for a contact center once content has been created under the current setting changing it later requires a manual re encryption/decryption exercise key rotation and key versioning for the master key are not currently supported — treat the vault master key as long lived and protect it accordingly crm integrations are outside this encryption boundary customer data forwarded to a connected third party crm is not encrypted or decrypted through this pipeline — if your crm integration needs the same protection, address it separately with your crm provider encryption is one way without keys — document key escrow and rotation before enablement if the vault master key becomes unavailable, all byok encrypted content becomes unrecoverable — there is no fallback to an unencrypted key mixed encrypted and legacy plain text records can coexist during migration; plan re archival where required byok and attachment encryption may require additional infrastructure (hsm/kms behind vault) per enterprise policy related pages security and compliance docid\ v t8sgzw4qyyofyzuc2jyvoice logger and archival (vla) docid\ lttux m4xlc8t r4yqddvinteraction archiver docid 9tbb2hjiwrcf8yezirqjonumber masking docid 6wrp8ee7j1w5bzcezcco9high availability & disaster recovery docid\ wioprwrarqsodvqhkqlou