Security and data protection
Encryption
How your data is encrypted in transit and at rest, how encryption keys and credentials are managed, and what you control in your own cloud account.
On this page
Encryption means that your customers' data cannot be read by anyone who intercepts it on a network or obtains a copy of stored data without the key. Telonic encrypts data as it moves between your systems and your deployment, and whenever it is stored, including in backups. In your own cloud account, you can hold the keys yourself. This page sets out each connection and store, how it is protected, and how keys and credentials are managed.
Data in transit
Every connection between your systems and your deployment is encrypted with TLS (Transport Layer Security, the standard encryption for data sent over networks), version 1.2 or higher. Call audio is encrypted with SRTP (Secure Real-time Transport Protocol, the standard encryption for voice carried over networks) by default. Unencrypted call audio is used only over a private network connection between your site and your deployment, and only at your written request.
| Connection | Protection |
|---|---|
| Your team using the Telonic console (the web application your team uses) in a browser | TLS 1.2 or higher |
| Sign-in through your identity provider (the system that manages your staff's logins) | TLS 1.2 or higher |
| Lookups, write-backs and actions in your systems | TLS 1.2 or higher, with the credentials for each system held as described below |
| SIP signalling (setting up, transferring and ending calls) from your phone system | TLS 1.2 or higher. Your trunk is authenticated with IP allow-listing (accepting connections only from agreed network addresses) and SIP digest credentials (a username and password check on each call), and mutual TLS (where both sides present a certificate) is supported |
| Call audio | SRTP by default. Unencrypted only over a private network connection, at your written request |
| Messages arriving from Meta's WhatsApp platform and other channel networks | TLS |
| Connections between components inside your deployment and to providers in your region | TLS |
| Text sent to a language model (the AI model that decides the reply) outside your region, only if you choose one | TLS, with personal information replaced by placeholders first |
Data at rest
Everything your deployment stores is encrypted with AES-256 (the Advanced Encryption Standard, using 256-bit keys). That covers call recordings, transcripts and messages, summaries, the customer record, the audit record, and the credentials used to connect to your systems. Backups and disaster recovery copies are encrypted in the same way and stay in the same country as your deployment.
Key management
Encryption keys are managed through the hosting environment's key management service (the cloud service that creates, stores and controls the use of encryption keys). Keys are kept separate from the data they protect, their use is restricted to the services that need them, and every use is logged by the key management service. Keys are rotated (replaced with new keys) on a regular schedule, and without delay if a key is suspected to be compromised.
In your own cloud account, customer-managed keys are supported. You create and hold the keys in your own key management service, and your deployment uses them with your permission. Because you control the keys, you can revoke that permission, and data encrypted with them can then no longer be read. Your own cloud account can be on Microsoft Azure, AWS, Google Cloud or Core42.
Credentials for your systems
To look up and act in your systems, the agent uses credentials your IT team issues, such as an API key (a secret code that identifies one system to another) or OAuth (a standard way to grant one system limited access to another without sharing a password). These credentials are stored encrypted in a secrets store (a service built to hold credentials securely), never in the agent's configuration, in code or in logs. Each credential is used only by the connection it belongs to.
Ask your IT team to issue each credential with only the permissions the agent needs in that system, so that the credential itself enforces the limit. Your team can revoke any credential from your side at any time, which stops the connection. Credentials are replaced on the schedule agreed with your IT team.
In practice
Rimal Air, an airline, hosts its deployment in its own cloud account and holds its own keys.
- The airline's security team creates the encryption keys in its own key management service, and grants the deployment permission to use them.
- Its IT team issues a credential for the reservation system with read access to bookings and permission to rebook within fare rules, and nothing more.
- Calls from the airline's phone system reach the deployment with signalling over TLS and audio over SRTP.
- During a period of delays and cancellations, the agent rebooks passengers, and each change travels to the reservation system over TLS.
- The security team's own logs show every use of its keys by the deployment.
What your team controls
- In your own cloud account, the encryption keys, and the permission to use them.
- The credentials the agent uses in each of your systems, their permissions, and revoking them.
- Whether call audio may run unencrypted over a private network connection, in writing.
Related
- Hosting and data residencySecurity and data protection
- Voice: connecting your telephony over SIPChannels
- Access control and single sign-onSecurity and data protection
- Deployment separationSecurity and data protection
- What we need from your IT teamIntegrations
Product names and logos are trademarks of their owners. Their mention shows systems Telonic connects to and does not imply partnership or endorsement.