Security and data protection
Incident response
How Telonic detects, handles and reports security incidents, when and how you are notified of a personal data breach, and how your deployment keeps running when a provider fails.
On this page
When something goes wrong, what matters is how quickly it is found, how well it is contained, and whether you hear about it from your supplier first. Telonic runs a defined incident response process for every security incident, from detection to a written review. Personal data breaches are notified to your named contacts without undue delay, and within 24 hours of becoming aware of a breach affecting your data. This page sets out the process, how severity is decided, what you are told and when, and how your deployment keeps running when a provider has an outage.
What counts as an incident
A security incident is any event that affects, or may affect, the confidentiality, integrity or availability of your deployment or your data. Examples include a suspected unauthorised access, a lost or exposed credential, or an outage of a provider your deployment depends on.
A personal data breach is a security incident in which personal data is lost, destroyed, altered, disclosed or accessed without authorisation. Personal data breaches carry specific notification commitments, set out below.
The process
| Stage | What happens |
|---|---|
| 1. Detect | Monitoring and alerts, a report from your team, a provider's notice or a Telonic engineer identifies a possible incident |
| 2. Triage | An engineer confirms whether it is an incident, assigns a severity, and names the person responsible for handling it |
| 3. Contain | Steps are taken to stop the incident spreading, such as revoking a credential, ending sessions or isolating a component |
| 4. Notify | Your named contacts are told, in line with the severity and the commitments below |
| 5. Remediate | The cause is fixed, and any affected service or data is restored |
| 6. Review | A written review records what happened, why, and what changes prevent it happening again |
Each step, and each action taken, is recorded with the time it happened. Where your deployment's audit log is relevant, it shows which records were accessed through the platform, by whom and when, so the scope of an incident can be established from evidence.
How severity is decided
Severity decides who is involved and how often you are updated. Response targets for each severity are set out in your agreement.
| Severity | What it means |
|---|---|
| Critical | Customer data is exposed or at clear risk, or your deployment cannot handle conversations |
| High | A control is weakened or a significant part of the service is affected, with no confirmed exposure of data |
| Normal | A limited issue with a workaround, and no risk to data |
| Low | A minor issue, or a question to investigate, with no effect on your service |
Critical incidents are covered 24 hours a day, seven days a week, in Arabic and English.
How and when you are told
Personal data breaches affecting your data are notified to your named contacts without undue delay, and within 24 hours of becoming aware of a breach affecting your data, with ongoing updates until the incident is closed. Confirmation is the point at which Telonic establishes that a breach has occurred. Work to contain it starts from detection, without waiting for confirmation.
The notification sets out what is known at the time: what happened, which data and which of your customers are affected, what has been done to contain it, what you may need to do, and who to contact. Updates follow as more is established. It is intended to support your own obligations, such as notifying a regulator or your customers. Your legal team decides what the law requires of you, and Telonic supports you with the facts and records you need.
After the incident is closed, you receive a written post-incident report: the timeline, the cause, the effect on your data and service, and the actions taken to prevent a repeat.
Monitoring and alerting
Your deployment is monitored continuously, with alerts to Telonic's engineers, so that we can often find a problem before your team reports it. Monitoring covers the health of the deployment, its connections to your systems and the providers it depends on. In your own cloud account or on your own premises, monitoring relies on the operational health signals, which contain no customer data and which you can switch off.
When a provider has an outage
Provider failover (switching to another provider when one fails) is configured during implementation. If a provider of speech recognition or of the language model (the AI model that decides the reply) has an outage, your deployment switches to another provider you have approved. Failover only ever switches to an approved provider in your chosen region, and fallback providers are tested in advance.
Behind failover sit documented business continuity and disaster recovery plans (the plans for keeping a service running, and restoring it, after a major failure), which are tested. Backups and disaster recovery copies are encrypted and stay in the same country as your deployment.
Exercises
Telonic's engineers rehearse the incident response process regularly, using realistic scenarios, and update the process with what they learn. Where it helps, we take part in your own incident exercises, so that both teams know who calls whom.
In practice
This example is illustrative. Wadi Assurance, an insurer, has named its head of information security and its data protection officer as incident contacts.
- At 09:12 on 15 October, a Telonic engineer reports that a laptop has been stolen. Monitoring raises an alert.
- The incident is triaged as high. The engineer's credentials are revoked and all of the engineer's sessions are ended.
- The audit logs of every deployment the engineer could reach, including Wadi Assurance's, are reviewed. They show no access to Wadi Assurance's deployment after the laptop was last used.
- Although no breach is confirmed, Telonic informs Wadi Assurance's named contacts, with the findings and the evidence.
- The written review, shared with Wadi Assurance, records the timeline and the changes made to device controls.
What your team controls
- Who your named contacts are for incident notification.
- The providers your deployment may fail over to.
- In your own environment, the operational health signals used for monitoring.