Liste de contrôle pour l'audit interne de l'accès au salaire déjà gagné : 50 contrôles et preuves

Liste de contrôle pour l'audit interne de l'accès au salaire déjà gagné : 50 contrôles et preuves à conserver

L'audit interne de l'accès au salaire déjà gagné doit vérifier toute la chaîne bonne personne – bon travail – bon droit – bon montant – bon compte – bon statut – bonne période de paie. Chaque conclusion doit être basée sur des preuves traçables, non seulement sur des interviews ou des captures d'écran. La liste de contrôle des 50 contrôles ci-dessous aide les entreprises à construire un programme de vérification périodique.

> En bref : Auditez selon 10 groupes, chacun avec cinq contrôles : gestion ; ressources humaines ; pointage ; formule/limites ; transactions ; banque ; paie ; données personnelles ; sécurité/incidents ; changements/continuité des activités. Sélectionnez des échantillons basés sur les risques et vérifiez à nouveau des données sources jusqu'au résultat final.

> Avertissement : Ceci est une liste de contrôle de référence, pas une norme d'audit ou un avis juridique. Les entreprises doivent l'adapter en fonction de leur taille, contrats, politiques, systèmes et évaluation des risques réels. Le fait qu'un contrôle soit "dans le code" ne prouve pas qu'il fonctionne efficacement.

1. Objectifs de l'audit

(Voir aussi : Dossier d'évaluation de l'accès au salaire déjà gagné.)

Le programme devrait répondre :

1. Seules les personnes éligibles peuvent-elles utiliser le service ?
2. Seul le travail effectué et approuvé génère-t-il un montant disponible ?
3. Les formules, limites et réserves sont-elles correctement approuvées/appliquées ?
4. Les transactions évitent-elles les doublons, les erreurs de personne et les statuts non clairs ?
5. Les relevés bancaires correspondent-ils aux registres des transactions ?
6. Les montants reçus sont-ils correctement intégrés dans la paie et non cumulés ?
7. Les données personnelles sont-elles traitées conformément aux objectifs/droits ?
8. Les incidents et changements sont-ils contrôlés ?
9. Les rapports de gestion sont-ils complets/précis ?
10. Les recommandations précédentes ont-elles été corrigées ?

2. Portée et fréquence

Peut être appliqué :

• vérification avant mise en service ;
• vérification après 30–90 jours ;
• audit périodique trimestriel/annuel ;
• vérification imprévue après un incident ;
• examen avant l'ouverture à un grand client ;
• vérification lors de changements de banque, formule ou paie.

La portée doit préciser l'entité légale, le client, la période, le système, le compte bancaire, la source du travail, la version logicielle et les tiers.

3. Sélection d'échantillons basée sur les risques

Ne choisissez pas seulement au hasard. Les échantillons devraient inclure :

• transactions de grande valeur/proches des limites ;
• personnes avec de nombreuses transactions par jour/période ;
• transactions en attente, échouées puis réussies ;
• travail modifié après approbation ;
• personnes ayant quitté ou transférées ;
• travailleurs pour plusieurs clients ;
• changements de compte/appareil ;
• transactions en dehors des heures normales ;
• clients avec un taux d'erreur élevé ;
• montants non récupérables ;
• échantillons aléatoires pour détecter les écarts imprévus.

La taille de l'échantillon doit être déterminée par l'audit en fonction de l'ensemble et des risques, sans utiliser un nombre fixe pour chaque période.

4. Échelle d'évaluation des découvertes

Niveau	Caractéristiques	Exemple
Grave	Risque financier/données important ou échec des contrôles clés	Doublons, erreur de personne, fuite de clé
Élevé	Impact sur de nombreuses personnes/périodes ou non réconciliable	Erreur de formule, écart de paie
Moyen	Contrôle existant mais fonctionnement incohérent	Approbation tardive, droits non révisés
Faible	Dossiers/efficacité à améliorer	Manque de preuves de formation

Le niveau officiel doit être lié à des critères financiers, nombre de personnes, obligations légales et délais de correction.

5. Groupe 1 — Gestion et politiques (Contrôles 1–5)

1. Un responsable de service est en charge de bout en bout.
2. Le règlement de l'accès au salaire déjà gagné est en vigueur, avec autorité d'approbation et historique des versions.
3. Le RACI correspond aux droits réels sur le système.
4. Les KPI ne poussent pas les travailleurs à effectuer des transactions.
5. Les risques, exceptions et actions sont rapportés périodiquement.

Preuves : décision de nomination, règlement, matrice des droits, procès-verbal de réunion, tableau de bord, registre des risques.

