Gouvernance des risques et prévention de la fraude dans l'accès au salaire déjà gagné (EWA)

Pour maîtriser le risque de fraude lié à l'accès au salaire déjà gagné (EWA), l'entreprise doit contrôler l'ensemble de la chaîne : de la vérification de l'identité du salarié, des heures validées et des plafonds, jusqu'au compte bénéficiaire, à l'ordre de paiement et au rapprochement. Trois couches sont essentielles : la prévention, par la répartition des droits et des règles de transaction ; la détection, par les données, les alertes et le rapprochement ; la réaction, par un blocage maîtrisé, une enquête, un remboursement et une correction de la cause racine. Il ne faut considérer aucune anomalie comme une fraude par principe, ni relancer automatiquement un paiement lorsque le résultat de la transaction reste incertain.

> Remarque : Cet article propose un cadre de gouvernance et des repères techniques. Les seuils d'alerte, les plafonds, les délais de blocage, les procédures d'enquête et les responsabilités de chaque partie doivent être validés par l'entreprise, le fournisseur d'accès au salaire déjà gagné, le partenaire de paiement, le service juridique et la sécurité de l'information, selon le modèle de déploiement réel.

> Glossaire : EWA (accès au salaire déjà gagné en fonction des jours travaillés) · HRIS (système d'information des ressources humaines) · payroll (paie) · ERP (planification des ressources de l'entreprise) · MFA (authentification multifacteur) · risk-based auth (authentification adaptée au niveau de risque) · idempotency (prévention des transactions dupliquées) · callback/webhook (notification automatique entre systèmes) · timeout (dépassement du délai d'attente) · false positive (blocage ou alerte erronée) · social engineering (ingénierie sociale / fraude non technique) · go-live (mise en production officielle) · NIST CSF / OWASP ASVS (cadres et normes de sécurité de l'information).

En quoi le risque de l'EWA diffère-t-il du risque d'un prêt ?

L'accès au salaire déjà gagné (EWA – Earned Wage Access) est conçu pour permettre au salarié d'accéder à une partie du salaire qu'il a déjà gagné. Le risque essentiel ne réside donc pas seulement dans l'éventualité d'un « défaut de remboursement », mais dans le fait que le système identifie mal la personne, les heures travaillées, le plafond, le compte bénéficiaire ou le statut du paiement.

Par exemple :

• le compte du salarié est piraté et le numéro de compte bénéficiaire est modifié ;

• des données de pointage non validées sont malgré tout intégrées dans le calcul du plafond ;

• une demande est renvoyée après un timeout et génère un double paiement ;

• un salarié a quitté l'entreprise mais son statut n'a pas été mis à jour dans le HRIS ;

• une même personne dispose à la fois du droit de modifier les heures travaillées et du droit d'approuver les transactions ;

• une transaction réussit auprès de la banque mais n'est pas encore enregistrée dans la paie ;

• un salarié légitime est bloqué à tort en raison d'un modèle d'alerte trop sensible.

La gouvernance des risques de l'EWA doit ainsi protéger simultanément quatre propriétés :

1. La bonne personne : l'auteur de la transaction est bien le titulaire légitime du compte.

2. Le bon montant : la somme est calculée à partir de données approuvées et de la politique en vigueur.

3. Le bon bénéficiaire : l'argent est transféré vers un compte vérifié.

4. Une seule fois : chaque demande valide ne génère qu'un seul résultat de paiement, entièrement rapproché.

1. Distinguer erreur, abus et fraude

Tout écart ne constitue pas nécessairement une fraude. Si l'équipe opérationnelle conclut trop hâtivement, l'entreprise risque de sanctionner injustement un salarié ou de passer à côté d'une erreur système qu'il faudrait corriger.

Un bon système doit d'abord qualifier l'événement d'anomalie à vérifier, avant de disposer de preuves suffisantes pour conclure à une fraude.

2. Cartographie des risques selon le cycle de vie de la transaction EWA

flowchart TD
    A["Identification et activation"] --> B["Réception des données de temps et de salaire"]
    B --> C["Calcul du plafond"]
    C --> D["Création de la demande"]
    D --> E["Transfert des fonds"]
    E --> F["Rapprochement et règlement"]
    F --> G["Suivi, réclamations, remboursement"]

Chaque étape comporte son propre groupe de risques :

3. Construire un registre des risques EWA

