Information Security Policy (ISP)

Statut : draft

Ce document est la politique master de sécurité de l'information de Nex. Il est référencé par les partenaires bancaires en J0 de toute due diligence. Doit être validé par la direction et le RSSI avant signature.

1. Engagement de la direction

La direction de Nex reconnaît la sécurité de l'information comme un actif critique de la plateforme. Elle s'engage à :

• Fournir les ressources nécessaires (budget, personnel, formations) pour maintenir le niveau de sécurité défini.
• Soutenir l'application des contrôles par l'ensemble des équipes.
• Réviser cette politique au minimum annuellement et après tout incident majeur.
• Faire de la sécurité un critère explicite des objectifs annuels des équipes techniques.

Signataires : [À CONFIRMER : CEO + CTO + RSSI]. Date d'effet : [À CONFIRMER]. Prochaine revue : [Date d'effet + 12 mois].

2. Portée

Cette politique couvre :

• Tous les systèmes d'information de Nex : backend (11 microservices NestJS), apps mobiles (Nex, Nex Pro, Nex Business), dashboards web (CMMS, Backoffice), infrastructure cloud (AWS EKS, RDS, S3, Cloudflare, Doppler, Firebase).
• Toutes les données traitées par la plateforme : PII utilisateurs, données KYC/KYB, transactions monétaires, secrets, logs.
• Tous les acteurs ayant un accès logique ou physique aux systèmes : employés Nex, prestataires externes (auditeurs, pentesters, QA), partenaires techniques (providers Mobile Money, banques).
• Toutes les régions opérationnelles : zone CEMAC (priorité), zone UEMOA (extension).

3. Rôles et responsabilités

Rôle	Responsabilité
Direction (CEO/CTO)	Approuver cette ISP, allouer les ressources sécurité, statuer sur les risques résiduels acceptés.
RSSI [À CONFIRMER]	Maintenir la politique, animer le programme sécurité, point d'entrée audits externes, déclarations régulateur.
Équipe sécurité	Mettre en œuvre les contrôles, opérer le SOC (ou son équivalent), conduire les revues.
Tech leads / équipe plateforme	Appliquer les contrôles dans le code, valider la sécurité avant mise en production, on-call.
Équipes dev (backend, mobile, web)	Respecter secure-sdlc et les conventions de coding-standards.
Compliance officer	Surveiller les exigences réglementaires (BEAC/COBAC, GABAC, RGPD), maintenir la doc compliance.
Chaque salarié et prestataire	Signaler tout incident ou suspicion à security@paywithnex.com [À PROVISIONNER], suivre les formations annuelles.

4. Classification des données

Quatre niveaux. Toute donnée traitée par Nex doit être classifiée explicitement (étiquette dans le data dictionary, ou inférée par convention).

Niveau	Définition	Exemples Nex
Public	Diffusable sans restriction.	Site marketing, doc publique sur le produit.
Internal	Diffusable à toute personne sous contrat Nex.	Architecture interne, runbooks, code source non sensible.
Confidential	Diffusable uniquement aux personnes dont le rôle le justifie.	Reporting financier interne, rapports d'incident, données agrégées de transactions.
Restricted	Diffusable uniquement à un cercle nominatif explicitement autorisé.	Secrets (clés API, mots de passe DB), PII non agrégée, documents KYC/KYB scannés, soldes wallet d'un utilisateur, mots de passe.

5. Principes de contrôle d'accès

• Least privilege : chaque acteur (humain, service, token) reçoit le minimum de droits nécessaires à sa fonction.
• Need-to-know : l'accès à une donnée Restricted doit être justifié et tracé.
• Separation of duties (SoD) : aucune personne ne peut à elle seule initier, valider et exécuter une opération monétaire critique. Voir maker-checker.
• MFA obligatoire pour les accès admin (dashboards Backoffice, Doppler, AWS, Cloudflare, GitLab). [ETAT ACTUEL À CONFIRMER].
• Sessions temporaires : les accès des prestataires externes sont limités dans le temps (≤ 30 jours par défaut, renouvelables).
• Cf. matrice détaillée : /security/access-control-matrix.

6. Cryptographie

