🔏 Data Security Document

This document describes Atobi’s infrastructure, processes, and policies concerning data privacy, security, and incident management. It summarizes the organizational and technical measures we have implemented to ensure secure and reliable use of the Atobi platform.

Application Security

Atobi ensures that users of the platform have access only to the data they are authorized to access. The security model combines data access, audiences, and module access rights.

Data Access

The system provides a layered data access control, built around the user’s responsibilities for various “locations”.
A user has a primary work location and default access to data from this location.
Regional managers or others with responsibilities for many stores will be granted access on a higher organizational level, e.g., “All of Germany”, and will, as a default, have access to all the stores in Germany.
A user can be granted “Global” access, by-passing the location-based controls and allowing access to all data from all the locations.
A user can be promoted to be “System Owner”, also entitling them to full access to all data and system configurations.

Modular Access

Each user has detailed permissions for each module, controlling creation and management of content.

Modules include:

Administration
User Management (local or global)
Locations
Professions (work titles)
Article Studio
Channels Studio
Engagement Studio
Complaints

Audiences

When publishing content, at least one Audience must be assigned to view the content.
An Audience is defined by one or more locations and optionally one or more professions.
Example audiences include: “All store managers in Germany,” “All full-time employees in Stockholm,” or “All colleagues globally.”
When configuring Feed channels, where multiple users can publish content (posts), there are specific configurations to control (Feed groups) what audiences the user needs to be a member of to be allowed to make posts - and also which audiences are required to see such posts.

Authentication and Passwords

Access Tokens

Atobi API Authentication is based on JWT access tokens, with a lifetime of 1 hour, and an automatic refresh mechanism, using a refresh token valid for 30 days.
During token refresh, the user’s access is revalidated, and if revoked, no new token is issued, and access to the system is prohibited.
The Access token contains several claims, used by the different Atobi services to validate the user’s identity, the location, the audiences, etc, all used to ensure the proper data access controls are applied.

Passwords

Passwords have a minimum length of 6 characters, must contain at least one lowercase character, one uppercase character, and one non-alphabetic character.
Passwords are stored as salted hashes using the BCrypt algorithm, preventing anyone from gleaning the actual passwords in the databases.
Passwords are never stored on the user's device or in the browser. Instead, a JWT token is stored securely.
The token is cleared when the user logs out or the token expires.

Forgotten Passwords

To change a password, a user must always provide the old password.
When a password is forgotten, a user can request a password reset. A secret link to reset the password is sent to the user's primary email address.

Temporary Passwords

An administrator can set a one-time temporary password, which can be shared with the user, and which is required to be changed upon the next login.

Single Sign-On (SSO)

The system can be configured to trust an external Identity provider using SAML2 or Open ID Connect protocols. Once the external IdP “confirms” the validity of the user, Atobi issues an access token.
Through these protocols, automatic user, location, and profession provisioning is also an option, mapping claims to the user’s primary location and work title.

Easy Access

The system can be configured to allow access to content published to a specific channel, without providing a password - this can be useful for semi-public content, or in situations where it’s desired to know the identity of the users accessing the content, but not requiring them to authenticate using a password.
A mix of Easy-access channels and regular channels is possible, allowing password protection for most content and not for some.

Open Registration

The system can be configured to allow users to join the system without a prior invitation.
The user is asked to select a work location, provide their first and last name, and choose a password. The user’s profession is set to the configured default.
Based on the combination of the location chosen by the user and the default profession, the user is assigned to any audiences that match.

User-Generated Content

If Chat, feed posts, and comments are enabled, users can generate content, which in turn others can object to (complain about).
Administrators (with complaint permissions) can moderate and take action on such complaints and are notified upon new complaints.

System Architecture

The Atobi application consists of a web/browser application and multiple services, all hosted on Amazon Web Services (AWS) or Microsoft Azure cloud infrastructures within the EU. Atobi is migrating remaining services from AWS to Azure, expected to be completed by late 2026.

Mobile/Front-end Application

The front-end web browser application is accessed through a customer-specific sub-domain under the atobi.io domain. Customer-specific logos, titles, fonts, help email, etc., are injected into the generic website at runtime and presented fully white-labeled.
Microsoft Edge, Google Chrome, and Apple Safari browsers are supported.
The application can also be installed as a Progressive Web Application (PWA), also known as a Home Screen App on Apple devices, on Android, iOS, iPadOS, MacOS, and Windows mobiles, tablets, laptops, and desktops.
The website/PWA utilizes a service worker, which runs in the background for data caching (secured by the browser) and for receiving Web push notifications, even if the website is not in focus/opened.

Services (APIs)

All services used by the frontend application can also be accessed headless and are documented via OpenAPI specifications. For integration with Atobi for workflow automation and user provisioning, contact help@atobi.io.
All Azure services operate on a serverless auto-scaling infrastructure within the EU.
AWS services operate on an auto-scaling server cluster behind an auto-scaling load balancer, ensuring quick response even at high load and self-healing in case of infrastructure outages.

Data encryption

Data at rest is encrypted using AES256 encryption on both AWS and Azure.
Data in transit is encrypted via SSL/TLS. The system (e.g., https://app.atobi.io) is not available without SSL encryption and automatically redirects HTTP to HTTPS.

Web Security

All connections to and from the service use HTTPS with the TLS 1.2 protocol or higher - using SHA256withECDSA (eq. to 3072-bit RSA) encryption.
Sensitive cookies are set with secure- and http-only ﬂags.
All user input is validated before processing. Special care is taken to prevent Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), and SQL Injection.