Le registre des risques transforme des préoccupations générales en responsabilités et actions concrètes. Chaque risque doit comporter :

• un code et une description du scénario ;

• l'actif ou le processus concerné ;

• la cause et les conditions déclenchantes ;

• la probabilité et le niveau d'impact ;

• les contrôles de prévention, de détection et de correction ;

• les données ou indicateurs de suivi ;

• le propriétaire du risque ;

• le risque résiduel après contrôle ;

• la personne habilitée à accepter le risque résiduel ;

• la date du prochain examen.

Modèle de matrice des risques

Il ne faut pas recopier les niveaux de probabilité d'une autre entreprise. Le score doit reposer sur la taille de l'effectif, la fréquence des transactions, le degré d'automatisation, la qualité des données et l'historique d'incidents propre au programme.

4. Contrôle de l'identité et prévention de la prise de contrôle de compte

Un fraudeur n'a généralement pas besoin de contourner l'algorithme de calcul du plafond s'il peut s'emparer d'un compte légitime. Les points de risque les plus élevés se situent habituellement au niveau de l'activation, de la récupération de compte, du changement de numéro de téléphone, du changement d'appareil et du changement de compte bénéficiaire.

Contrôles à l'activation

• vérifier le matricule salarié par rapport à la source HRIS approuvée ;

• vérifier que le canal de contact appartient bien au salarié ;

• ne pas s'appuyer sur des informations faciles à deviner, comme la date de naissance ou le matricule ;

• limiter le nombre de tentatives et détecter plusieurs comptes provenant du même appareil ;

• notifier l'activation via le canal enregistré ;

• conserver la preuve de la version des conditions et de la date d'acceptation.

Contrôles à la connexion et à la transaction

• une authentification adaptée au niveau de risque ;

• une réauthentification avant toute transaction ou modification sensible ;

• la détection d'un nouvel appareil, d'une session anormale ou de tentatives d'échec répétées ;

• l'invalidation des anciennes sessions après un changement de mot de passe ou un signalement de perte d'appareil ;

• une notification immédiate en cas de nouvelle connexion ou de création de transaction ;

• la possibilité pour l'utilisateur de signaler « ce n'est pas moi » via un canal facilement accessible.

La récupération de compte doit être aussi robuste que la connexion

Si un agent du support peut récupérer un compte à l'aide de quelques questions faciles à deviner, tous les contrôles de connexion en amont peuvent être neutralisés. La procédure de récupération doit exiger plusieurs éléments de preuve, limiter les droits de l'agent du support, être intégralement journalisée et faire l'objet d'une approbation supplémentaire dans les cas à risque élevé.

5. Contrôle du changement de compte bénéficiaire

Le changement de bénéficiaire est l'opération susceptible de transformer un compte piraté en préjudice financier réel.

Contrôles recommandés :

1. réauthentifier l'utilisateur ;

2. vérifier le nouveau compte selon une méthode approuvée ;

3. notifier le changement via l'ancien et le nouveau canal, le cas échéant ;

4. appliquer un délai d'attente ou des limites renforcées selon le risque ;

5. bloquer la transaction si le changement s'accompagne d'un nouvel appareil ou d'un autre signal anormal ;

6. ne pas laisser un même agent du support à la fois modifier et approuver ;

7. conserver l'historique de l'ancienne valeur masquée, de la nouvelle valeur masquée, de l'auteur et du motif ;

8. placer la transaction suivant immédiatement le changement dans un flux de surveillance dédié.

Il ne faut pas publier de seuils ou de délais précis dans un article public si cette information peut aider un fraudeur à ajuster son comportement pour contourner les contrôles.

6. Garantir la fiabilité des données de temps et du statut d'emploi

Le plafond de l'EWA dépend directement des données source. Le contrôle antifraude doit commencer avant même que les données n'entrent dans la plateforme (voir Que sont les heures validées ? et Intégrer l'EWA au pointage, à la paie et à l'ERP).

Pour les données des salariés

• utiliser un matricule salarié unique, jamais réutilisé ;

• mettre à jour les dates d'effet des embauches, congés et départs ;

• vérifier les incohérences entre le HRIS, la paie et l'EWA ;

• suspendre le droit de transaction lorsque le statut n'est pas clair ;

• vérifier les comptes EWA encore actifs de salariés ayant quitté l'entreprise.

Pour les données de pointage

• ne prendre en compte que le statut approuvé par l'entreprise ;

