Dernière mise à jour : [EFFECTIVE_DATE]

Modèle en cours de validation juridique. Ce document est un projet destiné à être vérifié et adapté par un conseil juridique qualifié dans chaque pays concerné avant toute publication. Il ne constitue pas un avis juridique.

Politique de sécurité de l'information

La présente politique décrit les mesures techniques et organisationnelles par lesquelles [LEGAL_ENTITY] protège la confidentialité, l'intégrité et la disponibilité des données traitées par [TRADING_NAME]. Elle complète la Politique de protection et de confidentialité des données.

1. Isolement des locataires

La plateforme est multi-locataire. L'isolement des données entre abonnés repose sur la sécurité au niveau des lignes (Row-Level Security) de PostgreSQL : chaque table contenant des données de locataire applique FORCE RLS et une politique tenant_isolation. En pratique, un locataire ne peut jamais lire ou modifier les données d'un autre, même en cas d'erreur applicative.

2. Authentification

L'accès repose sur une authentification par jetons JWT propres à la plateforme (jeton d'accès de courte durée + jeton de rafraîchissement). Les mots de passe ne sont jamais stockés en clair : ils sont hachés avec bcrypt.

3. Contrôle d'accès par rôle et par territoire

Les autorisations combinent deux vérifications systématiques : un privilège (droit fonctionnel) et une portée territoriale (arborescence ltree de territoires). Une action n'est permise que si l'utilisateur détient le privilège requis et que la cible relève de son territoire. Les onglets de la console sont eux-mêmes des droits délégables.

4. Registres inaltérables

Certaines données sont conçues pour ne jamais être modifiées :

les paiements et les objectifs ne peuvent être ni modifiés ni supprimés ; toute correction se fait par écriture d'annulation (contre-passation) ;
le journal d'audit (audit_log) est en ajout seul, garanti par des déclencheurs (triggers) de base de données qui empêchent toute mise à jour ou suppression.

5. Chiffrement

Les échanges sont chiffrés en transit via HTTPS/TLS. Le chiffrement au repos dépend de la configuration de l'hébergeur et du stockage d'objets ; il est appliqué selon les capacités offertes par ces prestataires et n'est pas surestimé ici.

6. Réseau et hébergement

La plateforme est hébergée sur Railway (application et base de données PostgreSQL/PostGIS). Les prestataires d'infrastructure sont listés sur la page Sous-traitants ultérieurs.

7. Cycle de développement sécurisé (SDLC)

Les évolutions sont livrées via un processus contrôlé : revue de code, tests automatisés et intégration continue avant tout déploiement. Les migrations de base de données sont additives et appliquées de manière contrôlée à la mise en service.

8. Journalisation et supervision

Chaque action utilisateur significative est journalisée dans le journal d'audit inaltérable, ce qui permet la traçabilité, la détection d'anomalies et les investigations.

9. Gestion des vulnérabilités et correctifs

Nous suivons les vulnérabilités affectant nos dépendances et notre infrastructure et appliquons les correctifs selon leur criticité. Les dépendances sont tenues à jour dans le cadre du cycle de développement.

10. Sauvegarde et restauration

Des sauvegardes régulières sont réalisées afin de permettre la restauration en cas d'incident. Les modalités et durées de conservation sont décrites dans la Politique de conservation et de suppression.

11. Attribution et retrait des accès

Les accès sont attribués selon le principe du moindre privilège et retirés sans délai au départ d'un collaborateur ou à la fin d'une prestation. Les droits sont revus périodiquement.

12. Sécurité des sous-traitants ultérieurs

Les prestataires ayant accès aux données sont sélectionnés en fonction de leurs garanties de sécurité et encadrés contractuellement. Voir la page Sous-traitants ultérieurs.

13. Réponse aux incidents

Les incidents de sécurité sont traités selon la Politique de gestion des violations de données, qui définit la détection, le confinement, l'évaluation, la notification et la remédiation.

14. Divulgation responsable

Vous pensez avoir découvert une vulnérabilité ? Signalez-la de manière responsable à [SECURITY_EMAIL]. Merci de nous laisser un délai raisonnable pour corriger avant toute divulgation publique.

Last updated: [EFFECTIVE_DATE]

Draft pending legal review. This document is a working draft to be verified and localised by qualified legal counsel in each country of operation before publication. It is not legal advice.

Information Security Policy

This policy describes the technical and organisational measures by which [LEGAL_ENTITY] protects the confidentiality, integrity and availability of the data processed by [TRADING_NAME]. It complements the Data Protection & Confidentiality Policy.

1. Tenant isolation

The platform is multi-tenant. Data isolation between subscribers relies on PostgreSQL Row-Level Security (RLS): every table holding tenant data enforces FORCE RLS and a tenant_isolation policy. In practice, one tenant can never read or modify another tenant's data, even if an application error occurs.

2. Authentication

Access relies on platform-specific JWT authentication (a short-lived access token plus a refresh token). Passwords are never stored in clear text: they are hashed with bcrypt.

3. Role- and territory-based access control

Authorisation combines two checks, always: a privilege (functional right) and a territory scope (an ltree tree of territories). An action is permitted only if the user holds the required privilege and the target falls within their territory. Console tabs are themselves delegable access rights.

4. Immutable ledgers

Certain data is designed never to change:

payments and objectives cannot be updated or deleted; any correction is made by a reversal entry;
the audit log (audit_log) is append-only, enforced by database triggers that prevent any update or deletion.

5. Encryption

Traffic is encrypted in transit via HTTPS/TLS. Encryption at rest depends on the hosting and object-store configuration; it is applied according to the capabilities those providers offer and is not overstated here.

6. Network and hosting

The platform is hosted on Railway (application and PostgreSQL/PostGIS database). Infrastructure providers are listed on the Sub-processors page.

7. Secure development lifecycle (SDLC)

Changes are shipped through a controlled process: code review, automated tests and continuous integration before any deployment. Database migrations are additive and applied in a controlled way at release.

8. Logging and monitoring

Every significant user action is written to the immutable audit log, enabling traceability, anomaly detection and investigations.

9. Vulnerability management and patching

We track vulnerabilities affecting our dependencies and infrastructure and apply patches according to severity. Dependencies are kept up to date as part of the development lifecycle.

10. Backup and recovery

Regular backups are taken to allow recovery in the event of an incident. The arrangements and retention periods are described in the Data Retention & Deletion Policy.

11. Access provisioning and deprovisioning

Access is granted on a least-privilege basis and revoked without delay when a staff member leaves or an engagement ends. Rights are reviewed periodically.

12. Sub-processor security

Providers with access to data are selected for their security assurances and bound contractually. See the Sub-processors page.

13. Incident response

Security incidents are handled under the Data Breach Response Policy, which defines detection, containment, assessment, notification and remediation.

14. Responsible disclosure

Believe you have found a vulnerability? Please disclose it responsibly to [SECURITY_EMAIL]. Kindly allow us a reasonable time to remediate before any public disclosure.