Third-party Vendors Register
Statut : draft. Registre des fournisseurs tiers (vendors) ayant accès à un actif Nex ou traitant des données pour le compte de Nex. Document attendu par les audits banque et nécessaire au respect des obligations vendor risk d'ISO 27001 (A.5.19-A.5.23) et de la réglementation EME.
1. Principes
- Tout vendor doit faire l'objet d'une fiche dans ce registre.
- Chaque vendor a un owner interne chez Nex.
- Évaluation initiale + revue annuelle minimum.
- Les contrats incluent des clauses sécurité (BCP, breach notification, droit à audit, sortie de données).
- Cas critiques → plan de bascule documenté.
2. Catégories de criticité
| Niveau | Critère | Exemples |
|---|---|---|
| Critique | Indisponibilité = service Nex indisponible OU traitement de PII Restricted | AWS, Cloudflare, Doppler, Firebase, providers Mobile Money, banque cantonnement |
| Élevé | Indisponibilité dégrade fortement le service OU accès à PII Confidential | Apentis, GitLab |
| Moyen | Impact limité ou accès à donnée Internal | Brevo, Sentry, Grafana Cloud |
| Faible | Pas d'accès à donnée sensible | Outils dev (Linear, Notion [À CONFIRMER]) |
3. Registre
3.1 AWS (Amazon Web Services)
| Aspect | Valeur |
|---|---|
| Service rendu | Hébergement compute (EKS), DB (RDS), stockage (EBS), réseau (VPC, NLB), monitoring |
| Criticité | Critique |
| Owner interne | @platform-ops |
| Région utilisée | eu-west-3 (Paris) |
| Données traitées | Toutes (PII, transactions, secrets via External Secrets) |
| Certifications | SOC 1/2/3, ISO 27001, ISO 27017/27018, PCI-DSS Level 1, HIPAA, FedRAMP |
| Contrat | AWS Customer Agreement + Service Terms |
| SLA | 99.99 % (EKS, RDS Multi-AZ) |
| Breach notification | Selon CSP responsibility split (modèle de responsabilité partagée) |
| Plan de bascule | Migration vers une autre région AWS ou un autre cloud — non testé |
| Évaluation dernier | [À CONFIRMER] |
| Prochaine revue | Annuel |
3.2 Cloudflare
| Aspect | Valeur |
|---|---|
| Service rendu | Edge / WAF / CDN / DNS / Pages (hosting doc) |
| Criticité | Critique |
| Owner interne | @platform-ops |
| Plan | Free [à upgrader Pro/Business à la croissance] |
| Données traitées | Trafic HTTP (peut contenir headers d'auth, IP utilisateurs) |
| Certifications | SOC 2 Type II, ISO 27001, PCI-DSS, FedRAMP |
| Contrat | Self-Service Subscription Agreement |
| SLA | Sur plan Pro / Business uniquement (pas sur Free) |
| Breach notification | Cf. politique de privacy Cloudflare |
| Plan de bascule | Bascule DNS vers un autre provider en cas d'incident majeur — non testé |
| Évaluation dernier | [À CONFIRMER] |
| Prochaine revue | Annuel |
3.3 Doppler
| Aspect | Valeur |
|---|---|
| Service rendu | Source de vérité des secrets (cf. ADR-0008) |
| Criticité | Critique |
| Owner interne | @platform-ops |
| Plan | [À CONFIRMER] |
| Données traitées | Secrets (clés API, mots de passe DB, Firebase service accounts) — Restricted |
| Certifications | SOC 2 Type II |
| Contrat | Terms of Service Doppler |
| Sécurité | Encryption at-rest + transit, RBAC, audit log |
| Plan de bascule | Migration vers HashiCorp Vault ou AWS Secrets Manager — non testé |
| Évaluation dernier | [À CONFIRMER] |
| Prochaine revue | Annuel |
3.4 Firebase (Google Cloud)
| Aspect | Valeur |
|---|---|
| Service rendu | Auth (custom tokens), Cloud Messaging (push), Cloud Storage (file-service) |
| Criticité | Critique |
| Owner interne | @platform-team |
| Projet Firebase | [À CONFIRMER] |
| Données traitées | Auth tokens, push tokens, fichiers KYC/KYB (PII Restricted) |
| Certifications | SOC 1/2/3, ISO 27001, ISO 27017/27018, PCI-DSS, HIPAA |
| Contrat | Google Cloud Terms of Service |
| Région stockage | [À CONFIRMER : eur3 ? us-central1 ?] — critique pour data residency |
| Plan de bascule | Auth : remplaçable par Auth0 / Cognito ; Storage : remplaçable par S3 |
| Évaluation dernier | [À CONFIRMER] |
| Prochaine revue | Annuel |
| Cf. ADR | ADR-0002 |
3.5 Apentis (KYC provider)
| Aspect | Valeur |
|---|---|
| Service rendu | Vérification KYC (OCR pièce d'identité, screening sanctions, PEP) |
| Criticité | Élevé |
| Owner interne | @kyc-team |
| Données traitées | PII Restricted (photo CNI, selfie, identité) |
| Certifications | [À CONFIRMER : SOC 2 ? ISO 27001 ?] |
| Contrat | [À CONFIRMER] |
| Région de traitement | [À CONFIRMER] |
| Plan de bascule | Remplaçable par autre provider KYC (Onfido, Veriff…) — coûts d'intégration |
| Évaluation dernier | [À CONFIRMER] |
| Prochaine revue | Annuel |
3.6 Opérateurs Mobile Money (intégrations CEMAC)
| Aspect | Valeur |
|---|---|
| Service rendu | Cash-in / cash-out / paiements via Mobile Money (Orange Money, MTN MoMo, Moov, Airtel…) |
| Criticité | Critique (chaque opérateur individuellement) |
| Owner interne | @platform-team |
| Données échangées | Identifiants utilisateur, montants, références transaction |
| Certifications | Variable selon opérateur |
| Contrat | Contrats commerciaux bilatéraux |
| SLA | Variable |
| Plan de bascule | Routage vers un autre opérateur si fail (à implémenter dans providers-gateway) |
| Évaluation dernier | [À CONFIRMER opérateur par opérateur] |
| Prochaine revue | Annuel |
| Cf. doc | /services/providers-gateway/ |
3.7 Banque(s) partenaire(s) — compte de cantonnement
| Aspect | Valeur |
|---|---|
| Service rendu | Compte de cantonnement EME ; comptes opérationnels Nex |
| Criticité | Critique |
| Owner interne | Direction Nex + compliance officer |
| Banque principale | [À CONFIRMER] |
| Données échangées | Soldes, ordres de virement, RIB / IBAN clients merchants |
| Cf. doc | /compliance/customer-funds-safeguarding |
3.8 GitLab (self-hosted + gitlab.com)
| Aspect | Valeur |
|---|---|
| Service rendu | Code source, CI/CD, container registry |
| Criticité | Élevé (le code = secret métier ; CI peut accéder à Doppler) |
| Owner interne | @platform-team |
| Instance | GitLab self-hosted (CE) sur infra Nex + miroir sur gitlab.com |
| Données traitées | Code source, runners CI, jobs logs |
| Certifications | GitLab Inc. (gitlab.com) : SOC 2 Type II, ISO 27001 |
| Plan de bascule | Bascule complète vers gitlab.com si self-hosted indisponible |
| Évaluation dernier | [À CONFIRMER] |
| Prochaine revue | Annuel |
3.9 Autres vendors (synthèse)
| Vendor | Service | Criticité | Owner | Action |
|---|---|---|---|---|
| Grafana Cloud | Monitoring logs/metrics | Élevé | @platform-ops | Fiche à compléter |
Brevo / SendGrid [À CONFIRMER] | Email transactionnel | Moyen | @platform-team | Fiche à compléter |
Tambila [À CONFIRMER] | WhatsApp copies non-prod (cf. /flows/cash-out-intent) | Moyen | @platform-team | Fiche à compléter |
| SMS provider | OTP utilisateurs | Critique | @platform-team | Fiche à compléter — provider à identifier |
Linear / Notion [À CONFIRMER] | Outils internes | Faible | divers | Fiche à compléter |
Sentry [À CONFIRMER si utilisé] | Error tracking | Moyen | dev | À évaluer |
4. Clauses contractuelles cibles
Pour tout vendor de criticité ≥ Élevé, le contrat doit inclure :
- Engagements de sécurité (certifications, mesures techniques minimales).
- Engagement de notification d'incident (délai cible ≤ 72 h pour breach de PII).
- Engagement de continuité (BCP, SLA disponibilité).
- Droit d'audit par Nex ou un tiers mandaté.
- Clause de sortie : modalités de récupération / suppression des données en fin de contrat.
- Conformité RGPD / données personnelles : DPA (Data Processing Agreement) si traitement PII.
- Localisation des données : restrictions ou exigences spécifiques.
- Sous-traitance : autorisation préalable des sous-traitants ultérieurs.
5. Procédure d'évaluation initiale (nouveau vendor)
- Cas d'usage : justifier le besoin, identifier les données échangées et la criticité.
- Due diligence : récupérer certifications (SOC 2, ISO 27001, PCI-DSS), rapports d'incident publics, références clients.
- Évaluation contractuelle : revue des clauses sécurité, RGPD, sortie de données.
- Décision :
@compliance-team+@security-team+ métier demandeur. Documentée dans cette page. - Onboarding : provisionner les accès (Doppler pour les secrets), intégrer aux runbooks IR.
6. Indicateurs
À suivre :
- Nombre de vendors par criticité.
- Délai moyen depuis dernière évaluation (objectif : ≤ 12 mois).
- Nombre d'incidents liés à un vendor par an.
- Nombre de plans de bascule testés / non testés.
7. Gaps connus
- Beaucoup de fiches à compléter (toutes marquées
[À CONFIRMER]). - Aucun plan de bascule testé en exercice.
- Région de traitement Firebase à confirmer (impact data residency).
- DPA RGPD à vérifier pour chaque vendor traitant des PII.
- Programme de revue annuelle vendor non encore formalisé.