Test : choisir trois rôles et comparer les droits dans les documents avec les droits réels ; vérifier si les actions en retard ont un responsable.

6. Groupe 2 — Liste des travailleurs et identification (6–10)

1. La liste ne comprend que les personnes actives/clients corrects.
2. Le numéro d'identification est une clé unique et non dupliquée.
3. Le code de pointage est correctement associé au client/lieu de travail.
4. Le compte bancaire est vérifié et correspond au titulaire avant utilisation.
5. Les changements d'appareil/compte ou exceptions sont approuvés et enregistrés.

Preuves : fichier source des ressources humaines, journal de synchronisation, résultats de vérification, historique des changements, formulaire d'approbation des exceptions.

Test : choisir des échantillons de nouveaux employés, départs, transferts et changements d'appareil ; tracer depuis le dossier source jusqu'aux droits d'utilisation actuels.

7. Groupe 3 — Pointage et approbation (11–15)

1. La source du travail/clé de liaison/fréquence de synchronisation est documentée.
2. Le travail futur et les jours non clôturés ne génèrent pas de montant disponible.
3. Seules les personnes autorisées peuvent approuver/refuser/modifier le travail.
4. Les modifications de travail approuvé ramènent l'enregistrement en attente et enregistrent avant/après.
5. Les quarts de nuit, heures supplémentaires, congés et multiples lieux de travail sont traités selon les règles d'approbation.

Preuves : configuration de la source, journal d'importation, liste des droits, piste d'audit, dictionnaire des quarts/symboles.

Test : recréer un quart normal, un quart de nuit et un enregistrement modifié ; vérifier le résultat dans le montant disponible.

8. Groupe 4 — Formule, prix unitaire, limites et réserve (16–20)

1. La formule du système correspond à la politique approuvée.
2. Le prix unitaire/jour est correctement associé au client et à la période de validité.
3. Les limites minimales, par ordre, par jour sont correctement configurées.
4. La réserve/N jours de travail est calculée et affichée correctement.
5. Les changements de paramètres sensibles nécessitent une double validation, un journal et une vérification après changement.

Preuves : tableau des politiques, configuration, journal des changements, approbation, résultats de calcul d'échantillon.

Test : recalculer un échantillon avec la formule travail approuvé × prix unitaire − reçu − réserve, vérifier l'arrondi à 1 000 unités et les limites.

Les valeurs par défaut dans le code incluent 50 000 unités/transaction, 3 millions d'unités/ordre et 5 millions d'unités/personne/jour ; l'audit doit comparer avec les valeurs réellement appliquées, sans supposer que ces chiffres sont la politique.

9. Groupe 5 — Initiation et traitement des transactions (21–25)

1. Le serveur vérifie toutes les conditions, pas seulement les données de l'application.
2. Les travailleurs confirment le contenu avant chaque demande.
3. Chaque demande a un code de transaction stable pour éviter les répétitions.
4. Il existe un verrouillage simultané/empêchant deux ordres pour le même montant disponible.
5. Seules les réponses valides changent le statut à "payé".

Preuves : documentation des flux, journal des données masquées, code de transaction, tests automatisés, modèle de contenu d'engagement.

Test : essayer deux demandes presque simultanées, une demande dépassant les limites, sans numéro d'identification, travail non approuvé et réponse bancaire invalide dans un environnement de test autorisé.

10. Groupe 6 — Banque et réconciliation (26–30)