• conserver l'identité de l'approbateur, la date d'approbation et la version de l'enregistrement ;

• alerter en cas d'ajout ou de modification d'heures après la clôture ;

• détecter des heures impossibles, des postes qui se chevauchent ou des pics soudains ;

• séparer la personne qui modifie les heures de celle qui approuve les exceptions ;

• recalculer le plafond lorsque les données source sont ajustées.

Pour les règles de salaire et de plafond

• gérer les versions des formules ;

• tester avant la mise en application ;

• exiger une double approbation pour les changements importants ;

• conserver intégralement les valeurs avant et après ;

• ne pas modifier directement les données de production pour un « traitement rapide » ;

• être capable de reconstituer le calcul à partir des données source et de la version de la politique.

7. Prévenir les transactions dupliquées grâce à l'idempotency

Situation typique : la plateforme envoie un ordre de paiement mais ne reçoit pas de réponse en raison d'un timeout. Si le système considère cela comme un échec et envoie un nouvel ordre, le salarié peut recevoir un double versement.

L'idempotency garantit que plusieurs renvois d'une même demande ne produisent qu'un seul résultat métier. Une conception adaptée nécessite :

• une idempotency_key unique, générée par l'appelant ;

• une contrainte d'unicité dans la base de données ;

• un lien entre la clé, l'utilisateur, le type de transaction et le contenu de la demande ;

• une durée de conservation de la clé couvrant l'ensemble du cycle de traitement ;

• le renvoi du transaction_id et du statut précédent en cas de nouvelle soumission de la demande ;

• l'interdiction d'associer une même clé à un montant ou un bénéficiaire différent ;

• la conservation de la clé lors des nouvelles tentatives via une file d'attente ou après une reprise du système.

L'idempotency ne remplace pas le rapprochement. Elle empêche la création de doublons au moment du traitement ; le rapprochement, lui, détecte les écarts déjà survenus entre l'EWA, le partenaire de paiement et la paie/l'ERP.

8. Gérer les transactions dont le résultat est incertain

Une transaction de paiement ne se limite pas aux statuts « réussie » et « échouée ». Il faut un statut intermédiaire pour les cas où l'ordre a été envoyé mais où le résultat final reste inconnu.

stateDiagram-v2
    [*] --> Created
    Created --> Validating
    Validating --> Processing
    Processing --> Succeeded
    Processing --> Failed
    Processing --> Unknown
    Unknown --> Succeeded
    Unknown --> Failed
    Succeeded --> Reconciled
    Succeeded --> Reversed

Lorsque le statut est UNKNOWN (ou équivalent) :

• suspendre la part du plafond concernée ;

• ne pas générer automatiquement un nouvel ordre de paiement ;

• interroger le statut à l'aide de la référence existante ;

• alerter l'équipe opérationnelle en cas de dépassement du délai interne ;

• rapprocher avec le rapport ou le relevé du partenaire ;

• consigner la personne et la justification lors d'un traitement manuel ;

• ne restituer le plafond qu'après avoir confirmé que les fonds n'ont pas été transférés, ou qu'ils ont été remboursés.

9. Combiner les signaux d'alerte de fraude

Un signal isolé suffit rarement à conclure. Par exemple, un changement de téléphone par un salarié peut être parfaitement légitime. Le risque augmente lorsque plusieurs signaux apparaissent simultanément.

Signaux liés au compte et à l'appareil

• connexion depuis un nouvel appareil suivie d'un changement de compte bénéficiaire ;

• un nombre de comptes sur un même appareil dépassant le niveau habituel ;

• des échecs d'authentification répétés ;

• des informations d'appareil changeant de façon anormale ;

• des connexions depuis des lieux éloignés dans un intervalle de temps incohérent ;

• une demande de récupération suivie immédiatement d'une transaction.

Signaux liés aux heures et au plafond

• une forte hausse des heures par rapport à l'historique ou au planning ;

• des ajustements d'heures en masse juste avant la création d'une transaction ;

• de nombreux enregistrements approuvés par une même personne en dehors des heures normales ;

• une variation importante du plafond sans événement de paie correspondant ;

• des données provenant d'une ancienne version qui écrasent des données plus récentes ;

• un plafond qui continue de se générer pour un salarié ayant quitté l'entreprise.

Signaux liés aux transactions

• de nombreuses demandes rapprochées dans le temps ;

