Sécurité des données et confidentialité lors de la mise en œuvre de l'accès au salaire déjà gagné

Pour sécuriser les données relatives à l'accès au salaire déjà gagné (EWA), l'entreprise doit savoir exactement quelles données sont collectées, à quelles fins elles sont utilisées, où elles se trouvent, qui y a accès, avec quelles parties elles sont partagées et quand elles doivent être supprimées. Les mesures clés comprennent la minimisation des données, le contrôle d'accès basé sur les rôles, l'authentification forte, le chiffrement, la gestion des clés et des secrets, les journaux infalsifiables, la surveillance des anomalies, les sauvegardes, les tests de sécurité, la gestion des fournisseurs et la procédure de réponse aux incidents. La sécurité n'est pas une fonctionnalité isolée, mais une responsabilité partagée tout au long du cycle de vie de l'EWA.

> Remarque : Il s'agit d'un cadre de référence en matière de gouvernance, de technique et d'exploitation. La détermination des obligations juridiques spécifiques dépend du rôle de chaque partie, du type de données, de l'objectif du traitement, des flux de transfert de données et du modèle de déploiement réel. Il est recommandé que les départements juridiques, de la sécurité de l'information et des ressources humaines de l'entreprise examinent conjointement ce cadre avant son application.

> Explication des termes : accès au salaire déjà gagné (EWA) · HRIS (système d'information des ressources humaines) · ERP (progiciel de gestion intégré) · paie (payroll) · API (interface de programmation d'applications) · SFTP (transfert sécurisé de fichiers) · jeton (token) · MFA (authentification multifacteur) · OTP (mot de passe à usage unique) · idempotence (protection contre les doublons de transactions) · webhook/callback (notification automatique entre systèmes) · journal (log) · SOC (centre des opérations de sécurité) · mise en service (go-live) · guide d'intervention (playbook) · normes de vérification de la sécurité des applications web/mobiles OWASP ASVS/MASVS · sauvegarde (backup).

Pourquoi les données d'accès au salaire déjà gagné doivent-elles être hautement protégées ?

L'accès au salaire déjà gagné (EWA) permet aux salariés d'accéder à une partie de leur salaire déjà gagné avant la date de paie régulière. Pour déterminer l'éligibilité d'une personne et son solde disponible, le système doit généralement connecter de nombreux domaines de données :

• informations d'identification et statut professionnel ;

• unité, poste ou groupe de paie ;

• données de pointage et statut d'approbation ;

• niveau de salaire, période de paie et divers ajustements ;

• compte de versement ou informations de paiement ;

• historique des demandes, montant, date et résultat des transactions ;

• données d'appareil, sessions de connexion et journaux de prévention de la fraude.

