Security and data protection
Customer conversations are sensitive. That is why data minimisation and controlled access are part of the design – not something added afterwards.
Data minimisation
We process the data a capability actually needs – and no more. New capabilities are assessed on the data they genuinely require.
Provider permissions by need
When integrating with providers such as Google and Microsoft, we request the permissions the chosen capability requires, and only when the user enables it. Some providers themselves define which permissions a given action requires.
Secure handling of integration tokens
Tokens for connected accounts are exchanged and used server-side and stored protected in Supabase Vault. The browser never receives access or refresh tokens.
Separation between workspaces
Data is logically separated between customers and workspaces so access does not cross organisations.
Permission-based access
Access within the platform is governed by permissions and entitlements in each workspace, so users only see what their role allows.
Encryption and operations
Data is transmitted encrypted over TLS/HTTPS, secrets are handled server-side, and environments are kept separated in our operational setup.
Traceability of administrative actions
Relevant administrative and support actions can be traced, and audit trails exist for central operations such as connecting and disconnecting integrations.
Calendar content
When calendar data is used to find suitable meeting times, the principle is to rely on free/busy information rather than meeting titles, descriptions or other calendar content where such details are not necessary.
This page describes how we work with security and data protection in practice. It is not a legal guarantee, and we do not claim certifications or attestations we cannot document.
Want to follow the development of EasyAfterCall?
Get in touch for a conversation about your needs, or log in if you already have access to the platform.