Security & compliance

Support tools hold more sensitive customer data than almost anything else a business runs — names, contact details, order history, complaints, and whatever customers volunteer in a message. This page covers the controls Tola gives you, and is written to be handed to IT or procurement directly.

Access control

Access in Tola is controlled at three independent levels, and all three have to allow an action for it to be possible.

Two practices are worth writing into your own policy: keep administrators to two or three named people, and review channel access whenever someone changes role — it is the setting that drifts fastest and the one nobody notices has drifted.

Single sign-on

Tola supports SAML single sign-on, so your team signs in through your existing identity provider — Okta, Entra ID, Google Workspace or any SAML 2.0 provider.

For an organisation of any size this is the control that matters most, because it moves account lifecycle out of Tola and into the system you already govern. When someone leaves, disabling their account in your directory removes their Tola access, with no separate step for anyone to forget. Your password policy, MFA requirements and conditional access rules all apply automatically.

If your security review has one requirement, it is usually this one.

Two-factor authentication

Where SSO is not in use, individual accounts can be secured with two-factor authentication using a standard authenticator app. Users set it up under their own profile, with recovery codes issued at the time.

Enforce this for administrators at minimum. An administrator account is access to every customer conversation in the business.

Audit logs

Tola records administrative and access activity: sign-ins, permission and role changes, channel configuration changes, and changes to account settings.

This gives you the answer to "who changed this, and when", which is what an incident review needs and what most compliance frameworks require evidence of. It is also, in practice, how most configuration mysteries get solved — a routing rule that stopped working usually stopped because somebody changed it.

Review the log periodically rather than only after an incident. Unexpected permission changes are worth noticing at the time.

Data ownership and export

The data is yours. Contacts, companies, conversations and attachments belong to your business, and you can export them.

For your own obligations under GDPR and comparable regimes, the practical points are:

• Contacts and conversations can be exported, which covers subject access requests.
• Contacts can be deleted, which covers erasure requests.
• Retention is your decision. Decide how long you keep conversation history and apply it deliberately. Support inboxes accumulate personal data indefinitely by default, and that is a liability rather than an asset.

If you operate under a specific framework — GDPR, HIPAA, PCI DSS, a national data residency rule — raise it during evaluation. The answer depends on your deployment, and it is much cheaper to establish before a rollout than after.

Deployment options

Tola can run as a hosted service or be deployed within infrastructure you control. Where the data physically sits, who can reach the underlying systems, and what your backup and retention arrangements look like all depend on which of these you choose.

For organisations with data residency requirements, or a policy against customer data leaving a particular jurisdiction, this is the conversation to have first — it shapes everything else in a security review.

Shared responsibility

Some risks are ours and some are yours, and being clear about the split avoids unpleasant surprises.

Ours: platform security, encryption in transit, availability, and the integrity of the software.

Yours:

• Who has access, and at what level. The most common cause of an incident in any support platform is an account that should have been closed.
• What your agents put in conversations. Full card numbers and passwords should never be typed into a support thread — by an agent or a customer. Train for this, and delete them when it happens.
• Which third parties you connect. Every integration is a place your data can travel to. Review them the way you would review any vendor.
• Retention. How long you keep things is a decision only you can make.
• Call recording consent, where you use voice. Requirements vary by jurisdiction and the obligation is yours.

A review checklist

For IT or procurement assessing Tola, these are the questions worth asking, and the ones we expect:

1. Can we enforce SSO through our identity provider, and does deprovisioning propagate?
2. Can we restrict individual agents to specific queues?
3. Is there an audit trail of administrative changes, and can we export it?
4. Where is the data stored, and can we choose?
5. Can we export everything if we leave?
6. Can we delete a specific customer's data on request?
7. What is the retention policy, and can we set it?
8. Which third parties will our data reach through the integrations we plan to use?

If an answer matters to your approval, get it in writing during evaluation rather than at rollout.