Information security policy

1. Scope and ownership

This policy covers the slygo.fr website, the Slygo app, its browser extension, its servers and the people who operate them.

• Security owner: Khaled El Ghandri, president of Kera Consulting, responsible for applying and reviewing this policy.
• Contact for any security question or report: support@slygo.fr.

2. Principles

• Data minimisation: Slygo only reads what is needed to compute net profit, in read-only mode, and never requests buyers' names, emails, phone numbers or postal addresses.
• Least privilege: each person and each component only gets the access it needs.
• Defence in depth: encryption, network isolation, database access rules and automated tests each protect the data independently.
• Transparency: merchants are informed through the privacy policy and the data processing agreement (DPA).

3. Data classification

• Confidential: access tokens of connected platforms, API keys and server secrets. Encrypted at rest by the application (AES-256-GCM) in addition to database encryption, never sent to the browser, never written to logs, kept outside the source code.
• Internal: merchants' business data (products, costs, orders, refunds, fees, ad spend). Encrypted at rest by the database provider, isolated per merchant by database access rules.
• Public: the marketing website and published documents.

Buyer personal data is excluded by design.

4. Encryption

• In transit: HTTPS (TLS 1.2 or later) for every connection, including calls to connected platforms; the server only accepts HTTPS from the outside.
• At rest: database storage encrypted by the provider (Supabase, AES-256); access tokens additionally encrypted by the application with a dedicated key stored only on the server.
• Notifications received from connected platforms (webhooks) are rejected unless their cryptographic signature is valid.

5. Infrastructure and network

• Hosting in the European Union: application server at OVHcloud (France), database at Supabase (Ireland).
• Host firewall: only HTTPS (443), HTTP (80, redirected to HTTPS) and SSH (22) are open; every other port is closed.
• Network segmentation: the application and the databases only listen on the server's internal interface and are reachable solely through the HTTPS reverse proxy; each service runs in its own isolated container.
• Administrative access to servers by SSH key only, with automatic blocking of repeated failed attempts.
• Operating system security updates are installed automatically.

6. Access control

• Production access (servers, database, cloud and platform consoles, DNS, code repository) is limited to the security owner.
• Multi-factor authentication is required on every administrative account.
• Inside the app, database access rules (row-level security) restrict every merchant to their own data; these rules are covered by automated tests run on every change.
• The server key that bypasses these rules is confined to a single server-side module, checked by an automated test, and every write is scoped to the merchant concerned.
• Access rights are reviewed every quarter and revoked as soon as they are no longer needed.

7. Day-to-day operations and devices

• Company devices use full-disk encryption, automatic screen lock, the operating system's built-in malware protection and automatic updates.
• Strong unique passwords are kept in a password manager; multi-factor authentication is enabled wherever available.
• Secrets are never shared by email or chat, and are never stored in the source code.

8. Secure development

• Every change goes through a pull request and an automated pipeline: unit tests, integration tests, database access rule tests, type checking and linting.
• The production build is rejected if it contains a secret or a local address.
• Connected platforms are accessed with read-only permissions only.

9. Vulnerability and threat management

• Server operating systems receive security updates automatically; application dependencies are reviewed at least monthly against published security advisories.
• Critical vulnerabilities are fixed or mitigated within 7 days, high ones within 30 days.
• Access tokens and keys can be revoked and rotated at any time; a compromised connection is disconnected immediately.

10. Incident response

• Roles: the security owner leads the response (assessment, containment, communication) and documents every incident.
• Reporting channel: anyone can report a suspected incident or vulnerability to support@slygo.fr.
• Process: detect and assess; contain (revoke tokens, rotate keys, disable the affected access); fix; notify; review.
• Notification: affected merchants and the platforms concerned (TikTok Shop, Shopify, Meta, Amazon) are informed without undue delay and within 48 hours of becoming aware of a personal data breach; the supervisory authority (CNIL) is notified within 72 hours where required.

11. Retention and deletion

• Merchant data is kept for as long as the account exists and deleted when the account is deleted, which merchants can do themselves from the app's settings.
• Connection tokens are erased as soon as a connection is removed or revoked by the platform.
• Technical logs of platform notifications are purged after 30 days.
• On request from a merchant or a platform, data is provided, corrected or deleted.

12. Sub-processors

• OVH SAS (OVHcloud), application hosting, France.
• Supabase Inc., database and authentication, data centre in Ireland (EU).
• Resend Inc., sign-in and notification emails.

The full list and its updates are given in the data processing agreement.