Lorsque ces données sont combinées, elles peuvent décrire de manière assez détaillée la relation de travail et le comportement financier d'un individu. Un incident peut non seulement entraîner une violation d'informations, mais aussi conduire à une usurpation de compte, un virement erroné, un calcul de plafond erroné, une interruption de la paie, des litiges et une baisse de la confiance des salariés (voir également les risques liés à la mise en œuvre de l'EWA).

Par conséquent, la bonne question n'est pas seulement « les données sont-elles chiffrées ? », mais plutôt : l'ensemble du processus empêche-t-il l'accès non autorisé, la corruption des données, les fausses transactions, les paiements en double et l'utilisation abusive des données ?

1. Cartographie des données avant de choisir une solution de sécurité

Une entreprise ne peut pas protéger un actif dont elle ignore l'emplacement exact. La première étape consiste à cartographier les données EWA depuis leur création jusqu'à leur suppression.

Pour chaque flux, le dossier doit répondre à :

1. Quelles données sont transmises ?

2. À quel objectif ces données servent-elles ?

3. Quel système est la source de données de référence ?

4. Quelle partie détermine l'objectif et les méthodes de traitement ?

5. Quelle partie effectue le traitement conformément à l'accord ?

6. Les données sont-elles transmises par API, fichier ou saisie manuelle ?

7. Où les données sont-elles stockées et pour combien de temps ?

8. Qui peut consulter, modifier, exporter ou supprimer ?

9. Des données sont-elles transférées à des sous-traitants ou en dehors du périmètre défini ?

10. Que se passe-t-il lorsque le salarié quitte l'entreprise ou que le contrat de service prend fin ?

Modèle de registre des données

Le modèle ci-dessus n'est qu'un cadre de conception. La durée de conservation et le niveau de classification doivent être déterminés par l'entreprise sur la base de fondements juridiques, d'exigences contractuelles, de besoins de rapprochement et d'une évaluation réelle des risques.

2. Ne collecter que les données strictement nécessaires

La minimisation des données réduit à la fois les risques et les coûts de protection. Si le système a simplement besoin de savoir qu'un employé est actif et à quel groupe il appartient, il n'est pas nécessaire de copier l'intégralité du dossier du personnel.

L'entreprise doit examiner chaque champ de données à l'aide de quatre questions :

• Sans ce champ, l'EWA peut-elle exécuter correctement son métier ?

• Peut-on remplacer les données complètes par un code de référence, un jeton ou des données masquées ?

• Est-il nécessaire de les stocker, ou suffit-il de les utiliser pendant la session de traitement ?

• Peut-on réduire le niveau de détail ou raccourcir la durée de conservation ?

Trois techniques courantes

Masquage des données : afficher uniquement une partie, par exemple les quatre derniers chiffres du compte de versement.

Tokénisation : remplacer les informations sensibles par un code de référence ; les données complètes n'existent que dans le domaine responsable du traitement.

Séparation des données : ne pas stocker les dossiers d'identification, les informations de compte et l'historique des transactions dans la même table ou sous le même accès si cela n'est pas nécessaire.

Minimiser ne signifie pas manquer de données pour le contrôle. Le système a toujours besoin de suffisamment de codes de transaction, de versions sources, d'horodatages et de journaux pour prévenir les paiements en double et faciliter les rapprochements.

3. Définir les rôles et responsabilités entre les parties

Un programme EWA peut impliquer l'entreprise utilisatrice, le fournisseur d'EWA, l'opérateur d'infrastructure, le système de pointage, la paie, la banque ou le partenaire de paiement. Si les responsabilités sont vagues, un incident sera facilement rejeté d'une partie à l'autre.

La matrice des responsabilités doit clairement définir :

Cette matrice doit être ajustée en fonction du contrat réel. Il ne faut pas considérer que « faire appel à un prestataire » revient à transférer l'intégralité de la responsabilité des données et de la sécurité de l'information.

4. Une authentification forte sans nuire à l'expérience des salariés

Le compte EWA est directement lié à la capacité de recevoir de l'argent et doit donc être protégé plus strictement qu'un compte servant uniquement à lire des actualités.

Pour les salariés

• vérification de l'identité lors de l'activation du compte ;

• utilisation d'un mécanisme d'authentification adapté au niveau de risque de la transaction ;

• exigence d'une vérification renforcée lors du changement d'appareil, de compte de versement ou en cas de comportement anormal ;

• limitation du nombre de tentatives et détection des tentatives de devinette de code ;

• interdiction de s'appuyer sur des questions de sécurité faciles à deviner ;

• notification en cas de nouvelle connexion, de modification d'informations importantes ou de transaction ;

• processus de récupération de compte sécurisé, évitant que le support ne contourne arbitrairement les étapes de vérification.

Pour les administrateurs et le personnel opérationnel

• obligation d'une authentification multifacteur ;

• priorité à la connexion centralisée et aux comptes d'identité individuels ;

• interdiction de partager les comptes administrateurs ;

• limitation des connexions par appareil, réseau ou conditions de risque le cas échéant ;

• octroi de privilèges temporaires pour les tâches spéciales ;

• enregistrement complet des actions de consultation, modification, exportation de données et modifications de configuration.

Les mots de passe, codes OTP et informations d'authentification ne doivent pas être inscrits dans les journaux. Le personnel du support ne doit pas non plus demander aux salariés de répéter leur mot de passe ou leur OTP.

5. Contrôle d'accès basé sur les rôles et principe du moindre privilège

L'accès doit être basé sur les tâches, et non simplement sur un titre hiérarchique élevé ou bas.

Les opérations à haut risque doivent appliquer la séparation des tâches ou une double approbation, par exemple :

• modifier le compte de versement ;

• déverrouiller un compte présentant des signes de fraude ;

• modifier une transaction déjà finalisée ;

• exporter des données en masse ;

• modifier les règles de plafond ;

• accorder des privilèges administratifs ;

• supprimer des journaux ou des données de transactions.

Les droits doivent être examinés régulièrement et révoqués immédiatement lorsque le personnel change de poste, quitte l'entreprise ou n'a plus de tâches associées.

6. Chiffrement des données et gestion des clés

Le chiffrement doit être appliqué aux données en transit et au repos, mais simplement « activer le chiffrement » ne suffit pas.

L'entreprise doit vérifier si :

• les connexions entre l'application, les API, le SFTP et le système de gestion sont chiffrées ;

• la base de données, les sauvegardes, l'espace de stockage de fichiers et les journaux sont protégés ;

• les clés de chiffrement sont stockées séparément des données ;

• qui a le droit d'utiliser, de renouveler ou de révoquer les clés ;

• les activités d'accès aux clés sont enregistrées ;

• la perte ou la compromission d'une clé est gérée ;

• les données exportées au format CSV/Excel restent hors de la zone protégée.

Les clés API, les mots de passe système et les certificats doivent être gérés dans un coffre-fort de secrets dédié. Ne placez pas de secrets dans le code source, les e-mails, les guides ou les fichiers de configuration largement partagés.

7. Protection des API et des flux d'intégration

Les API entre le pointage, la paie, l'EWA et le paiement constituent la voie de circulation des données et des ordres métiers (détaillé dans Intégration de l'EWA avec le pointage, la paie et l'ERP). Les contrôles importants comprennent :

• l'authentification du système appelant et le contrôle d'accès par fonction ;

• la vérification de la structure, du type et des limites des données d'entrée ;

• la limitation de la fréquence et la détection des comportements anormaux ;

• la gestion des versions d'API et un processus de modification contrôlé ;

• des signatures ou mécanismes de vérification pour les webhooks/callbacks ;

• la protection contre le rejeu de requêtes via le temps, un nonce ou une clé appropriée ;

• idempotency_key pour les ordres de création de transaction ;

• correlation_id pour le traçage trans-système ;

• une liste de codes d'erreur ne révélant pas de détails internes ;

• le contrôle des nouvelles tentatives (retry), en particulier lorsque le résultat du virement est incertain.

En cas d'utilisation de fichiers par lots (batch), il est nécessaire de contrôler un compte SFTP dédié, de chiffrer les fichiers si nécessaire, d'utiliser des sommes de contrôle (checksum), des numéros de lots, l'ordre de traitement, les enregistrements en double, les fichiers partiellement erronés et la suppression des fichiers de la zone de transit après délai.

La norme OWASP Application Security Verification Standard peut servir de cadre pour la construction et le test des contrôles de sécurité des applications web. Pour les applications mobiles, l'OWASP MASVS constitue une référence spécialisée pour les exigences d'authentification, de stockage, de réseau, de code et de confidentialité.

8. Les journaux doivent permettre l'enquête sans devenir une source de fuite

Les journaux (logs) aident à détecter la fraude, à traiter les réclamations et à retracer les incidents. Cependant, des journaux contenant trop de données sensibles créent une copie supplémentaire difficile à contrôler.

À enregistrer

• le code utilisateur ou le code administrateur contrôlé ;

• l'action et la cible affectée ;

• l'heure normalisée et le fuseau horaire ;

• l'adresse ou les indices d'appareil selon la politique ;

• le résultat (succès/échec) et le code de motif ;

• transactionid, correlationid et la version des données ;

• les modifications de privilèges, de configuration, de plafonds et de comptes de versement ;

• les actions d'exportation massives de données ;

• les événements de verrouillage de compte ou de détection d'anomalies.

À ne pas enregistrer intégralement

• les mots de passe, OTP et clés d'accès ;

• les numéros de compte ou documents d'identité complets ;

• le contenu des requêtes/réponses contenant l'intégralité des dossiers du personnel ;

• les jetons de session non révoqués ;

• les données ne servant pas aux fins de surveillance ou d'enquête.

Les journaux importants doivent être protégés contre toute modification ou suppression non autorisée, synchronisés au niveau de l'horodatage, envoyés vers un système de surveillance centralisé et assortis d'alertes basées sur des scénarios. L'OWASP souligne que la journalisation des applications doit soutenir à la fois les objectifs de sécurité et d'exploitation, mais que les données qu'elle contient doivent également être protégées.

9. Gestion des appareils, des applications et des sessions

Les salariés peuvent utiliser leur téléphone personnel, changer de carte SIM ou changer d'appareil. Par conséquent, le système doit équilibrer la sécurité et l'accessibilité.

Des règles spécifiques doivent être appliquées dans les situations suivantes :

• connexion à partir d'un nouvel appareil ;

• changement de numéro de téléphone ;

• appareil rooté/jailbreaké ou présentant des signes de manipulation ;

• plusieurs comptes utilisant anormalement le même appareil ;

• un même compte se connectant depuis plusieurs emplacements en peu de temps ;

• demande de versement immédiatement après un changement d'informations de paiement ;

• session de connexion prolongée ou réutilisation d'un jeton.

L'application ne doit pas stocker de données sensibles en clair dans la mémoire locale, le presse-papiers, les captures d'écran ou les notifications sur écran verrouillé. Les sessions de connexion doivent avoir une durée limitée, une capacité de révocation et nécessiter une réauthentification avant toute opération sensible.

10. Détecter la fraude tout en respectant la vie privée

La lutte contre la fraude peut nécessiter l'analyse des appareils, des comportements et des modèles de transactions. Néanmoins, la collecte doit être liée à un objectif clair, à la nécessité et à une durée de conservation spécifique.

Certains signaux métier peuvent inclure :

• le changement de compte de versement suivi immédiatement d'une transaction ;

• de multiples échecs d'authentification ;

• des demandes répétées au contenu similaire ;

• des transactions dépassant les règles de plafond ;

• des modifications anormales des données de pointage avant une transaction ;

• un compte assisté manuellement de manière excessive ;

• un administrateur effectuant de nombreuses modifications sensibles en dehors des heures de travail.

Il ne faut pas conclure automatiquement qu'une personne commet une fraude sur la base d'un seul signal. Le système doit disposer d'un score de risque, d'une étape de vérification supplémentaire, d'un mécanisme de traitement des exceptions et du droit d'examen par une personne habilitée. Tout modèle automatisé doit être testé pour éviter de bloquer par erreur un groupe de salariés en raison de données d'appareils, de zones géographiques ou de conditions d'utilisation différentes.

11. Sauvegarde, haute disponibilité et résilience

La sécurité englobe également la disponibilité et l'intégrité. Un système dont les données ne sont pas compromises, mais qui perd son historique de transactions ou cesse de fonctionner au moment de la paie, entraîne tout de même des conséquences majeures.

L'entreprise doit exiger :

• des sauvegardes adaptées au niveau d'importance de chaque donnée ;

• un chiffrement et des droits d'accès séparés pour les sauvegardes ;

• des copies isolées pour limiter l'impact des rançongiciels (ransomware) ;

• la vérification de la capacité de restauration, et non seulement le contrôle du « succès de la sauvegarde » ;

• des objectifs de temps de récupération (RTO) et de point de récupération (RPO) convenus par les deux parties ;

• une architecture de redondance pour les composants critiques ;

• des procédures opérationnelles de secours en cas d'interruption de l'EWA ou du canal de paiement ;

• la préservation de l'état des transactions au résultat incertain après le rétablissement du système.

Les objectifs temporels ne doivent pas être promus par des chiffres en l'absence de mesures et d'engagements de service officiels.

12. Gestion des fournisseurs et de la chaîne d'approvisionnement

Le fournisseur d'EWA peut continuer à utiliser une infrastructure cloud, des services d'envoi d'OTP, de surveillance, de vérification d'identité ou des partenaires de paiement. L'entreprise doit savoir quelles parties traitent les données et quelles sont les responsabilités de chacune.

Questions à se poser avant de signer le contrat

(Voir également l'ensemble des critères dans la Liste de contrôle pour le choix d'un fournisseur d'EWA.)

1. Quels groupes de données précis le fournisseur traite-t-il ?

2. Où les données et les sauvegardes sont-elles stockées ?

3. Des sous-traitants ont-ils accès aux données ?

4. Existe-t-il un mécanisme de notification préalable en cas de changement de sous-traitant ?

5. Selon quelle procédure les employés du fournisseur accèdent-ils aux données ?

6. Existe-t-il un chiffrement, une gestion des clés, une MFA et une séparation des environnements ?

7. Avec quel périmètre et quelle périodicité les tests d'intrusion sont-ils effectués ?

8. Comment les vulnérabilités sont-elles classées et corrigées ?

9. Quel est le délai de notification des incidents et quel est le point de contact pour la coordination ?

10. À la fin du contrat, comment les données et les copies sont-elles restituées ou supprimées ?

11. Quelles preuves attestent de la suppression complète ?

12. Quels sont les droits de l'entreprise en matière d'inspection, d'évaluation ou de réception de rapports indépendants ?

Une certification est un signal utile mais ne remplace pas la vérification du bon périmètre. L'entreprise doit examiner quels systèmes, sites et périodes sont couverts par la certification, et si celle-ci inclut la plateforme EWA utilisée.

13. Tests de sécurité avant et après la mise en service (go-live)

Un test unique avant le lancement ne suffit pas pour l'ensemble du cycle de vie du produit (lié au plan pilote EWA de 90 jours). Un programme adéquat peut comprendre :

• l'examen de l'architecture et de la modélisation des menaces ;

• la vérification du code source et des bibliothèques dépendantes ;

• l'analyse des vulnérabilités des applications, des serveurs et des configurations ;

• les tests d'API, du web et des applications mobiles ;

• les tests de contrôle d'accès par rôle ;

• les tests de la procédure de récupération de compte ;

• les tests contre les transactions répétées et les faux callbacks ;

• les tests d'intrusion indépendants avant le go-live et après des modifications majeures ;

• des exercices de réponse aux incidents et de restauration ;

• le suivi des corrections jusqu'à l'obtention de la preuve de fermeture des failles.

Les résultats des tests doivent distinguer clairement les failles graves, les failles acceptables temporairement et les risques résiduels approuvés par une personne habilitée. Il ne faut pas mettre le système en exploitation simplement parce qu'« aucune faille grave n'a été trouvée » si le périmètre des tests n'inclut pas le flux de paiement et l'intégration réelle.

14. Procédure de réponse aux incidents de données EWA

Lors de la détection de signes anormaux, le premier objectif est de limiter les dommages sans détruire les preuves.

Le guide d'intervention (playbook) doit définir :

• ce qui constitue un incident et son niveau de gravedad ;

• qui a le droit de verrouiller un compte, d'arrêter une API ou de suspendre temporairement les paiements ;

• la manière de préserver les journaux, les instantanés système et les preuves de transaction ;

• la manière d'identifier les données, les utilisateurs et la période affectés ;

• les points de contact juridiques, RH, de communication, de sécurité et les fournisseurs ;

• les motifs, le contenu et le moment de la notification aux autorités compétentes ou aux personnes concernées ;

• les critères de réouverture du service ;

• les plans d'aide aux salariés en cas de transaction erronée ;

• le rapport sur la cause racine et les actions visant à empêcher la récurrence.

Les délais de notification légaux doivent être déterminés par l'équipe juridique en fonction du type d'incident et du rôle spécifique de chaque partie, sans appliquer un chiffre unique à toutes les situations.

15. Cycle de vie des données : de la création à la suppression sécurisée

Chaque groupe de données nécessite un calendrier de conservation distinct. « Conserver indéfiniment pour consultation en cas de besoin » augmente généralement les risques sans apporter de valeur supplémentaire.

La politique doit couvrir :

• les données utilisées dans le système principal ;

• les sauvegardes ;

• les fichiers de transit ;

• les données exportées sur les postes utilisateurs ;

• les journaux d'application et de sécurité ;

• les données de test ;

• les données chez les sous-traitants ;

• les tickets de support et pièces jointes ;

• les données des anciens salariés ;

• les données après la fin du contrat de service.

La suppression sécurisée nécessite un ordre de suppression, un journal d'exécution, le traitement des copies et la preuve de l'achèvement. Dans certains cas, les données doivent continuer à être conservées en raison d'obligations légales, de règlements de litiges ou d'exigences d'audit ; dans ce cas, l'accès doit être restreint et l'objectif d'utilisation limité.

16. Cadre juridique vietnamien à prendre en compte

À la date de rédaction de cet article, la loi sur la protection des données personnelles n° 91/2025/QH15 a été promulguée le 26 juin 2025 et est entrée en vigueur le 1er janvier 2026. Le décret n° 356/2025/NĐ-CP, promulgué le 31 décembre 2025 et entré en vigueur le 1er janvier 2026, stipule en détail certains articles et mesures d'application de la loi.

En outre, selon les flux métiers, l'entreprise doit examiner la loi sur les transactions électroniques n° 20/2023/QH15, entrée en vigueur le 1er juillet 2024 ; le décret n° 52/2024/NĐ-CP sur le paiement sans numéraire et les réglementations sectorielles connexes.

La conformité ne doit pas être perçue simplement comme l'ajout d'une case « J'accepte ». L'entreprise doit déterminer correctement le rôle des parties, l'objectif et le fondement du traitement, les informations fournies aux salariés, le périmètre de partage, la garantie des droits des personnes concernées, les dossiers d'évaluation nécessaires, les mesures de protection et la procédure de traitement des incidents. Les conclusions juridiques spécifiques doivent être basées sur le schéma des données et le contrat de déploiement réel.

17. Liste de contrôle de sécurité avant l'approbation du déploiement de l'EWA

Gouvernance et juridique

• [ ] Il existe un propriétaire du programme EWA et un point de contact pour la sécurité de l'information.

• [ ] Il existe une cartographie des données et une liste des systèmes/fournisseurs recevant des données.

• [ ] Les rôles, les objectifs et les responsabilités de traitement des parties ont été définis.

• [ ] Les avis, les conditions et le mécanisme d'exercice des droits des salariés ont été examinés.

• [ ] Il existe une durée de conservation et une procédure de suppression pour chaque groupe de données.

• [ ] Le contrat réglemente les incidents, les sous-traitants, l'inspection et la fin du service.

Identité et contrôle d'accès

• [ ] Les salariés sont vérifiés lors de l'activation et lors de la modification d'informations sensibles.

• [ ] Les administrateurs doivent utiliser la MFA et des comptes individuels.

• [ ] Les droits sont attribués en fonction du rôle, du périmètre organisationnel et des tâches.

• [ ] Les opérations à haut risque disposent d'une double approbation ou d'une séparation des tâches.

• [ ] Les droits sont révisés périodiquement et révoqués en cas de changement de poste ou de départ.

Données et intégration

• [ ] Transférer uniquement les champs strictement nécessaires.

• [ ] Les données sensibles sont tokénisées ou masquées dans la mesure du possible.

• [ ] La connexion et les données stockées sont chiffrées.

• [ ] Les clés et les secrets sont gérés séparément du code source.

• [ ] Les API/webhooks disposent d'une authentification, d'une protection anti-rejeu et de limites de charge.

• [ ] Les transactions disposent de l'idempotence et d'une capacité de traçage trans-système.

Applications et exploitation

• [ ] Le web, les API et l'application mobile ont été testés en matière de sécurité sur le bon périmètre.

• [ ] Les journaux enregistrent suffisamment d'événements sans contenir de secrets/données sensibles complets.

• [ ] Il existe une surveillance, des alertes et des destinataires d'alertes clairement définis.

• [ ] Les sauvegardes sont protégées et restaurées avec succès lors de tests.

• [ ] Il existe un guide d'intervention (playbook) pour l'usurpation de compte, la fuite de données et les virements erronés.

• [ ] Il existe un plan de continuité des activités en cas d'interruption de la plateforme ou des paiements.

Go-live et post-déploiement

• [ ] Toutes les failles graves ont été corrigées et vérifiées à nouveau.

• [ ] Les risques résiduels ont été acceptés par une personne habilitée par écrit.

• [ ] La liste des contacts d'urgence entre les parties a été testée.

• [ ] Les salariés connaissent le canal pour signaler la perte d'un compte ou une transaction anormale.

• [ ] Il existe un calendrier de révision des droits, des vulnérabilités, des fournisseurs et de l'efficacité des alertes.

• [ ] Il existe des preuves de vérification après des modifications majeures.

Conclusion

La sécurité des données EWA commence par la compréhension des flux de données et des responsabilités, et non par une liste de technologies. Un programme digne de confiance doit limiter la collecte de données, authentifier la bonne personne, octroyer les bons droits, protéger les API et les transactions, consigner suffisamment de journaux, contrôler les fournisseurs, restaurer en cas d'interruption et traiter les incidents de manière transparente.

Si votre entreprise évalue une solution de Lương Ngày, préparez votre cartographie des systèmes, les groupes de données prévus pour l'intégration et votre liste de contrôle interne, puis consultez Lương Ngày pour les entreprises pour demander le dossier de sécurité, la documentation d'intégration et le périmètre d'évaluation technique avant d'implémenter le projet pilote.

Sources de référence

• Loi sur la protection des données personnelles n° 91/2025/QH15

• Décret n° 356/2025/NĐ-CP portant application de la loi sur la protection des données personnelles

• Loi sur les transactions électroniques n° 20/2023/QH15

• Décret n° 52/2024/NĐ-CP relatif au paiement sans numéraire

• Norme de vérification de la sécurité des applications web OWASP

• Norme de vérification de la sécurité des applications mobiles OWASP

• Fiche mémo sur la journalisation OWASP

---

Auteur : Nguyen Tan Loc — Chargé de mission stratégie, Nhan Kiet Manpower Supply Co., Ltd.

Conseil en solution Lương Ngày pour les entreprises : Hotline 0937.022.655 · Email info@nhankiet.vn · Lương Ngày pour les entreprises