Tjekliste for intern revision af adgang til optjent løn: 50 kontroller og beviser

Tjekliste for intern revision af adgang til optjent løn: 50 kontroller og beviser der skal opbevares

Intern revision af adgang til optjent løn skal verificere hele kæden af korrekt person – korrekt arbejde – korrekt rettighed – korrekt beløb – korrekt konto – korrekt status – korrekt lønperiode. Hver konklusion skal baseres på sporbare beviser, ikke kun interviews eller skærmbilleder. Tjeklisten med 50 kontroller nedenfor hjælper virksomheder med at opbygge et program for regelmæssig kontrol.

> Kort sagt: Revider efter 10 grupper, hver med fem kontroller: ledelse; personale; tidsregistrering; formler/grænser; transaktioner; bank; løn; persondata; sikkerhed/hændelser; ændringer/forretningskontinuitet. Vælg prøver baseret på risiko og kontroller fra rådata til endelige resultater.

> Advarsel: Dette er en vejledende tjekliste, ikke en revisionsstandard eller juridisk udtalelse. Virksomheder skal tilpasse den efter størrelse, kontrakter, politikker, systemer og faktiske risikovurderinger. Status "i koden" beviser ikke i sig selv, at kontrollen fungerer effektivt.

1. Revisionsmål

(Se mere: Due diligence-dokumentation for adgang til optjent løn.)

Programmet bør besvare:

1. Kan kun kvalificerede personer bruge det?
2. Er kun udført og godkendt arbejde tilgængeligt?
3. Er formler, grænser og reserver korrekt godkendt/anvendt?
4. Er transaktioner fri for duplikater, forkerte personer og uklar status?
5. Matcher bankudtog transaktionsbogen?
6. Er modtagne beløb korrekt indregnet i lønnen og ikke akkumuleret?
7. Behandles persondata korrekt i forhold til formål/rettigheder?
8. Er hændelser og ændringer kontrolleret?
9. Er ledelsesrapporter komplette/korrekte?
10. Er tidligere anbefalinger blevet adresseret?

2. Omfang og frekvens

Kan anvendes:

• før go-live kontrol;
• kontrol efter 30–90 dage;
• kvartals-/årlig revision;
• uventet kontrol efter hændelser;
• gennemgang før åbning for store kunder;
• kontrol ved ændringer i bank, formler eller løn.

Omfanget skal klart angive juridiske enheder, kunder, perioder, systemer, bankkonti, arbejdsressourcer, softwareversioner og tredjeparter.

3. Udvælgelse baseret på risiko

Ikke kun tilfældig udvælgelse. Prøver bør inkludere:

• transaktioner med høj værdi/tæt på grænser;
• personer med mange transaktioner på en dag/periode;
• ventende, mislykkede og efterfølgende succesfulde transaktioner;
• arbejde ændret efter godkendelse;
• personer der fratræder/overflyttes;
• arbejdstagere der arbejder for flere kunder;
• ændringer i konto/enhed;
• transaktioner uden for normal arbejdstid;
• kunder med høj fejlrate;
• ikke-inddrivelige beløb;
• tilfældige prøver for at opdage uforudsete afvigelser.

Prøvestørrelsen skal bestemmes af revisionen baseret på helheden og risikoen, ikke en fast størrelse for alle perioder.

4. Vurderingsskala for fund

Niveau	Karakteristika	Eksempel
Alvorlig	Stor risiko for penge/data eller kernekontrolfejl	Dobbeltbetaling, forkert person, nøglelækage
Høj	Påvirker mange personer/perioder eller kan ikke afstemmes	Forkert formel, lønafvigelse
Mellem	Kontrol findes men er inkonsekvent i drift	Forsinket godkendelse, rettigheder ikke gennemgået
Lav	Dokumentation/effektivitet skal forbedres	Manglende træningsbeviser

Det officielle niveau skal knyttes til kriterier for penge, antal personer, juridiske forpligtelser og tidsfrister for afhjælpning.

5. Gruppe 1 — Ledelse og politikker (Kontrol 1–5)

1. Der er en Service Owner med ansvar fra start til slut.
2. Politikken for adgang til optjent løn er gyldig, med godkendelsesmyndighed og versionshistorik.
3. RACI matcher faktiske rettigheder i systemet.
4. KPI'er tilskynder ikke til at presse arbejdstagere til transaktioner.
5. Risici, undtagelser og handlinger rapporteres regelmæssigt.

Beviser: udnævnelsesbeslutninger, politikker, rettighedsmatrix, mødereferater, dashboards, risikoregistre.