• des transactions répétées proches du plafond ;

• un changement de bénéficiaire suivi d'une demande de montant élevé ;

• plusieurs salariés transférant vers un même compte ;

• des transactions échouant de façon répétée vers plusieurs comptes bénéficiaires ;

• une même référence de paiement apparaissant dans plusieurs transactions ;

• une transaction sortant du schéma de comportement habituel du compte.

Signaux liés au personnel interne

• l'attribution de droits suivie d'une transaction anormale ;

• une même personne qui modifie les données, approuve et traite les exceptions ;

• des exports de données en masse sans justification professionnelle ;

• de nombreuses opérations d'administration en dehors des heures normales ;

• des alertes ignorées ou des motifs d'exception identiques enregistrés en masse ;

• des interventions sur des comptes liés par un appareil, un compte bénéficiaire ou une unité commune.

Les seuils précis doivent être conservés dans une documentation opérationnelle interne, à accès restreint.

10. Le modèle de scoring des risques ne doit pas devenir une « boîte noire »

Le score de risque peut aider à décider d'autoriser, d'exiger une vérification supplémentaire, de suspendre ou de transférer vers un contrôle manuel. L'entreprise doit néanmoins savoir sur quels signaux le modèle repose et comment ses erreurs sont maîtrisées.

Exemple de processus de décision :

Il faut suivre au minimum :

• le taux d'alertes exactes ;

• le taux d'utilisateurs légitimes bloqués à tort ;

• le temps de traitement des alertes ;

• le montant du préjudice évité ;

• le nombre d'alertes ignorées ;

• le nombre de transactions frauduleuses non détectées ;

• l'impact par groupe de salariés, par unité ou par appareil.

En cas d'utilisation d'un modèle d'apprentissage automatique, tout changement du modèle ou de la source de données doit être testé, approuvé, suivi pour détecter une dérive du modèle, et rester suffisamment explicable pour l'équipe d'enquête. Dans une phase initiale, un ensemble de règles claires associé à un bon rapprochement est souvent plus facile à maîtriser qu'un modèle complexe mais reposant sur des données non stabilisées.

11. Contrôle de la fraude interne

