6.4
Conformité PCI DSS - Bancaire
La solution de cashback nouvelle génération
1
INTRODUCTION ET CONTEXTE
1.1 Objectif du Document
Ce document définit la stratégie de conformité de REWAPP au standard PCI DSS (Payment Card Industry Data Security Standard) et aux réglementations bancaires applicables.
Il décrit les mesures techniques et organisationnelles mises en place pour garantir la sécurité des données de paiement des utilisateurs, en conformité avec les exigences réglementaires françaises et européennes.
PRINCIPE FONDAMENTAL
REWAPP ne stocke jamais les données de carte bancaire. Toutes les données sensibles sont gérées par des partenaires certifiés PCI DSS niveau 1.
1.2 Périmètre de Conformité
Le périmètre de conformité PCI DSS de REWAPP couvre :
- Application Mobile : liaison carte bancaire via OpenBanking
- Backend API : traitement des transactions et gestion des tokens
- Dashboard Partenaire : scan QR code et gestion des paiements
- Infrastructure Cloud : hébergement AWS sécurisé
- Intégrations Tierces : connexion aux fournisseurs bancaires (Budget Insight, Plaid, Tink)
ÉLÉMENTS EXCLUS DU PÉRIMÈTRE
Délégués aux partenaires certifiés : Stockage des numéros de carte bancaire (PAN), Traitement des données CVV/CVC, Processus d'autorisation de paiement.
1.3 Rappel de l'Architecture Bancaire REWAPP
L'architecture bancaire de REWAPP repose sur le modèle OpenBanking :
Flux Architecture Bancaire
| Étape | Description | Acteur Responsable |
|---|---|---|
| 1 | Liaison Carte - L'utilisateur autorise l'accès via l'interface du partenaire bancaire | Partenaire OpenBanking |
| 2 | Tokenisation - Le partenaire génère un token sécurisé représentant la carte | Partenaire OpenBanking |
| 3 | Détection Transaction - REWAPP reçoit les notifications de transaction via webhook | REWAPP + Partenaire |
| 4 | Crédit Points - Les points sont calculés et crédités sur le compte utilisateur | REWAPP |
| 5 | Virement Cashback - Le virement est initié via API bancaire | Partenaire OpenBanking |
2
PRÉSENTATION DU STANDARD PCI DSS
2.1 Définition et Objectifs
Le standard PCI DSS (Payment Card Industry Data Security Standard) est un ensemble d'exigences de sécurité établi par le PCI Security Standards Council, fondé par les principales marques de cartes de paiement (Visa, Mastercard, American Express, Discover, JCB).
Objectifs du standard :
- Protéger les données des titulaires de cartes
- Maintenir un réseau sécurisé
- Implémenter des mesures de contrôle d'accès strictes
- Surveiller et tester régulièrement les réseaux
- Maintenir une politique de sécurité de l'information
2.2 Niveaux de Conformité
Le standard PCI DSS définit 4 niveaux de conformité basés sur le volume de transactions annuelles :
Niveaux de Conformité PCI DSS
| Niveau | Volume Transactions | Exigences d'Audit |
|---|---|---|
| Niveau 1 | > 6 millions transactions/an | Audit annuel par QSA + Scan ASV trimestriel |
| Niveau 2 | 1 à 6 millions transactions/an | SAQ annuel + Scan ASV trimestriel |
| Niveau 3 | 20 000 à 1 million transactions/an | SAQ annuel + Scan ASV trimestriel |
| Niveau 4 | < 20 000 transactions/an | SAQ annuel recommandé |
- QSA
- Qualified Security Assessor (Auditeur certifié)
- ASV
- Approved Scanning Vendor (Scanner de vulnérabilités agréé)
- SAQ
- Self-Assessment Questionnaire (Auto-évaluation)
2.3 Positionnement REWAPP
STRATÉGIE DE CONFORMITÉ
REWAPP adopte une approche de délégation de la conformité PCI DSS à ses partenaires certifiés niveau 1.
Approche REWAPP
| Aspect | Approche REWAPP | Niveau de Risque |
|---|---|---|
| Stockage données carte | Aucun stockage - Délégué au partenaire | Très faible |
| Traitement PAN | Aucun accès - Tokenisation uniquement | Très faible |
| Transmission données | Via SDK partenaire - Pas de transit REWAPP | Très faible |
| Responsabilité conformité | Partagée avec partenaire PCI DSS niveau 1 | Maîtrisé |
Cette approche permet à REWAPP de bénéficier du niveau de sécurité le plus élevé sans avoir à supporter directement les coûts et la complexité d'une certification PCI DSS niveau 1.
3
LES 12 EXIGENCES PCI DSS ET CONFORMITÉ REWAPP
3.1 Exigence 1 : Installation et Gestion d'un Pare-feu
EXIGENCE
Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de cartes.
Implémentation REWAPP
| Mesure | Technologie | Responsable |
|---|---|---|
| Pare-feu réseau | AWS Security Groups + Network ACLs |
REWAPP Ops |
| WAF (Web Application Firewall) | AWS WAF + CloudFront |
REWAPP Ops |
| Segmentation réseau | VPC avec subnets publics/privés |
REWAPP Ops |
| Règles de filtrage | Whitelist IP pour API sensibles |
REWAPP Ops |
3.2 Exigence 2 : Paramètres de Sécurité par Défaut
EXIGENCE
Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur.
- Modification obligatoire de tous les mots de passe par défaut
- Désactivation des services et protocoles non nécessaires
- Configuration sécurisée des serveurs (hardening)
-
Gestion centralisée des secrets via
Variables CapRover - Rotation automatique des credentials tous les 90 jours
3.3 Exigence 3 : Protection des Données Stockées
RÈGLE ABSOLUE
REWAPP ne stocke AUCUNE donnée de carte bancaire (PAN, CVV, date d'expiration).
Données stockées par REWAPP
| Type de Donnée | Niveau de Sensibilité | Protection |
|---|---|---|
| Token bancaire (référence) | Élevé | Chiffrement AES-256 |
| IBAN utilisateur (virement) | Élevé | Chiffrement AES-256 + Accès restreint |
| Historique transactions | Moyen | Chiffrement au repos |
| Informations utilisateur | Standard | Chiffrement au repos |
3.4 Exigence 4 : Chiffrement des Transmissions
Configuration TLS
| Communication | Protocole | Version Minimale |
|---|---|---|
| API ↔ Applications | HTTPS |
TLS 1.3 |
| API ↔ Partenaire bancaire | HTTPS + mTLS |
TLS 1.3 |
| Base de données | SSL/TLS |
TLS 1.2+ |
| Cache Redis | TLS |
TLS 1.2+ |
| Webhooks entrants | HTTPS + Signature |
TLS 1.3 |
- Cipher suites modernes uniquement (ECDHE, AES-GCM)
- Désactivation SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1
- HSTS (HTTP Strict Transport Security) activé
- Certificate pinning sur l'application mobile
3.5 Exigence 5 : Protection Anti-Malware
AWS GuardDutypour la détection de menaces- Scan automatique des images Docker (Amazon ECR)
- Analyse des dépendances (
npm audit, Snyk) - Mises à jour automatiques des patchs de sécurité
3.6 Exigence 6 : Développement et Maintenance Sécurisés
Pratiques de Développement Sécurisé
| Pratique | Outil/Méthode | Fréquence |
|---|---|---|
| Revue de code | Pull requests obligatoires | Chaque commit |
| Analyse statique (SAST) | SonarQube, ESLint security |
CI/CD |
| Analyse dynamique (DAST) | OWASP ZAP |
Hebdomadaire |
| Gestion des dépendances | Dependabot, npm audit |
Continue |
| Formation sécurité | OWASP Top 10 | Trimestrielle |
Couverture OWASP Top 10 :
- Injection SQL : ORM Prisma avec requêtes paramétrées
- Broken Authentication : JWT + 2FA + Rate limiting
- Sensitive Data Exposure : Chiffrement systématique
- XXE : Parseurs XML sécurisés
- Broken Access Control : RBAC + Tests d'autorisation
- Security Misconfiguration : IaC + Audits automatisés
- XSS : Échappement des données + CSP
- Insecure Deserialization : Validation stricte des entrées
- Components with Known Vulnerabilities : Scan continu
- Insufficient Logging : CloudWatch + Sentry + Audit trail
3.7 Exigence 7 : Restriction des Accès aux Données
Principe du moindre privilège appliqué à tous les niveaux :
Matrice des Accès par Rôle
| Rôle | Données Bancaires | Transactions | Utilisateurs |
|---|---|---|---|
| Développeur | ❌ Aucun | ❌ Logs anonymisés | ❌ Aucun |
| Support Niveau 1 | ❌ Aucun | ✅ Consultation (masqué) | ✅ Consultation partielle |
| Support Niveau 2 | ❌ Aucun | ✅ Consultation | ✅ Consultation |
| Admin | ❌ Aucun (token) | ✅ Complet | ✅ Complet |
| Super Admin | ❌ Aucun (token) | ✅ Complet + Export | ✅ Complet + Modif |
3.8 Exigence 8 : Identification et Authentification
Méthodes d'Authentification
| Composant | Méthode d'Authentification | Facteurs |
|---|---|---|
| Application Mobile | Email/Mot de passe + Biométrie | 2FA |
| Dashboard Partenaire | Email/Mot de passe + OTP | 2FA obligatoire |
| Dashboard Admin | Email/Mot de passe + OTP + IP whitelist | MFA obligatoire |
| API Backend | JWT (RS256) | Token signé |
| Accès Infrastructure | SSO + MFA + Bastion | MFA obligatoire |
Politique de mots de passe :
- Minimum 12 caractères
- Au moins 1 majuscule, 1 minuscule, 1 chiffre, 1 caractère spécial
- Historique des 12 derniers mots de passe
- Expiration tous les 90 jours (accès privilégiés)
- Verrouillage après 5 tentatives échouées
3.9 Exigence 9 : Sécurité Physique
L'infrastructure étant 100% cloud (AWS), la sécurité physique est déléguée à Amazon Web Services qui maintient les certifications suivantes :
SOC 1/2/3
Certification Audit
PCI DSS
Niveau 1
ISO 27001
Sécurité Info
CSA STAR
Cloud Security
Locaux REWAPP (bureaux) :
- Aucune donnée sensible stockée localement
- Politique de bureau propre (clean desk)
- Verrouillage automatique des postes
3.10 Exigence 10 : Surveillance et Monitoring
Configuration des Logs
| Type de Log | Outil | Rétention |
|---|---|---|
| Logs applicatifs | CloudWatch Logs |
90 jours |
| Logs d'accès | AWS CloudTrail |
1 an |
| Logs de sécurité | AWS GuardDuty |
90 jours |
| Logs d'audit | Base PostgreSQL dédiée | 3 ans |
| Alerts temps réel | CloudWatch Alarms + PagerDuty |
Immédiat |
3.11 Exigence 11 : Tests de Sécurité Réguliers
Programme de Tests
| Type de Test | Fréquence | Prestataire |
|---|---|---|
| Scan de vulnérabilités (ASV) | Trimestriel | Qualys / Tenable |
| Test d'intrusion externe | Annuel | Cabinet spécialisé |
| Test d'intrusion interne | Annuel | Cabinet spécialisé |
| Analyse de code (SAST) | Continue (CI/CD) | SonarQube |
| Test de pénétration applicatif | Semestriel | Bug bounty + Audit |
3.12 Exigence 12 : Politique de Sécurité
Documentation de sécurité :
- Politique de Sécurité de l'Information (PSI)
- Procédures de gestion des incidents
- Plan de continuité d'activité (PCA)
- Plan de reprise d'activité (PRA)
- Charte informatique signée par tous les employés
Formation et sensibilisation :
- Formation sécurité à l'embauche
- Sessions de sensibilisation trimestrielles
- Exercices de phishing simulés
- Veille sécurité continue
4
STRATÉGIE DE TOKENISATION
4.1 Principe de la Tokenisation
La tokenisation est le processus de remplacement d'une donnée sensible (numéro de carte bancaire) par un identifiant unique non sensible (token) qui n'a aucune valeur exploitable en cas de compromission.
Comparaison Donnée Originale vs Token
| Aspect | Donnée Originale | Token |
|---|---|---|
| Format | 4532 XXXX XXXX 1234 |
tk_a1b2c3d4e5f6g7h8 |
| Valeur intrinsèque | Permet des paiements | Aucune valeur seule |
| Stockage | Interdit chez REWAPP | Autorisé chez REWAPP |
| Réversibilité | N/A | Uniquement par le partenaire certifié |
4.2 Architecture de Tokenisation REWAPP
Flux de tokenisation lors de la liaison carte :
-
1
Initiation
L'utilisateur initie la liaison carte dans l'app REWAPP
-
2
Redirection
REWAPP redirige vers l'interface sécurisée du partenaire (Budget Insight/Plaid/Tink)
-
3
Authentification
L'utilisateur saisit ses identifiants bancaires directement chez le partenaire
-
4
Génération Token
Le partenaire authentifie et génère un token sécurisé
-
5
Callback
Le partenaire retourne le token à REWAPP via callback sécurisé
-
6
Stockage
REWAPP stocke uniquement le token (chiffré AES-256)
SÉCURITÉ ABSOLUE
À AUCUN MOMENT les données de carte ne transitent par les serveurs REWAPP.
4.3 Cycle de Vie des Tokens
États du Token
| État | Description | Actions Possibles |
|---|---|---|
| Actif | Token valide et utilisable | Consultation transactions, virement |
| Suspendu | Temporairement désactivé (à la demande utilisateur) | Réactivation possible |
| Expiré | Validité dépassée (renouvellement nécessaire) | Ré-authentification requise |
| Révoqué | Supprimé définitivement | Nouvelle liaison obligatoire |
Politique de renouvellement :
- Durée de validité : 90 jours (selon partenaire)
- Renouvellement automatique si l'utilisateur est actif
- Notification J-7 avant expiration
- Ré-authentification silencieuse quand possible
4.4 Avantages de l'Approche Tokenisation
- Réduction drastique du périmètre PCI DSS
- Aucune donnée de carte à protéger dans les systèmes REWAPP
- En cas de brèche, les tokens n'ont aucune valeur exploitable
- Conformité déléguée au partenaire certifié niveau 1
- Coûts de conformité réduits de 80%
- Responsabilité partagée clairement définie
5
CONFORMITÉ PSD2 ET OPENBANKING
5.1 Rappel de la Directive PSD2
La directive européenne PSD2 (Payment Services Directive 2) entrée en vigueur en 2018 impose de nouvelles exigences en matière de services de paiement :
- Ouverture des données bancaires (OpenBanking)
- Authentification forte du client (SCA)
- Sécurisation des communications (APIs)
- Protection des consommateurs
STATUT REWAPP
REWAPP n'est pas un établissement de paiement et opère en tant que TPP (Third Party Provider) via des partenaires AISP agréés.
5.2 Strong Customer Authentication (SCA)
La SCA impose une authentification à deux facteurs pour les opérations sensibles, basée sur au moins deux des trois éléments suivants :
Facteurs d'Authentification
| Facteur | Type | Exemple REWAPP |
|---|---|---|
| Connaissance | Ce que l'utilisateur sait | Mot de passe, code PIN |
| Possession | Ce que l'utilisateur possède | Smartphone, carte SIM |
| Inhérence | Ce que l'utilisateur est | Empreinte digitale, reconnaissance faciale |
Implémentation REWAPP :
- Liaison carte : Authentification via l'app bancaire de l'utilisateur (SCA déléguée)
- Demande de virement : Confirmation par OTP SMS ou push notification
- Génération QR code : Biométrie ou code PIN in-app
5.3 APIs Ouvertes et Sécurisées
Spécifications APIs conformes PSD2
| Exigence PSD2 | Implémentation |
|---|---|
| Identification TPP | Certificat eIDAS (via partenaire) |
| Chiffrement communications | TLS 1.3 obligatoire |
| Non-répudiation | Signature électronique des requêtes |
| Traçabilité | Logging complet des accès API |
| Consentement explicite | Écran de consentement granulaire |
5.4 Gestion des Consentements
Conformément à la PSD2 et au RGPD, les consentements utilisateurs sont gérés selon les principes suivants :
Types de Consentement
| Consentement | Finalité | Durée | Révocable |
|---|---|---|---|
| Accès compte bancaire | Détection transactions chez partenaires | 90 jours (renouvelable) | ✅ Oui |
| Accès historique | Récupération transactions passées | Ponctuel | N/A |
| Initiation virement | Versement cashback bancaire | Par opération | N/A |
Interface de gestion :
- Tableau de bord des consentements dans l'app
- Révocation à tout moment en 2 clics
- Historique des consentements accordés/révoqués
- Notification avant expiration
6
PARTENAIRES BANCAIRES CERTIFIÉS
6.1 Critères de Sélection
Les partenaires bancaires de REWAPP sont sélectionnés selon des critères stricts :
Critères de Sélection Partenaires
| Critère | Exigence | Vérification |
|---|---|---|
| Certification PCI DSS | Niveau 1 obligatoire | Attestation AoC annuelle |
| Agrément AISP/PISP | Agréé ACPR ou équivalent UE | Registre officiel |
| Couverture bancaire | > 95% des banques françaises | Tests d'intégration |
| SLA disponibilité | > 99.9% | Contrat + Monitoring |
| Conformité RGPD | DPA signé | Revue juridique |
| Assurance | Couverture cyber minimum 5M€ | Certificat d'assurance |
6.2 Fournisseurs Recommandés
Partenaires OpenBanking
| Fournisseur | Certification | Couverture | Statut |
|---|---|---|---|
| Budget Insight (Powens) | PCI DSS Niveau 1 + AISP agréé ACPR | > 350 banques FR/EU | ✅ Recommandé (principal) |
| Plaid | PCI DSS Niveau 1 + AISP | > 11 000 institutions | ✅ Alternative |
| Tink (Visa) | PCI DSS Niveau 1 + AISP agréé | > 3 400 banques EU | ✅ Alternative |
| Bridge (Bankin') | PCI DSS Niveau 1 + AISP agréé ACPR | > 350 banques FR | ✅ Alternative |
6.3 Répartition des Responsabilités
Matrice de Responsabilités
| Domaine | Responsabilité REWAPP | Responsabilité Partenaire |
|---|---|---|
| Stockage données carte | ❌ Aucune | ✅ Totale |
| Authentification bancaire | ❌ Aucune | ✅ Totale |
| Conformité PCI DSS | Périmètre réduit (tokens) | Périmètre complet |
| Gestion des tokens | ✅ Stockage chiffré | ✅ Génération/Validation |
| Détection transactions | ✅ Traitement métier | ✅ Collecte/Transmission |
| Virements SEPA | ✅ Initiation demande | ✅ Exécution |
| Support utilisateur | ✅ Niveau 1 | ✅ Niveau 2/3 (technique) |
7
GESTION DES INCIDENTS DE SÉCURITÉ
7.1 Procédure de Détection
Sources de Détection des Incidents
| Source | Outil | Temps de Détection |
|---|---|---|
| Anomalies applicatives | Sentry + CloudWatch |
< 1 minute |
| Anomalies réseau | AWS GuardDuty |
< 5 minutes |
| Anomalies transactions | Système anti-fraude interne | < 1 minute |
| Vulnérabilités | Scans ASV + Dependabot |
Continue |
| Signalements utilisateurs | Support + In-app | Variable |
| Signalements partenaire | Webhook alertes | < 5 minutes |
7.2 Processus d'Escalade
Niveaux de Gravité
| Niveau | Description | Exemples | Délai Réponse |
|---|---|---|---|
| Critique (P1) | Compromission données, indisponibilité totale | Brèche de données, DDoS massif | < 15 minutes |
| Majeur (P2) | Impact significatif, données à risque | Tentative intrusion, vulnérabilité critique | < 1 heure |
| Modéré (P3) | Impact limité, pas de données compromises | Anomalie suspecte, scan de ports | < 4 heures |
| Mineur (P4) | Impact négligeable | Alerte faux positif, incident isolé | < 24 heures |
Matrice d'escalade :
- P1 : Équipe Sécurité + CTO + CEO + Partenaire bancaire + CNIL (si données personnelles)
- P2 : Équipe Sécurité + CTO + Partenaire bancaire
- P3 : Équipe Sécurité + Lead Dev
- P4 : Équipe Sécurité
7.3 Communication et Notification
Obligations de Notification (RGPD + PCI DSS)
| Destinataire | Délai | Condition |
|---|---|---|
| CNIL | 72 heures | Violation données personnelles |
| Utilisateurs concernés | Sans délai | Risque élevé pour les droits |
| Partenaire bancaire | Immédiat | Incident lié aux tokens/transactions |
| Autorités sectorielles | Selon gravité | Incident systémique |
7.4 Plan de Remédiation
Étape 1 : Confinement
Isoler les systèmes compromis, révoquer les accès suspects
2
Étape 2 : Éradication
Supprimer la menace, corriger la vulnérabilité
3
Étape 3 : Récupération
Restaurer les services, valider l'intégrité des données
4
Étape 4 : Post-mortem
Analyser les causes, documenter, améliorer
Documentation obligatoire :
- Chronologie détaillée de l'incident
- Actions entreprises
- Impact évalué (utilisateurs, données, financier)
- Mesures correctives implémentées
- Plan d'amélioration
8
AUDIT ET CERTIFICATION
8.1 Programme d'Audit
Programme d'Audit Annuel
| Type d'Audit | Fréquence | Périmètre | Prestataire |
|---|---|---|---|
| Audit PCI DSS (SAQ) | Annuel | Systèmes REWAPP | Interne + QSA |
| Scan ASV | Trimestriel | Infrastructure externe | Qualys/Tenable |
| Audit sécurité applicatif | Semestriel | Applications + API | Cabinet spécialisé |
| Test d'intrusion | Annuel | Infrastructure complète | Prestataire certifié |
| Audit partenaire bancaire | Annuel | Vérification AoC | Juridique/Conformité |
| Audit RGPD | Annuel | Traitements données | DPO + Cabinet |
8.2 Documentation Requise
Documents de conformité maintenus :
- Attestation de conformité PCI DSS (AoC) du partenaire bancaire
- Rapport SAQ (Self-Assessment Questionnaire) REWAPP
- Rapports de scan ASV trimestriels
- Rapports de tests d'intrusion
- Registre des traitements (RGPD)
- Politique de sécurité de l'information
- Procédures de gestion des incidents
- Logs d'audit (conservation 3 ans)
8.3 Plan de Conformité Continue
Calendrier de Conformité
| Mois | Action | Responsable |
|---|---|---|
| Janvier | Renouvellement SAQ PCI DSS | RSSI |
| Février | Audit partenaire bancaire (vérification AoC) | Juridique |
| Mars | Scan ASV Q1 | Équipe Sécurité |
| Avril | Formation sécurité équipes | RH + RSSI |
| Mai | Test d'intrusion externe | Prestataire |
| Juin | Scan ASV Q2 | Équipe Sécurité |
| Juillet | Revue politique sécurité | RSSI + Direction |
| Août | Exercice de réponse incident | Équipe Sécurité |
| Septembre | Scan ASV Q3 | Équipe Sécurité |
| Octobre | Audit sécurité applicatif | Prestataire |
| Novembre | Revue des accès et privilèges | RSSI + IT |
| Décembre | Scan ASV Q4 + Bilan annuel | Équipe Sécurité |
9
RÉCAPITULATIF ET CONFORMITÉ
9.1 Synthèse de la Stratégie PCI DSS
Conformité PCI DSS REWAPP
| Principe | Implémentation REWAPP | Statut |
|---|---|---|
| Ne jamais stocker les données de carte | Tokenisation via partenaire certifié | ✅ Conforme |
| Chiffrement des transmissions | TLS 1.3 sur toutes les communications | ✅ Conforme |
| Chiffrement au repos | AES-256 pour données sensibles | ✅ Conforme |
| Contrôle des accès | RBAC + MFA + Principe moindre privilège | ✅ Conforme |
| Surveillance et logging | CloudWatch + GuardDuty + Audit trail | ✅ Conforme |
| Tests de sécurité | Scans ASV + Pentests + SAST/DAST | ✅ Conforme |
| Gestion des incidents | Procédures documentées + Équipe dédiée | ✅ Conforme |
| Conformité partenaire | Partenaires PCI DSS niveau 1 uniquement | ✅ Conforme |
9.2 Points de Contact
Contacts Sécurité & Conformité
| Rôle | Contact | Responsabilité |
|---|---|---|
| RSSI (Responsable Sécurité) | security@rewapp.fr |
Politique de sécurité, audits |
| DPO (Délégué Protection Données) | dpo@rewapp.fr |
Conformité RGPD, droits utilisateurs |
| Équipe Sécurité | incident@rewapp.fr |
Gestion des incidents, alertes |
| Support Conformité | compliance@rewapp.fr |
Documentation, certifications |
9.3 Engagement de Conformité
ENGAGEMENTS REWAPP
REWAPP s'engage à maintenir les plus hauts standards de sécurité pour la protection des données de ses utilisateurs.
- Maintenir la conformité PCI DSS via ses partenaires certifiés niveau 1
- Ne jamais stocker, traiter ou transmettre les données de cartes bancaires
- Chiffrer toutes les données sensibles au repos et en transit
- Effectuer des tests de sécurité réguliers
- Former continuellement ses équipes aux bonnes pratiques de sécurité
- Notifier les autorités et utilisateurs en cas d'incident conformément à la réglementation
- Maintenir une documentation de conformité à jour