Test: vælg tre roller og sammenlign rettigheder i dokumenter med faktiske rettigheder; se om forsinkede handlinger har ansvarlige personer.

6. Gruppe 2 — Arbejdstagerliste og identifikation (6–10)

1. Listen indeholder kun nuværende medarbejdere/korrekte kunder.
2. ID-kort er en unik identifikationsnøgle, der er matchet og ikke duplikeret.
3. Tidsregistreringskoder er korrekt tilknyttet kunder/arbejdssteder.
4. VPBank-konti er verificeret og matchet med ejeren før brug.
5. Enheds-/kontoændringer eller undtagelser er godkendt og logget.

Beviser: kildemedarbejderfiler, synkroniseringslog, verifikationsresultater, ændringshistorik, undtagelsesgodkendelser.

Test: vælg prøver af nye, fratrådte, overflyttede medarbejdere og enhedsændringer; spor fra kildefiler til nuværende rettigheder.

7. Gruppe 3 — Tidsregistrering og godkendelse (11–15)

1. Arbejdskilder/nøgler/synkroniseringsfrekvenser er dokumenteret.
2. Fremtidigt arbejde og ikke-afsluttede dage genererer ikke tilgængelige beløb.
3. Kun autoriserede personer kan godkende/afvise/redigere arbejde.
4. Redigeret godkendt arbejde returneres til ventende status og logges før/efter.
5. Natarbejde, overarbejde, pauser og flere arbejdssteder behandles efter godkendelsesregler.

Beviser: kildekonfigurationer, importlog, rettighedslister, revisionsspor, skiftordbøger.

Test: genskab en almindelig vagt, en nattevagt og en redigeret post; kontroller resultaterne i tilgængelige beløb.

8. Gruppe 4 — Formler, enhedspriser, grænser og reserver (16–20)

1. Systemformler matcher godkendte politikker.
2. Enhedspriser/dag er korrekt tilknyttet kunder og gyldighedsperioder.
3. Minimumsgrænser, pr. ordre, pr. dag er korrekt konfigureret.
4. Reserverede/N arbejdsdage beregnes og vises korrekt.
5. Ændringer i følsomme parametre har fire øjne, log og efterkontrol.

Beviser: politikdokumenter, konfigurationer, ændringslog, godkendelser, prøveberegningsresultater.

Test: genberegn prøver ved hjælp af formlen godkendt arbejde × enhedspris − modtaget − reserver, kontroller afrunding ned til 1.000 VND og grænseværdier.

Standardniveauer i koden inkluderer 50.000 VND/gang, 3 millioner VND/ordre og 5 millioner VND/person/dag; revisionen skal sammenligne med faktiske anvendte niveauer, ikke antage disse tal som politik.

9. Gruppe 5 — Oprettelse og behandling af transaktioner (21–25)

1. Serveren kontrollerer alle betingelser igen, ikke kun data fra appen.
2. Arbejdstagere bekræfter indholdet før hver anmodning.
3. Hver anmodning har en stabil transaktionskode for at forhindre gentagelse.
4. Der er samtidighedslås/forhindring af to ordrer for samme tilgængelige beløb.
5. Kun gyldige svar ændrer status til betalt.

Beviser: flowdokumentation, anonymiserede logfiler, transaktionskoder, automatiserede tests, prøveindhold for forpligtelser.

Test: prøv to næsten samtidige anmodninger, anmodninger over grænser, manglende ID-kort, ikke-godkendt arbejde og ugyldige bankreaktioner i et tilladt testmiljø.

10. Gruppe 6 — Bank og afstemning (26–30)

(Detaljer: se Afstemning af transaktioner for adgang til optjent løn med løn og regnskab.)

1. Banknøgleopbevaring er adskilt og adgangsbegrænset.
2. Kildekonti, underskrivere/fuldmagter og udgiftsgrænser er administreret.
3. Uklare statuser holdes i venteposition, ingen nye ordrer udstedes automatisk.
4. Suspenderede beløb undersøges efter procedurer og har advarselsalder.
5. T+1 afstemning af kontoudtog udføres, og forskelle har ansvarlige personer.

Beviser: pengestrømsdiagrammer, rettighedsmatrix, undersøgelseslog, anonymiserede kontoudtog, afstemningsrapporter og afslutningsreferater.

Test: vælg alle suspenderede transaktioner i perioden og prøver af succesfulde/mislykkede; afstem to-vejs fra system til kontoudtog og fra kontoudtog til system.

Systemet har en nuværende undersøgelsesplan på 5 minutter og læser kontoudtog kl. 08:00 T+1. Dette er tekniske specifikationer; revisionen skal se på faktisk kørsel og officielle SLA'er.