Une personne interne connaît les processus et peut détenir des droits légitimes (voir sécurité des données et vie privée dans le déploiement de l'EWA). Le contrôle de la connexion seul est donc insuffisant.

Principes clés :

• séparer la personne qui crée, celle qui approuve et celle qui rapproche ;

• ne pas partager de comptes administrateurs ;

• attribuer les droits selon l'entité juridique, l'unité et la fonction ;

• limiter dans le temps les droits spéciaux et exiger une justification ;

• exiger une double approbation pour les opérations sensibles ;

• conserver un journal inviolable des modifications de données et de configuration ;

• alerter en cas d'export de données en masse ;

• revoir les droits périodiquement et les révoquer immédiatement en cas de changement de poste ;

• prévoir une rotation ou un congé obligatoire pour les postes sensibles, si la politique le permet ;

• disposer d'un canal de signalement et d'un mécanisme d'enquête indépendant.

L'équipe d'enquête ne doit pas inclure le supérieur direct ni une personne en conflit d'intérêts avec la personne concernée.

12. Le rapprochement multidimensionnel pour détecter les pertes

Le rapprochement doit porter sur au moins trois sources (voir le processus de l'accès au salaire déjà gagné, du pointage au rapprochement) :

1. le registre des transactions de la plateforme EWA ;

2. les résultats de la banque ou du partenaire de paiement ;

3. les dossiers de paie/ERP ou de règlement approuvés.

Selon la conception, il est possible de rapprocher également les données de temps, le plafond et le grand livre comptable.

Les écarts à isoler

• l'EWA signale un succès mais le partenaire ne l'a pas confirmé ;

• le partenaire signale un succès mais l'EWA ne comporte aucune transaction correspondante ;

• le montant, les frais ou le bénéficiaire ne correspondent pas ;

• une transaction est remboursée mais le plafond n'a pas été mis à jour ;

• une transaction réussie est absente de la paie/l'ERP ;

• une même référence de paiement est associée à plusieurs transactions ;

• une transaction apparaît deux fois dans le fichier de rapprochement ;

• les données de temps sont ajustées après la génération de la transaction.

Chaque écart doit disposer d'un code de dossier, d'un responsable, d'un niveau de priorité, de preuves, d'un délai interne et d'un résultat final. Il ne faut pas supprimer un enregistrement d'écart au seul motif que les chiffres ont été corrigés.

13. Processus de traitement des alertes et d'enquête

flowchart TD
    A["Création de l'alerte"] --> B["Tri et priorisation"]
    B --> C["Protection du compte et de la transaction"]
    C --> D["Collecte des preuves"]
    D --> E["Conclusion et traitement"]
    E --> F["Correction de la cause"]
    F --> G["Mesure de l'efficacité et mise à jour des règles"]

Étape 1 : Tri

Vérifier si l'alerte dispose de données complètes, quel est le statut actuel de la transaction, et si le préjudice risque de se poursuivre.

Étape 2 : Limiter le préjudice

Selon l'autorité compétente, il est possible de révoquer la session, de bloquer temporairement le compte, de suspendre une transaction non encore versée, d'annuler un changement de compte bénéficiaire ou d'arrêter un flux d'intégration. La mesure doit être proportionnée et réversible si l'alerte s'avère erronée.

Étape 3 : Préserver les preuves

Consigner les journaux, les versions de données, la configuration, le code de transaction, la référence de paiement, l'historique des modifications et les échanges avec le support. Ne jamais modifier directement la preuve d'origine.

Étape 4 : Analyser la cause

Distinguer la prise de contrôle de compte, la fraude interne, l'erreur de données, l'erreur système et l'abus de politique. Examiner à la fois les causes techniques et les failles de processus.

Étape 5 : Traiter et notifier

Agir conformément au contrat, aux règles internes et aux exigences légales. Ne pas conclure publiquement ni prendre de mesure disciplinaire tant que la procédure de vérification appropriée n'est pas achevée.

Étape 6 : Prévenir la récidive

Corriger les règles, les droits d'accès, le code source, les processus, les supports de formation, et suivre l'efficacité après le changement.

14. Protéger le salarié en cas de fausse alerte du système

La lutte contre la fraude ne doit pas se transformer en obstacle empêchant un salarié légitime d'accéder à ses droits en temps voulu.

L'entreprise doit disposer de :

• une notification claire indiquant que la transaction est en cours de vérification, sans l'étiqueter « fraude » avant toute conclusion ;

• un canal de réclamation facile d'accès ;

• un code de dossier et un statut de traitement ;

• un délai interne fonction du niveau d'impact ;

• un mécanisme de déblocage ou de restauration rapide une fois la légitimité vérifiée ;

• une personne habilitée à examiner les exceptions ;

• une mesure du taux de blocage erroné pour chaque règle ;

• un examen visant à vérifier qu'aucune règle ne pénalise indûment un groupe d'utilisateurs particulier.

L'équipe de support ne doit pas avoir accès à plus de données que nécessaire. Les informations d'enquête doivent faire l'objet d'une gestion des droits distincte, afin de protéger la vie privée et d'éviter de divulguer les règles antifraude.

15. Les indicateurs de gouvernance des risques à suivre

Les indicateurs doivent reposer sur des définitions cohérentes. La « fraude évitée » ne doit être comptabilisée que sur des bases solides, afin d'éviter de présenter chaque transaction refusée comme un préjudice évité.

16. Liste de contrôle des tests antifraude avant la mise en production

Identité et compte

• [ ] L'activation avec le matricule d'une autre personne est refusée.

• [ ] Les tentatives répétées ou automatisées déclenchent une alerte ou une limite adaptée.

• [ ] Le changement d'appareil et la récupération de compte exigent un niveau de vérification adéquat.

• [ ] Les anciennes sessions sont révoquées après un changement des informations d'authentification.

• [ ] Un agent du support ne peut pas contourner seul les contrôles.

Compte bénéficiaire

• [ ] Le changement de compte exige une réauthentification.

• [ ] La notification du changement est envoyée via le bon canal.

• [ ] La transaction suivant immédiatement le changement est traitée selon la politique de risque.

• [ ] Un compte bénéficiaire associé à plusieurs salariés est détecté.

• [ ] Un collaborateur non habilité ne peut ni consulter ni modifier l'intégralité des données.

Temps, salaire et plafond

• [ ] Les heures non validées ne génèrent pas de plafond si la politique exige une validation.

• [ ] Une modification tardive des heures entraîne un recalcul correct du plafond.

• [ ] Les anciennes données n'écrasent pas la version la plus récente.

• [ ] Un salarié ayant quitté l'entreprise est suspendu à la date d'effet correcte.

• [ ] Toute modification de formule fait l'objet d'une approbation et d'un journal avant/après.

Transaction et paiement

• [ ] Un renvoi avec la même idempotency_key ne génère pas de double paiement.

• [ ] Une même clé associée à un montant différent est refusée.

• [ ] Un timeout crée un statut incertain, sans envoi automatique d'un nouvel ordre.

• [ ] Un callback falsifié ou dupliqué est rejeté.

• [ ] Une transaction remboursée met à jour le plafond selon la procédure approuvée.

Fraude interne

• [ ] Une même personne ne peut pas créer, approuver et rapprocher une exception à elle seule.

• [ ] Les droits temporaires expirent automatiquement.

• [ ] Un export de données en masse génère un journal et une alerte.

• [ ] Une action d'administration ne peut pas être effacée de la piste d'audit courante.

• [ ] Les droits d'un collaborateur qui change de poste ou quitte l'entreprise sont révoqués dans les délais.

Rapprochement et enquête

• [ ] Une transaction manquante dans l'une des trois sources crée un dossier d'écart.

• [ ] Chaque dossier a un propriétaire et un historique de traitement.

• [ ] Les preuves sont préservées, sans modification directe.

• [ ] Un utilisateur bloqué à tort dispose d'un canal de réclamation et de réouverture.

• [ ] Les exercices de simulation de prise de contrôle de compte et de transaction erronée ont été réalisés.

17. Cadre juridique et protection des données dans la lutte antifraude

La prévention de la fraude peut mobiliser des données de compte, d'appareil, de comportement et d'historique de transactions. L'entreprise doit donc, en parallèle, garantir une finalité de traitement claire, des données adaptées et le respect de la vie privée du salarié.

Au Vietnam, la loi sur la protection des données personnelles n° 91/2025/QH15 entre en vigueur le 1er janvier 2026. Le décret 356/2025/NĐ-CP, également en vigueur à compter du 1er janvier 2026, précise certains articles et les mesures d'application de cette loi. Selon son rôle et son flux de paiement, l'entreprise doit en outre tenir compte du décret 52/2024/NĐ-CP relatif au paiement sans espèces, ainsi que des réglementations sectorielles connexes.

Surveiller la fraude ne signifie pas collecter toutes les données possibles. Chaque signal doit être rattaché à une finalité, à un niveau de nécessité, à une durée de conservation, à des droits d'accès et à une procédure d'explication/de traitement en cas de réponse du salarié. Les conclusions juridiques précises doivent être examinées au regard de l'architecture et des contrats réels.

En matière de gouvernance de la sécurité de l'information, le NIST Cybersecurity Framework 2.0 propose une approche structurée autour des fonctions Govern, Identify, Protect, Detect, Respond et Recover. L'OWASP Application Security Verification Standard peut servir de base pour tester les contrôles techniques des applications et des API. Il s'agit de cadres de référence, qui ne remplacent ni les obligations légales ni l'évaluation de risque propre à chaque entreprise.

Conclusion

Une gouvernance efficace des risques de l'EWA repose sur plusieurs couches de contrôle : des données source fiables, une identification exacte de la personne, un changement de bénéficiaire vérifié, des transactions dotées d'idempotency, des statuts de paiement clairs, une séparation des droits internes, des alertes explicables et un rapprochement transaction par transaction.

L'objectif n'est pas de bloquer le plus possible, mais de prévenir le préjudice au bon moment tout en protégeant le salarié légitime. Si votre entreprise évalue le déploiement de l'accès au salaire déjà gagné, préparez les scénarios de risque, le schéma des droits d'accès et les cas de test UAT à réaliser, puis découvrez l'accès au salaire déjà gagné pour les entreprises afin de demander la documentation sur le contrôle des transactions, le rapprochement et le périmètre de pilote adapté.

Références

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

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

• Décret 52/2024/NĐ-CP relatif au paiement sans espèces

• NIST Cybersecurity Framework

• OWASP Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

Auteur : Tran Van Tai — Assistant du Directeur général adjoint, en charge de la stratégie de développement, Nhan Kiet Manpower Supply Co., Ltd.

Conseil pour les entreprises : Hotline 0937.022.655 · Email info@nhankiet.vn · L'accès au salaire déjà gagné pour les entreprises