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 t8sgzw4qyyofyzuc2jy the voice log archiver (vla) is an automated system that fetches, converts, encrypts, and stores call recordings it ensures that voice logs are retained for extended periods (up to 8 years) without impacting the performance of the active contact center archival process workflow the vla operates through a four stage process to ensure data integrity and security fetching the system monitors the ameyo call server in real time new voice logs are identified and downloaded to the archiver server with a typical lag of only 20–25 minutes conversion raw audio files (separate in/out streams) are first converted to wav format the streams are mixed into a single wav file the file is compressed into mp3 format to optimize storage encryption the compressed files are secured using aes encryption a unique key is generated for each voice log and stored in the archiver database when byok is enabled for the contact center, this per call key is itself protected by the deployment's secret manager rather than stored in the clear — see data encryption docid\ tc9bqn20uz9snkahhinv8 for how the secret manager and key hierarchy work storage the final encrypted files are transferred to a mounted network drive (nas/san) via ftp user interface & search the vla console provides a centralized interface for supervisors and administrators search & retrieval supervisors and administrators can locate specific recordings using a combination of standard and advanced filters on their interface standard filters date range, campaign, queue, user/agent, customer phone number, and talk time call content filters call notes search for keywords within the notes added by agents qa scoring filter by "scored" or "unscored" calls dispositions filter by system or user dispositions advanced search allows attribute based queries using operators (e g , credit card number equals 1234) downloads single/bulk download users can download individual files or select multiple records to download as a zip file format downloads are typically provided in mp3 format for easy playback configuration & administration administrators have access to system level settings via the configuration tab audio controls ingain / outgain adjust the volume levels for the input (customer) and output (agent) audio streams values range from 1 to 9 presets select audio processing presets such as high phone, low phone, high voice, or low voice to optimize audio quality based on the source storage path define or update the destination directory on the nas/san storage reload applies changes made to the call server configuration without restarting the system monitoring & safeguards the system includes built in health monitoring to prevent data loss or server crashes disk usage protection the system continuously monitors disk space if free space falls below 5 gb , the fetching process stops automatically administrators must manually resume the service after clearing space execution details the monitoring tab displays the real time status of the "conversion" and "fetching" jobs operational guidelines prerequisites licensing separate licenses are required for voice log archiver infrastructure dedicated archiver server (windows/linux) network storage (nas/san) accessible via ftp/mapped drive ameyo call manager (for vla) and ameyo database access sizing considerations proper sizing is essential for performance factors influencing server requirements include total agents and calls per day average call duration retention period (e g , 1 year vs 5 years) recording format (mp3 compression ratio) retention & cleanup data lifecycle data is retained based on the configured policy (e g , 3 years) auto cleanup the system can be configured to automatically purge data older than the retention period to free up storage, though archival to external media is recommended before purging per tenant retention overrides (4 13 48+) administrators can configure per tenant voice log retention periods via the server preference store , overriding the global default the minimum retention is 3 months a nightly cleanup job automatically purges recordings that exceed the configured retention window number masking in voice logs when number masking is enabled at the process level, voice log filenames on the call server are masked by default the following controls are available reveal real numbers (4 13 9+) authorized users with the appropriate privilege can click an eye icon in the vla console to temporarily reveal the actual phone number associated with a masked recording unmasked filenames on call server (4 13 26+) the unmaskrawvoicelogs system configuration flag, when set to true , writes voice log files on the call server with the real (unmasked) filename while the ui continues to display masked values this is useful for integrations that rely on filenames matching actual phone numbers unmasked filenames in vla storage (4 13 38+) the unmasked filename behaviour was extended to recordings archived by vla, ensuring downstream systems consuming archived files also receive unmasked filenames token based voice log download api starting from version 4 13 25, a token based download api is available for secure programmatic access to voice log files external systems (crm, analytics, compliance tools) can request a short lived download token and use it to retrieve recordings without requiring a full ui session this is the recommended approach for automated integrations version history version enhancement release notes 4 13 9 authorized users can reveal real numbers via eye icon when masking is on 4 13 9 release notes docid 9nxxiuvss1xlp1svj ghj 4 13 25 token based voicelog download api for secure integrations 4 13 25 release notes docid 9qp nrj2vi08aiiqkvhp 4 13 26 unmaskrawvoicelogs flag for unmasked filenames on call server 4 13 26 release notes docid\ aftf0pmqlovldq f8wkot 4 13 38 extended unmasked filename behaviour to vla stored recordings contact center patch release notes version 4 13 38 docid\ pkcoa9s 8fugrj3c5jiv4 4 13 48 per tenant retention overrides (min 3 months, nightly cleanup) contact center patch release notes version 4 13 48 docid\ ohmti dqxjpuejrdrcdz0 interaction archiver docid 9tbb2hjiwrcf8yezirqjo number masking allows organizations to make customer phone numbers confidential, hiding them from agents and other users this feature ensures compliance with it regulatory standards and industry requirements regarding consumer data privacy when enabled, identifiable information like phone numbers is anonymized or masked, preventing unauthorized recognition or use beyond the intended purpose note number masking is available for voice only and does not apply to fusion applicability this feature is designed for use within the unified agent desktop (uad) or /app where ameyo serves as the primary interface it is also available in the mobile app / webtoolbar; however, in this context, the masking applies only at the visual interface layer the underlying contact number remains accessible through system level logs and developer tools key capabilities role based visibility administrators can grant specific user roles the privilege to view unmasked (actual) numbers for verification purposes process level configuration masking can be enabled or disabled for specific processes if enabled for a process, it applies to all campaigns within that process masking policies choose between random alphanumeric strings or partial character replacement configuration accessing the masking tab log in to the administrator console navigate to system configuration click on the masking tab enabling unmasked view for specific roles in certain scenarios, roles such as supervisors or analysts may need to verify actual phone numbers to grant this privilege in the masking tab, locate the "enable privilege to view the actual number for the user roles" section select one or more of the following roles to allow them to view unmasked values analyst executive group manager professional agent supervisor caution it is recommended to use this option cautiously to maintain data security configuring masking policies once masking is enabled for a process, you must select a masking policy 1\ random masking policy description replaces the phone number with a random alphanumeric string searching searching is enabled through a unique identifier in this policy, the unique identifier and the masked number are the same 2\ replacement masking policy description replaces specific characters of the actual number with 'x' configuration you define how many characters to show at the start (n) and at the end (n') of the number the remaining characters in the middle are masked constraint the preview and configuration are based on a maximum phone length of 15 digits the sum of the first characters (n) and last characters (n') must not exceed 15 if the total exceeds 15, an inline error is displayed applying changes after configuring the policy and roles, click apply important changes such as enabling, disabling, or modifying policies will only be visible to users after they log out and log in again to the ameyo application server it is recommended to make changes during non working hours to avoid impacting business operations once phone numbers are masked using a masking policy, they cannot be unmasked voice log filename masking when number masking is enabled, voice log filenames on the call server are also masked by default starting from version 4 13 26, the unmaskrawvoicelogs system configuration flag can be set to true to store voice log files with the real (unmasked) filename on the call server, while the ui continues to show masked values this is useful for integrations that match recordings by phone number ui masking consistency starting from version 4 13 33, number masking behaviour is aligned across all ui surfaces — including the agent toolbar and supervisor console — so that masked numbers appear consistently regardless of where they are viewed privilege management enhancements starting from version 4 13 48, administrators have expanded control over masking related privileges, allowing more granular assignment of who can view unmasked data across different user roles and contexts version history version enhancement release notes 4 13 26 configurable voice log filename masking via unmaskrawvoicelogs flag 4 13 26 docid\ aftf0pmqlovldq f8wkot 4 13 33 ui masking alignment across agent toolbar and supervisor console contact center patch release notes version 4 13 33 docid\ lnw2yk7bxjwbzqn hkjng 4 13 48 expanded mask related privilege management contact center patch release notes version 4 13 48 docid\ ohmti dqxjpuejrdrcdz0 high availability & disaster recovery docid\ wioprwrarqsodvqhkqlou