Malware Protection

Malware definitions are updated regularly and automatically.

Data Persistence Layers

Data persistence is ensured through several technologies.

For user data, a database layer is used - each tenant has its own individual database, served by the same database server (in AWS).
For user-uploaded data, various object storage solutions are used (Primarily Azure storage tables, user avatar images in AWS S3). Each tenant has its own dedicated object store, isolated to this tenant only.
The object stores are only accessible for requests carrying a SaS token, which is unique for each request and generated only by the Atobi file-service service after validating the user’s permission to access these specific assets by checking its link to a piece of content and the user’s right to access this article/post.
The articles (and feed posts) and associated data are stored in a central Azure database service, where tenant isolation is achieved using Row Level Security.
A few of the services leverage a NoSQL database in Azure. Tenant data isolation is achieved through an individual container for each tenant.

Data analytics

Atobi offloads online analytics to a central data warehouse, where data is collected for each of the different services on an hourly basis.
The data warehouse is not accessible from the Internet.
Using the collected data in the data warehouse, data analysis cubes are generated and are exposed through a 3rd party service from Sisense, operated from an AWS data center within the EU.
The frontend web application incorporates data analytics dashboards, and data access control is facilitated through a dedicated (Sisense) access token, generated by Atobi, and provides the required access control for the analytical data cubes and dashboards to adhere to each user’s location/audience-based permissions.
Tenant data isolation is achieved using Row Level Security.

Chat Service

The chat service consists of the core Microsoft Azure communication service (ACS), which is a bare-bones messaging infrastructure (also powering Microsoft Teams).
ACS is extended via a dedicated Atobi Chat service, providing additional features, to become a modern, responsive ad-hoc chat service.
Each tenant has its own ACS service, isolated for this tenant.

Protection of Servers and Infrastructure

Access to the production environment requires either an encrypted SSH or VPN connection. Access is limited to a small group of DevOps engineers and requires Multifactor authentication.
On all AWS servers, all ports and services are blocked by default, and only the few required ports for each service are open.
All infrastructure (serverless functions, object stores, networks, servers, clusters, load balancers, message queues, web apps, etc.) is managed under a GitOps regime. All services are defined and configured through code and are only provisioned through a DevOps pipeline - no manual configuration is allowed.
The Least-privilege principle is applied.
Security-critical patches are installed within 24 hours of availability.
Atobi services are automatically protected against DDoS attacks.

Logging and Monitoring

Operations performed by users in the application are logged to a centralized audit log.
24/7 monitoring and automated alerting ensure Atobi DevOps engineers can act quickly in case of service disruptions.
Server logs relevant to security are stored in a centralized way and are subject to analysis and automated alerting.

Disaster Recovery, Backup, and Redundancy

Atobi strives to achive 99.95% uptime, excluding scheduled maintenance windows.
All customer data is backed up daily and retained for 30 days in another availability zone/region.
All critical services are set up redundantly with automatic failover to ensure high availability
In case of a loss of a datacenter, GitOps code, combined with data backups, enables Atobi to reestablish a service in a new datacenter/region within a few hours.

Data Centers

Atobi's data centers are operated by Amazon Web Services, Inc., and Microsoft Azure, which are ISO 27001:2013 certified.

Security During Development

Atobi development environments are separated from testing and production environments.
Production data is never transferred out of the production environment to test environments.
All changes to Atobi code are peer-reviewed by senior developers who have extensive knowledge of application security. The application is developed according to industry best practices, and measures are taken to prevent vulnerabilities listed in the OWASP Top 10.
All libraries used are audit-checked with each build and are updated as needed.

Security Audits, Automated Tests, and Penetration Tests

The access controls of the application are subject to automated tests, which are run on every change and every release.
All changes to the application are subject to an extensive suite of API and integration tests and unit tests, and static analysis.
Penetration test is sought to be performed yearly by an independent 3rd party, and critical findings are addressed as soon as possible.
Customers are permitted to conduct their own penetration tests upon request - please contact help@atobi.io or your account manager.

Management and Organization

Risk assessment and business impact analysis are carried out regularly.
Information Security Awareness training ensures awareness of security risks and controls among all personnel.
Developers are required to demonstrate in-depth knowledge of security topics before employment.
All Atobi employees have anti-malware installed on their devices with automatic updating and scanning.
To protect sensitive data, Atobi employees (and any subcontractors) sign a non-disclosure agreement upon employment.
Clean desk and clear screen policies ensure conﬁdentiality at the Atobi oﬃces.
Employee workstations are required to have strong passwords, full-disk encryption, and automatic screen-lock.
Atobi's Password Policy requires that employees use strong, unique passwords for all systems used and that additional measures, such as 2-factor authentication, are applied when possible.
Information classiﬁcation policies, together with documented information and asset handling procedures, ensure conﬁdentiality, integrity, and availability of sensitive information.
All policies have identiﬁed owners and are reviewed regularly.
Access Management procedures ensure that employee access to systems is granted and revoked as changes occur, such as onboarding, termination of employment, or changes in roles within the organization.

Compliance

Atobi is GDPR compliant.
Atobi will direct law enforcement requests to the customer unless legally prohibited, so that the customer can decide whether to produce the requested information or oppose the request.