• TLS 1.2 minimum partout (edge Cloudflare → backend, inter-services, API publiques).
• Hash de mots de passe et PIN serveur : bcrypt. PIN dérivé côté mobile : PBKDF2-SHA256.
• Chiffrement at-rest : encryption activée sur RDS, Firebase Storage, Doppler.
• QR codes : AES-256-GCM avec device key par appareil (cf. ADR-0013).
• Tokens auth : Firebase custom token (RS256), JWT internal-service signé (cf. ADR-0002).
• Cf. détail : /security/encryption-standards.

7. Gestion des actifs

• Inventaire des services, datastores, secrets, comptes admin tenu dans [À CONFIRMER : outil — Notion, Linear, spreadsheet sécurisé].
• Chaque actif a un owner identifié (équipe ou personne).
• Lifecycle : provisioning → usage → décommissioning. Pour tout décommissioning, suppression des secrets associés et purge des données conformément à la politique de rétention.

8. Sécurité physique

Nex est principalement cloud-native (AWS EKS, Cloudflare, Firebase, Doppler). Les contrôles physiques sont délégués aux fournisseurs (cf. leurs certifications SOC 2 / ISO 27001).

Pour les locaux propres :

• Accès bureau Nex [À CONFIRMER : localisation, mode d'accès].
• Postes de travail : disque chiffré obligatoire, session verrouillée après inactivité, MDM [À CONFIRMER].
• Pas de stockage d'information Restricted sur clé USB ou disque externe non chiffré.

9. Gestion des incidents

Tout incident de sécurité (intrusion, fuite, compromission compte, fraude détectée, indisponibilité critique) est traité selon /operations/incident-response.

• Point d'entrée : security@paywithnex.com [À PROVISIONNER] + canal Slack/Teams dédié [À CONFIRMER].
• Délais de notification régulateur (BEAC, banque partenaire) : [À CONFIRMER selon les contrats].

10. Gestion des fournisseurs (vendor risk)

Tout fournisseur tiers ayant accès à un actif Nex ou traitant des données pour le compte de Nex fait l'objet d'une fiche vendor risk :

• Évaluation des certifications du fournisseur (SOC 2, ISO 27001, PCI-DSS si applicable).
• Contrat avec clauses sécurité (BCP, breach notification, droit à audit, sortie de données).
• Revue annuelle ou en cas d'incident impliquant le fournisseur.

Vendors critiques identifiés (à documenter dans /compliance/third-party-vendors) : AWS, Cloudflare, Doppler, Firebase, providers Mobile Money, GitLab.com / self-hosted, Apentis (KYC).

11. Conformité réglementaire

Cadres applicables et visés :

• BEAC / COBAC (zone CEMAC) — agrément établissement de monnaie électronique, reporting prudentiel. [À CONFIRMER statut].
• GABAC — AML/CFT, reporting transactions suspectes (SAR).
• Loi 2010/012 Cameroun sur la cybersécurité.
• RGPD pour toute donnée concernant des résidents UE.
• OWASP ASVS 4.0 Niveau 2 (fintech) — cible technique. Voir secure-sdlc.
• OWASP MASVS — pour les apps mobiles. Voir mobile-security.
• ISO 27001:2022 — statement of applicability en gap analysis. Voir iso-27001-soa.

12. Formation et sensibilisation

• Formation sécurité obligatoire à l'onboarding pour tout nouveau salarié ou prestataire ayant accès aux systèmes.
• Refresh annuel pour l'ensemble de l'équipe.
• Sessions ciblées (phishing, mots de passe, gestion incident) au minimum 1× par an.

13. Revue et amélioration continue

• Cette politique est revue au minimum annuellement par le RSSI et approuvée par la direction.
• Toute évolution majeure de l'architecture, du périmètre réglementaire ou suite à un incident déclenche une révision exceptionnelle.
• Les contrôles sont audités selon le calendrier défini dans /governance/review-cadence.

14. Sanctions

Le non-respect de cette politique peut entraîner des mesures disciplinaires (avertissement, suspension d'accès, fin de contrat) proportionnées à la gravité, selon le règlement intérieur de Nex.

15. Historique des versions

Version	Date	Auteur	Changement
0.1	2026-05-21	@security-team	Draft initial (refonte documentaire Lot 5)