(Détails : voir Réconciliation des transactions de l'accès au salaire déjà gagné avec la paie et la comptabilité.)

1. Le service de gestion des clés bancaires est séparé et l'accès est restreint.
2. Le compte source, les signataires/autorisations et les limites de dépenses sont gérés.
3. Les statuts non clairs sont maintenus en attente, sans initiation automatique de nouvelles transactions.
4. Les montants en suspens sont vérifiés selon la procédure et ont un âge d'alerte.
5. La réconciliation des relevés T+1 est effectuée, les écarts ont un responsable.

Preuves : schéma des flux financiers, matrice des droits, journal de vérification, relevés masqués, rapport de réconciliation et procès-verbal de clôture.

Test : choisir toutes les transactions en suspens de la période et un échantillon de réussites/échecs ; comparer dans les deux sens du système au relevé et du relevé au système.

Le système actuel a un calendrier de vérification de 5 minutes et lit les relevés à 08:00 T+1. C'est une spécification technique ; l'audit doit vérifier l'exécution réelle et le SLA officiel.

11. Groupe 7 — Paie et règlement (31–35)

1. Seules les transactions confirmées réussies sont incluses dans le total reçu.
2. Les transactions sont correctement associées à la personne, au client et à la période de paie.
3. Les jours de travail ont couvert la clé, sans cumul pour la période suivante.
4. Le total des transactions correspond au montant sur la paie/bulletin de paie.
5. Les départs, réductions de travail, remboursements et montants non récupérables ont une procédure.

Preuves : fichier de transactions, rapport de liaison, paie, modèle de bulletin de paie, advancecovereddays, registre des montants non récupérables.

Test : effectuer à nouveau la réconciliation pour un échantillon d'utilisateurs ; vérifier la coupure de début/fin de période et un cas de départ.

Ne pas conclure sur la déduction/récupération uniquement à partir de la logique logicielle ; comparer avec la politique et l'avis juridique approuvé.

12. Groupe 8 — Données personnelles et confidentialité (36–40)

(Cadre complet : voir Sécurité des données et confidentialité lors du déploiement de l'accès au salaire déjà gagné.)

1. Les rôles de traitement, objectifs et catégories de données sont documentés.
2. Les notifications/consentements et droits des sujets de données sont appliqués lorsque requis.
3. Les droits d'accès aux numéros d'identification, photos, GPS, comptes et salaires sont restreints.
4. Les délais de conservation, suppression/anonymisation et sous-traitants sont gérés.
5. Les violations de données ont une procédure de détection, évaluation et notification.

Preuves : politiques, dossiers de traitement, évaluations d'impact, liste des sous-traitants, journal des droits, preuves de suppression, procès-verbal d'incident.

Test : choisir un type de données depuis la collecte jusqu'à la suppression ; choisir trois comptes internes et vérifier les droits ; examiner le journal des exportations de données.

Le cadre juridique actuel à considérer inclut la Loi sur la protection des données personnelles 91/2025/QH15 et le Décret 356/2025/NĐ-CP, tous deux en vigueur à partir du 01/01/2026.

13. Groupe 9 — Sécurité de l'information et gestion des incidents (41–45)

(Voir aussi : Les couches de protection d'une transaction d'accès au salaire déjà gagné et Quand l'accès au salaire déjà gagné génère un incident.)

1. Il existe une gestion des vulnérabilités, des correctifs et des tests de sécurité.
2. Les secrets/clés sont stockés, transférés et révoqués en toute sécurité.
3. Les journaux importants sont protégés, synchronisés dans le temps et alertés.
4. Les incidents P1–P4 ont un commandant d'incident, une escalade et une analyse des causes profondes.
5. Le bouton d'arrêt d'urgence est contrôlé et testé.

Preuves : rapports de scan/pentest, registre des actifs, politique des clés, alertes, tickets d'incident, analyse des causes profondes, procès-verbal de test.

Test : choisir un incident clos et vérifier la chronologie ; confirmer que les actions de l'analyse des causes profondes sont terminées ; vérifier que les personnes ayant quitté ont perdu les droits sensibles.

Le nombre de fichiers de test ne remplace pas un test de sécurité indépendant ou des preuves de contrôle opérationnel.

14. Groupe 10 — Changements, BCP/DR et sortie de service (46–50)

1. Chaque version/configuration a une demande, une approbation, un test et un retour arrière.
2. La séparation des tâches entre développeur, approbateur et déployeur est adaptée aux risques.
3. Les sauvegardes, RTO/RPO et récupérations sont testées.
4. Les dépendances bancaires/ERP/Sheet/VietQR ont un plan de continuité.
5. La fin de service inclut l'exportation/restitution/suppression des données et la révocation des droits.

Preuves : ticket de changement, journal de déploiement, procès-verbal de sauvegarde et restauration, plan BCP/DR, résultats de test, liste de contrôle de sortie de fournisseur.

Test : choisir un changement urgent et un changement régulier ; vérifier s'il y a une vérification post-implémentation. Choisir une sauvegarde et vérifier les preuves de récupération, pas seulement l'état "sauvegarde réussie".

15. Techniques d'audit recommandées

Walkthrough

Choisir une transaction et suivre le processus du travail au bulletin de paie avec le responsable.

Reperformance

Recalculer le montant disponible et le total de réconciliation à partir des données sources.

Inspection

Vérifier la configuration, les journaux, les approbations et la documentation.

Observation

Observer un utilisateur/superviser le traitement d'une exception.

Confirmation

Confirmer les soldes/statuts avec une source indépendante appropriée, comme un relevé bancaire.

Data analytics

Analyser l'ensemble pour trouver des codes dupliqués, des personnes dépassant les limites, des transactions hors heures, des modifications de travail après paiement ou des écarts de paie.

Les interviews ne montrent que comment le processus est décrit ; elles ne suffisent pas à prouver qu'il fonctionne.

16. Modèle de feuille de travail d'audit

Champ	Contenu
Code de contrôle	C01–C50
Objectif	Quel risque est contrôlé
Propriétaire	Personne responsable
Conception	Le contrôle est-il approprié ?
Opération	A-t-il fonctionné pendant la période ?
Ensemble/échantillon	Taille et méthode de sélection
Preuves	Lien ou code de dossier
Exception	Nombre/valeur/impact
Conclusion	Efficace/non efficace/partiellement
Action	Responsable et échéance

17. Requêtes de données suggérées

• même numéro d'identification associé à plusieurs comptes actifs ;
• un compte bancaire associé à plusieurs personnes ;
• transactions avec même montant/temps/personne ;
• total par personne dépassant la limite journalière ;
• travail avec date future mais générant un montant ;
• travail modifié après une transaction réussie ;
• transaction réussie sans relevé ;
• relevé de paiement sans transaction interne ;
• transaction échouée/en attente apparaissant dans la paie ;
• personne ayant quitté générant encore des demandes ;
• changement de configuration sans ticket ;
• admin inactif depuis longtemps mais avec droits ;
• journal manquant pendant une période anormale.

Les requêtes doivent être testées pour éviter les faux positifs et exécutées dans le cadre des droits de données.

18. Comment rédiger une découverte d'audit

Une bonne découverte comprend cinq parties :

1. Critère : ce que le règlement/contrat/contrôle exige.
2. Constat : ce que montrent les preuves.
3. Cause : pourquoi le contrôle ne fonctionne pas.
4. Impact : finances, personnes, données, légalité, opérations.
5. Recommandation : action spécifique, responsable et échéance.

Exemple à éviter : "Renforcer le contrôle."
Exemple amélioré : "Parmi les 25 changements de limite sélectionnés, 4 manquaient d'approbation indépendante. Ajouter une approbation à double validation sur le système avant le..."

Ne publiez pas d'exemples réels sans anonymisation et autorisation.

19. Suivi des corrections

Chaque action nécessite :

• un propriétaire ;
• une date limite ;
• un niveau de priorité ;
• des preuves requises ;
• un vérificateur ;
• un statut ;
• une raison de prolongation ;
• un risque accepté par l'autorité appropriée si non corrigé.

Ne fermez pas une découverte simplement parce qu'il y a un plan ; vérifiez les preuves de mise en œuvre et l'efficacité après correction.

20. Questions fréquentes

Le fait qu'un contrôle soit dans le code signifie-t-il qu'il est efficace ?

Non. Il faut vérifier la configuration, les données réelles, les opérateurs et les preuves pendant la période.

Combien de transactions doivent être auditées ?

Cela dépend de l'ensemble, des risques et des objectifs. Combinez des échantillons basés sur les risques, aléatoires et une analyse complète des données lorsque possible.

Qui ne devrait pas auditer sa propre opération ?

Les opérateurs peuvent effectuer des vérifications de première ligne ; une évaluation indépendante devrait être réalisée par la deuxième/troisième ligne ou un audit suffisamment indépendant.

Une transaction en attente est-elle une erreur ?

Pas automatiquement. Il faut voir si le système maintient une attente sécurisée, vérifie à temps et évite les doublons.

Faut-il auditer séparément les données personnelles ?

Cela peut être intégré ou séparé, mais doit inclure l'expertise et la portée complète selon les lois/politiques en vigueur.

21. Conclusion

Un audit efficace de l'accès au salaire déjà gagné doit traverser toute la chaîne et être réexécuté avec des données réelles. Un système avec de nombreuses couches de protection doit encore prouver que ces couches sont activées, avec les bons droits et fonctionnent pendant la période. Le jeu de 50 contrôles aide les entreprises à passer de la confiance dans la description à la preuve : qui a fait quoi, sur quelles données, quel a été le résultat et comment les écarts ont été traités.

Sources officielles de référence

• Loi sur la protection des données personnelles n° 91/2025/QH15, en vigueur à partir du 01/01/2026.
• Décret 356/2025/NĐ-CP, précisant certaines dispositions et mesures d'application de la Loi sur la protection des données personnelles, en vigueur à partir du 01/01/2026.

---

Auteur : Nguyen Minh Khang — Chuyên viên ban chiến lược, Nhan Kiet Manpower Supply Co., Ltd.

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