Data security

Last updated: October 18, 2026 · Version 1.2

A store entrusts Atlas L1 with its customers’ records, its sales and its employees’ work. This page describes, without general promises, the measures in place to protect them. It supplements the privacy policy.

1. Architecture and isolation

Each subscribed store has its own Atlas L1 instance: a separate PostgreSQL database, its own application containers and its own file space. One instance cannot read the data of another: there is no database common to the stores. Instances run on servers located in Québec and operated by Atlas L1.

The servers expose no port to the Internet. Traffic between the browser and the instance passes through the Cloudflare network and then through an encrypted tunnel initiated outbound from the server; there is nothing to reach directly from the outside. Atlas L1’s operations console is also placed behind a named-user access control (Cloudflare Access), even before its own authentication.

2. Encryption in transit

All pages, the application and its programming interfaces are served over HTTPS (TLS 1.2 or later). The session cookie is transmitted only over HTTPS, is not accessible to scripts and expires after 12 hours. Exchanges between the instance and the third-party services the store has connected (Google, Square, Shopify, Twilio, backup providers) are likewise carried out over TLS.

3. Encryption and hashing at rest

• Employee passwords and PIN codes are hashed with Argon2; Atlas L1 can neither read nor retrieve them.
• Integration secrets (Google refresh tokens, providers’ API keys, payment secrets, backup configuration) are encrypted with AES-256-GCM using a key specific to each instance, which never leaves that instance’s environment.
• Payment card data is never entered or stored in Atlas L1: it is processed by Stripe (subscriptions) and by Square (the store’s point-of-sale payments, if it has connected it).
• The vault of operating secrets that accompanies the backups is encrypted with a public key; the corresponding private key is kept neither on the servers nor with the backup provider.

4. Authentication and access control

• Each employee has an individual account, with a role that defines what they can see and do (administrator, manager, technician, salesperson, etc.).
• Sign-in is by password, PIN code or NFC badge, depending on what the store has configured; switching from one employee to another at the counter is logged.
• The store may restrict the hours during which its employees can sign in, with a calendar of special days; a session opened outside the permitted window is closed.
• Tablets (customer kiosk, comparison tool) are named and individually authorized by a hashed token, valid for 30 days and revocable at any time.
• Atlas L1 operators authenticate with a second factor (TOTP); sensitive actions on a store additionally require a signature by that second factor.
• A sign-in log (date, IP address, browser) and an activity log are kept in each instance and may be consulted by the store.

5. Support access

Atlas L1 support has no permanent access to instances. When an intervention is necessary (configuring an integration identifier, correcting a setting, delivering an update to a store that receives them only on request), the operations console sends a permission request to the store, which accepts or declines it from its application. Nothing is carried out until the store has confirmed. Each action is recorded in the store’s log, with the operator who performed it and the way it was signed, and the permission is revocable at any time.

No one at Atlas L1 consults a store’s data, except to resolve a problem the store has reported, with its consent, or for security reasons or legal obligation.

6. Backups and recovery

• A full backup of each instance’s database is taken every 12 hours and retained for 30 days, outside the database volume itself.
• A copy of these backups is stored off-site (Dropbox, United States), so that a disaster affecting Atlas L1’s servers does not result in the loss of the stores’ data. Each copy is encrypted before it leaves (AES-256, with a key specific to the copy, itself encrypted with an RSA-4096 public key); the private key is held offline, neither on the servers nor with Dropbox — the same mechanism as the secrets vault above.
• The store may also enable a backup to its own cloud account (Google Drive, Box, Dropbox or OneDrive). Atlas L1 places the archives in a folder that it creates and touches nothing else; dated archives beyond the retention period chosen are removed from that folder, never the photos.
• The disaster recovery procedure is documented and travels with the backups; restoration drills are carried out on a real copy.

7. Monitoring and updates

Each instance responds to a liveness probe; the operations console continuously measures availability, latency, resource usage and backup status, and flags anything outside the norm. Atlas L1 updates are first delivered to trial stores, then to stores in service; a store may request to receive an update only on its signed order.

With each build, the Atlas L1 code undergoes automated checks (strict typing, tests, consistency of routes, fields and setting keys) before it can be deployed.

8. Connected Google accounts

When a store connects its Google account, Atlas L1 receives only a token limited to the permissions the store has accepted (sending emails from its address, the account address, a backup folder that it creates in its Drive). This token is encrypted at rest, is used only by the store’s instance, and is revoked with Google and then destroyed as soon as the store clicks “Disconnect”. The details appear in section 4 of the privacy policy.

9. Reporting a vulnerability

10. In the event of an incident

Atlas L1 keeps a register of privacy incidents. An incident presenting a risk of serious injury is notified to the store concerned, to the persons affected and to the Commission d’accès à l’information du Québec, as soon as possible, together with the measures taken to limit its effects.