Incident notification commitment

Draft for legal review. The times below are proposals for the owner (D15). They must be met in practice before they are published as a commitment.

1. Purpose

This commitment says what we do when something goes wrong with security or personal data in iCall. It complements the DPA and the security overview.

2. What counts as an incident

A security incident is an event that harms or may harm the confidentiality, integrity or availability of iCall or the data in it. A personal data incident is one that leads to accidental or unlawful destruction, loss, change, disclosure of or access to personal data. Examples are a leaked recording, access by a person who should not have it, a stolen key, or a bug that shows one customer another customer's data.

A service outage is handled under the SLA. It becomes a security incident if data is also at risk.

3. Our commitments to customers

• Time. If an incident affects a customer's personal data, we tell the customer without undue delay and in any case within [24 hours · to be confirmed] of confirming it. We do not wait until the investigation is finished.
• Who and how. We write to the account owner and the security contact on file, and show a notice in the workspace [confirm the channels, for example email and workspace notice · to be confirmed].
• What we say. What happened and when, what data and people are likely affected, what we have done and what we advise the customer to do, and who to contact.
• Updates. We update the customer at least every [24 hours · to be confirmed] until the incident is under control, then give a final report within [10 business days · to be confirmed] with the cause and the steps to prevent it happening again.
• Help. We give the customer what it needs to meet its own duties to the authority and to the people affected, as the DPA says.

4. What the law expects

Under the Georgian Law on Personal Data Protection a controller must tell the supervisory authority, the State Audit Office, within 72 hours of identifying an incident, unless significant harm is unlikely, and must inform the people affected without unreasonable delay if significant harm is highly likely. A processor must tell the controller immediately [confirm the current authority and its notice channel · to be confirmed]. Under the GDPR, where it applies, a processor must tell the controller without undue delay and the controller has 72 hours to tell its authority.

This is why our commitment to the customer is short. The customer is the controller. It decides about notifying the authority and the people affected. When KCall is the controller of the data, for example website or account data, KCall makes the notice itself.

5. How we handle an incident

1. Detect and confirm: we check alerts and reports and decide if it is an incident.
2. Contain: we close the hole, for example by rotating keys, suspending access or blocking an integration.
3. Assess: we find out what data and which customers are affected, using the audit log.
4. Notify: we tell affected customers as above.
5. Fix and learn: we repair the cause, test the fix and write down what we learned.

6. Reporting an incident or vulnerability to us

Write to [security contact email · to be confirmed] with as much detail as you can. For a service outage use the support channels in the SLA. Please do not publish a vulnerability before we have had a reasonable time to fix it, and do not access or keep other people's data.

7. Records

We keep a record of every incident, with what happened, its effects and what we did, as long as needed for accountability and at least [3 years · to be confirmed] [confirm incident record retention · to be confirmed].