Skip to main content
We keep a written incident response plan, review it every quarter, and define roles and escalation paths before anything goes wrong. This page is the public summary of that plan.

​
The stages

  1. Detect. Monitoring, alerts, staff, customers and security researchers can all raise an incident.
  2. Triage. We confirm what happened and set a severity. The most severe incidents get an immediate response.
  3. Contain. We stop it spreading, for example by revoking access or isolating a component.
  4. Remove the cause. We fix the weakness that allowed it.
  5. Recover. We restore normal service and check it is working as it should.
  6. Review. Within a few working days we hold a review that looks for the cause in the system, not someone to blame, and track every action to closure.
AI behaviour is covered too. An agent that states something false, discloses something it should not, acts outside its instructions or treats someone unsafely is handled as an incident under the same plan, and so is a near miss caught before it reaches anyone.

​
When we tell you

If an incident affects your data, we tell you without undue delay, and no later than 72 hours after we become aware of it. We send what we know at that point and follow up in writing as we learn more, rather than waiting until every fact is known. The notice covers what happened, the kinds of data involved, roughly how many people are affected, the likely consequences, and what we have done and will do.

​
Your data and ours

  • Data from your calls, contacts and messages. We process it on your instructions, so you decide whether and how to tell the regulator and the people affected. We give you the facts and the help you reasonably need, and we do not contact your customers ourselves unless you ask us to in writing.
  • Our own data, such as user accounts, billing and security logs. We notify the regulator and the people affected ourselves, including the 72-hour supervisory-authority notification under GDPR Article 33 and the notifications required under POPIA section 22.

​
Staying available

  • The platform runs on managed infrastructure with redundancy at the database, compute and edge layers.
  • The database is backed up daily and encrypted, with point-in-time recovery within the retention window, in storage independent of the primary cluster.
  • We monitor availability and performance, schedule planned maintenance to keep disruption low, and tell affected customers about material incidents.
Recovery-time and recovery-point objectives are shared under a non-disclosure agreement. See Security pack.

​
Report a vulnerability

We welcome good-faith reports at security@getsmartalex.com and do not pursue legal action against research within the scope of our Vulnerability Disclosure Policy.