11. Gruppe 7 — Løn og afregning (31–35)

1. Kun bekræftede succesfulde transaktioner går ind i det samlede modtagne beløb.
2. Transaktioner er korrekt tilknyttet personer, kunder og lønperioder.
3. Arbejdsdage er dækket af nøgler, ikke akkumuleret til næste periode.
4. Samlede transaktioner matcher beløb på løn/udbetalingssedler.
5. Fratrædelser, reduceret arbejde, tilbagebetalinger og ikke-inddrivelige beløb har procedurer.

Beviser: transaktionsfiler, bro-rapporter, løn, prøve lønsedler, advancecovereddays, ikke-inddrivelige beløbsregistre.

Test: genudfør afstemning for prøvebrugere; kontroller cut-off i starten/slutningen af perioden og en fratrædelsessag.

Konkluder ikke fradrags-/inddrivelsesmetoder kun fra softwarelogik; sammenlign med godkendte politikker og juridiske udtalelser.

12. Gruppe 8 — Persondata og privatliv (36–40)

(Fuld ramme: se Datasikkerhed og privatliv ved implementering af adgang til optjent løn.)

1. Roller, formål og datakategorier er dokumenteret.
2. Meddelelser/samtykke og databeskyttelsesrettigheder er implementeret.
3. Adgang til ID-kort, billeder, GPS, konti og løn er begrænset.
4. Opbevaringsperioder, sletning/anonymisering og underbehandlere er administreret.
5. Databrud har detektions-, vurderings- og anmeldelsesprocedurer.

Beviser: politikker, behandlingsdokumentation, konsekvensvurderinger, underbehandlerlister, logrettigheder, sletningsbeviser, hændelsesrapporter.

Test: vælg en datatype fra indsamling til sletning; vælg tre interne konti og kontroller rettigheder; gennemgå log for dataeksport.

Den nuværende lovgivningsramme inkluderer Persondataloven 91/2025/QH15 og Dekret 356/2025/NĐ-CP, begge gældende fra 01/01/2026.

13. Gruppe 9 — Informationssikkerhed og hændelseshåndtering (41–45)

(Se mere: Beskyttelseslag for en transaktion med adgang til optjent løn og Når adgang til optjent løn forårsager hændelser.)

1. Der er styring af sårbarheder, patches og sikkerhedstest.
2. Hemmeligheder/nøgler opbevares, roteres og tilbagekaldes sikkert.
3. Vigtige logs er beskyttet, tidsmæssigt synkroniseret og alarmeret.
4. Hændelser P1–P4 har Incident Commander, eskalering og RCA.
5. Nødstopknapper er kontrolleret og øvet.

Beviser: scanning/pentest-rapporter, aktivregistre, nøglepolitikker, alarmer, hændelsesbilletter, RCA, øvelsesrapporter.

Test: vælg en lukket hændelse og kontroller tidslinjen; bekræft afsluttede RCA-handlinger; kontroller at fratrådte personer har mistet følsomme rettigheder.

Antallet af testfiler erstatter ikke uafhængige sikkerhedstests eller beviser for operationelle kontroller.

14. Gruppe 10 — Ændringer, BCP/DR og serviceophør (46–50)

1. Alle releases/konfigurationer har anmodninger, godkendelser, tests og rollback.
2. Adskillelse af opgaver mellem udviklere, godkendere og implementering er passende for risiko.
3. Backup, RTO/RPO og gendannelse er testet.
4. Afhængigheder af bank/ERP/Sheet/VietQR har afbrydelsesplaner.
5. Serviceophør har eksport/returnering/sletning af data og tilbagekaldelse af rettigheder.

Beviser: ændringsbilletter, implementeringslog, backup-gendannelsesrapporter, BCP/DR-planer, øvelsesresultater, leverandørafslutnings-tjeklister.

Test: vælg en nødsituation og en almindelig ændring; se om der er efterkontrol. Vælg en backup og kontroller gendannelsesbeviser, ikke kun "backup succes" status.

15. Revisionsmetoder der bør anvendes

Walkthrough

Vælg en transaktion og følg proceslederen fra arbejde til lønseddel.

Reperformance

Beregn tilgængelige beløb og samlede afstemninger fra rådata.

Inspection

Kontroller konfigurationer, logs, godkendelser og dokumentation.

Observation

Observer brugere/overvåg håndtering af en undtagelse.

Confirmation

Bekræft saldi/status med passende uafhængige kilder, som bankudtog.

Data analytics

Scan hele populationen for at finde duplikerede koder, personer over grænser, transaktioner uden for arbejdstid, arbejde redigeret efter betaling eller lønafvigelser.

Interviews afslører kun, hvordan processer beskrives; de er ikke tilstrækkelige til at bevise, at de fungerer.

16. Eksempel på revisionsarbejdsark

Felt	Indhold
Kontrolkode	C01–C50
Mål	Hvilken risiko kontrolleres
Ejer	Ansvarlig person
Design	Er kontrollen passende
Drift	Har den fungeret i perioden
Helhed/prøve	Størrelse og udvælgelsesmetode
Beviser	Sti eller filkode
Undtagelser	Antal/værdi/påvirkning
Konklusion	Effektiv/ineffektiv/delvis
Handling	Ansvarlig person og deadline

17. Forslag til dataforespørgsler

• samme ID-kort knyttet til flere aktive konti;
• en bankkonto knyttet til flere personer;
• transaktioner med samme beløb/tidspunkt/person;
• total pr. person over daglig grænse;
• arbejde med fremtidige datoer men genererer penge;
• arbejde redigeret efter succesfuld transaktion;
• succesfulde transaktioner uden kontoudtog;
• kontoudtog uden interne transaktioner;
• mislykkede/ventende transaktioner der vises i løn;
• personer der fratræder men stadig genererer anmodninger;
• konfigurationsændringer uden billetter;
• admin uden aktivitet i lang tid men stadig med rettigheder;
• manglende logs i unormale tidsintervaller.

Forespørgsler skal testes for at undgå falske positiver og udføres inden for datatilladelsesområdet.

18. Sådan skriver du revisionsfund

Et godt fund har fem dele:

1. Kriterium: hvad kræver politik/kontrakt/kontrol.
2. Faktisk tilstand: hvad viser beviserne.
3. Årsag: hvorfor fungerer kontrollen ikke.
4. Indvirkning: penge, personer, data, juridisk, drift.
5. Anbefaling: specifik handling, ansvarlig person og deadline.

Dårligt eksempel: “Kontrollen skal styrkes.”
Bedre eksempel: “Ud af 25 udvalgte grænseændringer mangler 4 uafhængig godkendelse. Tilføj obligatorisk fire øjne-godkendelse i systemet inden…”

Offentliggør ikke faktiske eksempler uden anonymisering og tilladelse.

19. Opfølgning på afhjælpning

Hver handling skal have:

• ejer;
• deadline;
• prioriteringsniveau;
• krævede beviser;
• person til genkontrol;
• status;
• årsag til forlængelse;
• risiko accepteret af korrekt myndighed hvis ikke rettet.

Luk ikke fund kun fordi der er en plan; kontroller beviser for implementering og effektivitet efter rettelse.

20. Ofte stillede spørgsmål

Betyder "i koden" at kontrollen er effektiv?

Nej. Man skal kontrollere konfigurationer, faktiske data, operatører og beviser i perioden.

Hvor mange transaktioner skal revideres?

Afhænger af helhed, risiko og mål. Kombiner risikobaserede prøver, tilfældige prøver og fuld dataanalyse når muligt.

Hvem bør ikke revidere deres egen drift?

Operatører kan selv kontrollere første linje; uafhængig vurdering bør udføres af anden/tredje linje eller revision med tilstrækkelig uafhængighed.

Er suspenderede transaktioner en fejl?

Ikke nødvendigvis. Man skal se om systemet holder dem sikkert, undersøger rettidigt og ikke dobbeltbetaler.

Skal persondata revideres separat?

Det kan kombineres eller adskilles, men skal have ekspertise og fuldt omfang i henhold til gældende lovgivning/politikker.

21. Konklusion

Effektiv revision af adgang til optjent løn skal gennemgå hele kæden og genudføre med faktiske data. Et system med mange beskyttelseslag skal stadig bevise, at disse lag er aktiveret, med korrekte rettigheder og fungerer i perioden. De 50 kontroller hjælper virksomheder med at skifte fra tillid til beskrivelser til beviser: hvem gjorde hvad, på hvilke data, hvad var resultatet, og hvordan blev afvigelser håndteret.

Officielle referencer

• Persondataloven nr. 91/2025/QH15, gældende fra 01/01/2026.
• Dekret 356/2025/NĐ-CP, detaljerede bestemmelser og foranstaltninger til gennemførelse af Persondataloven, gældende fra 01/01/2026.

---

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

Rådgivning om adgang til optjent løn for virksomheder: Hotline 0937.022.655 · Email info@nhankiet.vn · Adgang til optjent løn for virksomheder