Risikostyring og bekæmpelse af svindel i adgang til optjent løn (EWA)

For at styre svindelrisikoen ved adgang til optjent løn (EWA) skal virksomheden kontrollere hele kæden – fra medarbejderverificering, godkendt arbejdstid og beløbsgrænser til modtagerkonti, betalingsordrer og afstemning. Tre vigtige lag er: forebyggelse gennem rettighedsstyring og transaktionsregler; opdagelse gennem data, advarsler og afstemning; og reaktion gennem kontrolleret spærring, undersøgelse, tilbagebetaling og udbedring af grundlæggende årsager. Man bør ikke betragte enhver uregelmæssighed som svindel, og man bør heller ikke automatisk udbetale på ny, når resultatet af en transaktion er uafklaret.

> Bemærk: Denne artikel giver en vejledende styrings- og teknisk ramme. Alarmtærskler, beløbsgrænser, tilbageholdelsestider, undersøgelsesprocesser og de enkelte parters ansvar skal godkendes af virksomheden, EWA-udbyderen, betalingspartneren, den juridiske afdeling og informationssikkerhedsafdelingen ud fra den faktiske implementeringsmodel.

> Ordforklaring: EWA (adgang til optjent løn) · HRIS (HR-informationssystem) · payroll (lønbehandling) · ERP (enterprise resource planning) · MFA (multifaktorautentificering) · risk-based auth (risikobaseret autentificering) · idempotency (forebyggelse af dobbelttransaktioner) · callback/webhook (automatisk notifikation mellem systemer) · timeout (udløb af ventetid) · false positive (fejlagtig blokering/falsk alarm) · social engineering (ikke-teknisk bedrageri) · go-live (officiel idriftsættelse) · NIST CSF / OWASP ASVS (rammeværk og standarder for informationssikkerhed).

Hvordan adskiller EWA-risiko sig fra risikoen ved et lån?

Adgang til optjent løn (EWA) er designet til, at medarbejdere kan få adgang til en del af den løn, de allerede har optjent. Derfor ligger den centrale risiko ikke kun i muligheden for "manglende tilbagebetaling", men i at systemet identificerer den forkerte person, forkert arbejdstid, forkert beløbsgrænse, forkert modtagerkonto eller forkert betalingsstatus.

Eksempler:

• en medarbejders konto bliver overtaget, og modtagerkontonummeret ændres;

• ikke-godkendte fremmødedata bliver alligevel medregnet i beløbsgrænsen;

• en anmodning sendes igen efter timeout, hvilket resulterer i dobbelt udbetaling;

• en medarbejder er fratrådt, men status i HRIS er ikke opdateret;

• en person med ret til at rette arbejdstid har samtidig ret til at godkende transaktioner;

• en transaktion lykkes i banken, men er ikke registreret i lønsystemet;

• en reel medarbejder bliver fejlagtigt spærret, fordi advarselsmodellen er for følsom.

Risikostyring i EWA skal derfor beskytte fire egenskaber samtidigt:

1. Den rette person: den, der udfører transaktionen, er den retmæssige kontoindehaver.

2. Den rette ydelse: beløbet beregnes ud fra godkendte data og gældende politik.

3. Den rette modtager: pengene overføres til en verificeret konto.

4. Præcis én gang: hver gyldig anmodning skaber kun ét betalingsresultat og bliver fuldt afstemt.

1. Skeln mellem fejl, misbrug og svindel

Ikke enhver afvigelse er svindel. Hvis driftsteamet konkluderer for hurtigt, risikerer virksomheden at behandle en medarbejder uretfærdigt eller at overse en systemfejl, der skal udbedres.

Et godt system bør registrere hændelsen som en uregelmæssighed, der kræver verificering, indtil der er tilstrækkelige beviser til at konkludere svindel.

2. Risikokort for EWA-transaktionens livscyklus

flowchart TD
    A["Identifikation og aktivering"] --> B["Modtagelse af arbejdstids- og løndata"]
    B --> C["Beregning af beløbsgrænse"]
    C --> D["Oprettelse af anmodning"]
    D --> E["Pengeoverførsel"]
    E --> F["Afstemning og opgørelse"]
    F --> G["Opfølgning, klager, tilbagebetaling"]

Hvert trin har sin egen risikogruppe:

3. Opbygning af et EWA-risikoregister

Et risikoregister omsætter generelle bekymringer til konkret ansvar og handling. Hver risiko bør have:

• et ID og en beskrivelse af scenariet;

• det aktiv eller den proces, der berøres;

• årsag og udløsende betingelser;

• sandsynlighed og konsekvensgrad;

• forebyggende, opdagende og afhjælpende kontroller;

• data eller nøgletal til opfølgning;

• en risikoejer;

• restrisiko efter kontroller;

• en person med bemyndigelse til at acceptere restrisikoen;

• dato for næste gennemgang.

Eksempel på risikomatrix

Sandsynlighedsniveauer bør ikke kopieres fra andre virksomheder. Scoren skal baseres på arbejdsstyrkens størrelse, transaktionsfrekvens, automatiseringsgrad, datakvalitet og programmets egen hændelseshistorik.

4. Kontrol af identitet og kontoovertagelse

Svindlere har som regel ikke brug for at bryde beregningsalgoritmen for beløbsgrænsen, hvis de kan overtage en gyldig konto. De højeste risikopunkter er typisk aktivering, kontogenoprettelse, ændring af telefonnummer, skift af enhed og ændring af modtagerkonto.

Kontroller ved aktivering

• sammenhold medarbejder-id med en godkendt HRIS-kilde;

• verificér, at kontaktkanalen tilhører medarbejderen;

• undgå at basere sig på let tilgængelige oplysninger som fødselsdato eller medarbejder-id;

• begræns antallet af forsøg, og opdag flere konti fra samme enhed;

• giv besked om aktivering via den registrerede kanal;

• gem bevis for vilkårsversion og tidspunkt for accept.

Kontroller ved login og transaktioner

• autentificering, der matcher risikoniveauet;

• gen-autentificering før transaktioner eller følsomme ændringer;

• opdagelse af nye enheder, usædvanlige sessioner og gentagne mislykkede forsøg;

• deaktivering af gamle sessioner efter password-skift eller anmeldelse af mistet enhed;

• øjeblikkelig besked ved nyt login eller ny transaktion;

• mulighed for, at brugeren kan indberette "det var ikke mig" via en let tilgængelig kanal.

Kontogenoprettelse skal være lige så robust som login

Hvis en supportmedarbejder kan gendanne en konto med blot nogle få let gennemskuelige spørgsmål, kan alle forudgående login-kontroller blive gjort virkningsløse. Genoprettelsesprocessen kræver flere former for bevis, begrænsede rettigheder for supportmedarbejdere, fuld logning og supplerende godkendelse i højrisikotilfælde.

5. Kontrol af ændringer i modtagerkonto

At ændre betalingsmodtageren er en handling, der kan omdanne en overtaget konto til et reelt økonomisk tab.

Anbefalede kontroller:

1. gen-autentificering af brugeren;

2. verificering af den nye konto efter en godkendt metode;

3. besked om ændringen via både den gamle og den nye kanal, hvor det er relevant;

4. anvendelse af ventetid eller forstærkede grænser baseret på risiko;

5. blokering af transaktionen, hvis ændringen sker sammen med en ny enhed eller andre usædvanlige tegn;

6. ingen enkelt supportmedarbejder må både foretage og godkende ændringen;

7. opbevaring af historik med maskeret gammel værdi, maskeret ny værdi, hvem der udførte ændringen, og årsagen;

8. placering af transaktioner umiddelbart efter ændringen i et separat overvågningsforløb.

Konkrete tærskler eller ventetider bør ikke offentliggøres i en offentlig artikel, hvis oplysningerne kan hjælpe svindlere med at tilpasse deres adfærd for at omgå kontrollerne.

6. Sikring af pålidelige data om arbejdstid og ansættelsesstatus

EWA-beløbsgrænsen afhænger direkte af kildedataene. Svindelbekæmpelse skal derfor starte, før data kommer ind i platformen (se Hvad er godkendt arbejdstid? og Integration af EWA med tidsregistrering, lønbehandling og ERP).

For medarbejderdata

• brug entydige medarbejder-id'er, der ikke genbruges;

• opdater ikrafttrædelsesdatoer for nyansættelser, orlov og fratrædelse;

• tjek for konflikter mellem HRIS, lønsystem og EWA;

• suspendér transaktionsrettigheder, når status er uklar;

• gennemgå aktive EWA-konti for fratrådte medarbejdere.

For fremmødedata

• medregn kun status, som virksomheden har godkendt;

• gem godkenderen, godkendelsestidspunktet og postens version;

• advar ved arbejdstid, der tilføjes eller ændres efter låsningstidspunktet;

• opdag umulige timetal, overlappende vagter eller pludselige stigninger;

• adskil den, der retter arbejdstid, fra den, der godkender undtagelser;

• genberegn beløbsgrænsen, når kildedataene justeres.

For løn- og beløbsgrænseregler

• versionsstyr beregningsformlerne;

• test, før reglerne tages i brug;

• kræv to-trins-godkendelse ved væsentlige ændringer;

• gem både før- og efter-værdier fuldstændigt;

• undlad direkte rettelser i produktionsdata for at "løse det hurtigt";

• sørg for at kunne genskabe beregningen ud fra kildedata og politikversion.

7. Forebyggelse af dobbelttransaktioner med idempotency

Et typisk scenarie: platformen sender en betalingsordre, men modtager intet svar på grund af timeout. Hvis systemet opfatter det som en fejl og sender en ny ordre, kan medarbejderen modtage beløbet to gange.

Idempotency sikrer, at gentagne afsendelser af samme anmodning kun svarer til ét forretningsresultat. Et velfungerende design kræver:

• en entydig idempotency_key, oprettet af den kaldende part;

• en unik-begrænsning i databasen;

• sammenkædning af nøglen med brugeren, transaktionstypen og anmodningens indhold;

• en opbevaringstid for nøglen, der dækker hele behandlingsforløbet;

• returnering af det oprindelige transaction_id og status, når anmodningen sendes igen;

• afvisning af, at samme nøgle kan følges af et andet beløb eller en anden modtager;

• bevarelse af nøglen ved gentagelse via kø eller efter systemgendannelse.

Idempotency erstatter ikke afstemning. Det forhindrer dobbeltoprettelse på behandlingstidspunktet, mens afstemning opdager uoverensstemmelser, der allerede er opstået mellem EWA, betalingspartneren og payroll/ERP.

8. Håndtering af transaktioner med uafklaret status

En betalingstransaktion har ikke kun status "gennemført" og "mislykket". Der er behov for en mellemtilstand til de tilfælde, hvor ordren er sendt, men det endelige resultat endnu ikke kendes.

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

Når status er UNKNOWN eller tilsvarende:

• hold den tilhørende del af beløbsgrænsen tilbage;

• opret ikke automatisk en ny betalingsordre;

• forespørg status med den oprindelige referencekode;

• advar driftsteamet, hvis den interne tidsfrist overskrides;

• sammenhold med partnerens rapport eller kontoudtog;

• registrér, hvem der har behandlet sagen manuelt, og på hvilket grundlag;

• tilbagefør først beløbsgrænsen, når det er fastslået, at pengene ikke er overført, eller at de er blevet tilbagebetalt.

9. Advarselssignaler om svindel bør kombineres

Et enkeltstående signal er som regel ikke nok til at drage en konklusion. En medarbejder, der skifter telefon, kan for eksempel være helt legitim. Risikoen stiger, når flere signaler optræder samtidigt.

Signaler om konto og enhed

• login fra en ny enhed efterfulgt af ændring af modtagerkonto;

• et usædvanligt højt antal konti på samme enhed;

• gentagne mislykkede autentificeringsforsøg;

• usædvanlige ændringer i enhedsoplysninger;

• login fra geografisk fjerne lokationer inden for en urimelig kort tid;

• en genoprettelsesanmodning efterfulgt af en øjeblikkelig transaktion.

Signaler om arbejdstid og beløbsgrænse

• kraftig stigning i arbejdstid sammenlignet med historik eller vagtplan;

• masse-justeringer af arbejdstid lige før en transaktion oprettes;

• mange poster godkendt af samme person uden for arbejdstid;

• store ændringer i beløbsgrænsen uden en tilsvarende lønbegivenhed;

• data fra en ældre version overskriver nyere data;

• en fratrådt medarbejder får stadig tildelt en beløbsgrænse.

Signaler om transaktioner

• mange anmodninger tæt efter hinanden;

• gentagne transaktioner tæt på loftet;

• ændring af modtager efterfulgt af en anmodning om et stort beløb;

• flere medarbejdere overfører til samme konto;

• gentagne mislykkede transaktioner til flere forskellige modtagerkonti;

• samme betalingsreference optræder i flere transaktioner;

• transaktioner, der afviger fra kontoens normale adfærdsmønster.

Signaler om interne medarbejdere

• tildeling af rettigheder efterfulgt af usædvanlige transaktioner;

• samme person retter data, godkender og behandler undtagelser;

• masseeksport af data uden en arbejdsrelateret begrundelse;

• mange administrative handlinger uden for arbejdstid;

• gentagen tilsidesættelse af advarsler eller ensartede undtagelsesbegrundelser i stort omfang;

• indgreb i konti, der har fælles relationer via enhed, modtagerkonto eller afdeling.

Detaljerede tærskler bør opbevares i interne driftsdokumenter med begrænset adgang.

10. Risikoscoringsmodellen må ikke blive en "sort boks"

Risikoscoren kan understøtte beslutninger om at tillade, kræve yderligere verificering, tilbageholde eller sende til manuel kontrol. Virksomheden skal dog vide, hvilke signaler modellen bygger på, og hvordan fejlmarginen kontrolleres.

Et vejledende beslutningsforløb:

Der bør som minimum følges op på:

• andelen af korrekte advarsler;

• andelen af gyldige personer, der fejlagtigt blokeres;

• behandlingstiden for advarsler;

• værdien af forhindrede tab;

• antallet af oversete advarsler;

• antallet af svindeltransaktioner uden advarsel;

• konsekvenser fordelt på medarbejdergrupper, afdelinger eller enheder.

Anvendes der en machine learning-model, skal ændringer i modellen eller datakilden testes, godkendes, overvåges for model drift og kunne forklares tilstrækkeligt for undersøgelsesteamet. I den indledende fase er et klart regelsæt kombineret med god afstemning ofte lettere at styre end en kompleks model, der mangler solide data.

11. Kontrol af intern svindel

Interne medarbejdere kender processerne og kan besidde lovlige rettigheder (relateret til datasikkerhed og privatliv ved implementering af EWA). Derfor er login-kontrol alene ikke tilstrækkeligt.

Nøgleprincipper:

• adskil den, der opretter, den, der godkender, og den, der afstemmer;

• undgå delte administratorkonti;

• tildel rettigheder afgrænset til juridisk enhed, afdeling og opgave;

• særlige rettigheder skal være tidsbegrænsede og velbegrundede;

• følsomme handlinger kræver to-trins-godkendelse;

• opbevar manipulationssikret log for data- og konfigurationsændringer;

• advar ved masseeksport af data;

• gennemgå rettigheder løbende, og inddrag dem straks ved jobskifte;

• rotation eller obligatorisk fravær for følsomme stillinger, hvor politikken tillader det;

• etablér en whistleblower-kanal og en uafhængig undersøgelsesmekanisme.

Undersøgelsesteamet bør ikke omfatte personer, der er direkte leder for, eller som har interessekonflikter med, den person, der undersøges.

12. Flerdimensional afstemning til opdagelse af tab

Afstemning bør foretages mellem mindst tre kilder (jf. processen for adgang til optjent løn fra tidsregistrering til afstemning):

1. EWA-platformens transaktionsregister;

2. resultater fra banken eller betalingspartneren;

3. godkendte payroll-/ERP-poster eller opgørelser.

Afhængigt af designet kan man også sammenholde arbejdstidsdata, beløbsgrænser og bogføringen.

Uoverensstemmelser, der skal behandles separat

• EWA rapporterer succes, men partneren har ikke bekræftet det;

• partneren rapporterer succes, men EWA har ingen registreret transaktion;

• beløb, gebyr eller modtager stemmer ikke overens;

• en transaktion tilbageføres, men beløbsgrænsen er ikke opdateret;

• transaktionen er gennemført, men mangler i payroll/ERP;

• én betalingsreference er knyttet til flere transaktioner;

• én transaktion optræder to gange i afstemningsfilen;

• arbejdstidsdata justeres, efter at transaktionen er opstået.

Hver uoverensstemmelse skal have et sags-id, en ansvarlig person, en prioritet, dokumentation, en intern frist og et endeligt resultat. Slet ikke en registrering af en uoverensstemmelse, blot fordi tallene er blevet rettet.

13. Proces for håndtering af advarsler og undersøgelser

flowchart TD
    A["Oprettelse af advarsel"] --> B["Screening og prioritering"]
    B --> C["Beskyttelse af konto og transaktion"]
    C --> D["Indsamling af beviser"]
    D --> E["Konklusion og behandling"]
    E --> F["Udbedring af årsag"]
    F --> G["Måling af effekt og opdatering af regler"]

Trin 1: Screening

Verificér, om advarslen har fuldstændige data, hvilken status transaktionen har, og om skaden fortsat kan udvikle sig.

Trin 2: Begrænsning af skade

Afhængigt af bemyndigelsen kan man tilbagekalde sessionen, midlertidigt spærre kontoen, tilbageholde en ikke-udbetalt transaktion, annullere en ændring af modtagerkonto eller stoppe et integrationsflow. Foranstaltningen skal stå i et rimeligt forhold til situationen og kunne omgøres, hvis advarslen viser sig at være forkert.

Trin 3: Bevarelse af beviser

Registrér logs, dataversioner, konfiguration, transaktions-id, betalingsreference, ændringshistorik og supportkommunikation. Ret aldrig direkte i de oprindelige beviser.

Trin 4: Årsagsanalyse

Skeln mellem kontoovertagelse, intern svindel, datafejl, systemfejl og misbrug af politik. Overvej både tekniske årsager og svagheder i processen.

Trin 5: Behandling og notifikation

Følg kontrakten, interne regler og lovkrav. Konkludér ikke offentligt eller iværksæt disciplinære sanktioner på egen hånd, før den relevante verificeringsproces er afsluttet.

Trin 6: Forebyggelse af gentagelse

Ret regler, rettighedsstyring, kildekode, processer og undervisningsmateriale, og følg op på effekten efter ændringen.

14. Beskyttelse af medarbejdere ved falske alarmer

Svindelbekæmpelse bør ikke blive en barriere, der forhindrer legitime medarbejdere i at få adgang til deres ydelser rettidigt.

Virksomheden bør have:

• en klar besked om, at transaktionen er under verificering, uden at blive mærket "svindel", før der er draget en konklusion;

• en let tilgængelig klagekanal;

• et sags-id og en behandlingsstatus;

• interne frister afhængigt af konsekvensens omfang;

• en mekanisme til hurtig oplåsning eller genoprettelse, når legitimiteten er bekræftet;

• en bemyndiget person til at gennemgå undtagelser;

• måling af andelen af falske blokeringer for hver enkelt regel;

• en gennemgang af, om reglerne uretmæssigt stiller en bestemt brugergruppe dårligere.

Supportteamet bør ikke have adgang til flere data, end der er nødvendigt. Efterforskningsoplysninger skal have særskilt adgangsstyring for at beskytte privatlivet og undgå at afsløre svindelbekæmpelsesreglerne.

15. Risikostyringsnøgletal, der bør følges

Nøgletallene skal have ensartede definitioner. "Forhindret svindel" bør kun registreres, når der er dokumentation for det, så man undgår at opblæse enhver afvist transaktion til et forhindret tab.

16. Tjekliste for svindeltest før go-live

Identitet og konto

• [ ] Aktivering med en anden persons medarbejder-id afvises.

• [ ] Gentagne forsøg eller automatisering udløser passende advarsler/begrænsninger.

• [ ] Skift af enhed og kontogenoprettelse kræver et passende niveau af verificering.

• [ ] Gamle sessioner tilbagekaldes efter ændring af login-oplysninger.

• [ ] En supportmedarbejder kan ikke alene omgå kontrollerne.

Modtagerkonto

• [ ] Ændring af konto kræver gen-autentificering.

• [ ] Besked om ændringen sendes via den rette kanal.

• [ ] Transaktioner umiddelbart efter ændringen behandles efter risikopolitikken.

• [ ] Det opdages, hvis samme modtagerkonto optræder hos flere medarbejdere.

• [ ] Medarbejdere uden rettigheder kan hverken se eller redigere de fuldstændige data.

Arbejdstid, løn og beløbsgrænse

• [ ] Ikke-godkendt arbejdstid udløser ikke en beløbsgrænse, hvis politikken kræver godkendelse.

• [ ] Senere rettelser af arbejdstid genberegner beløbsgrænsen korrekt.

• [ ] Ældre data overskriver ikke en nyere version.

• [ ] Fratrådte medarbejdere suspenderes i overensstemmelse med ikrafttrædelsesdatoen.

• [ ] Ændringer i formlen har godkendelse samt en før/efter-log.

Transaktioner og betaling

• [ ] Gentagen afsendelse med samme idempotency_key medfører ikke dobbelt udbetaling.

• [ ] Samme nøgle med et andet beløb afvises.

• [ ] Timeout skaber en uafklaret status uden automatisk afsendelse af en ny ordre.

• [ ] Forfalskede eller gentagne callbacks afvises.

• [ ] Tilbageførte transaktioner opdaterer beløbsgrænsen efter den godkendte proces.

Intern svindel

• [ ] Én person kan ikke selv oprette, godkende og afstemme en undtagelse.

• [ ] Midlertidige rettigheder udløber automatisk.

• [ ] Masseeksport af data skaber log og advarsel.

• [ ] Administrative handlinger kan ikke slettes fra det almindelige revisionsspor.

• [ ] Rettigheder for medarbejdere, der skifter job eller fratræder, inddrages rettidigt.

Afstemning og undersøgelse

• [ ] Manglende transaktion i en af de tre kilder skaber en uoverensstemmelsessag.

• [ ] Hver sag har en ejer og en behandlingshistorik.

• [ ] Beviser bevares og redigeres ikke direkte.

• [ ] Fejlagtigt spærrede brugere har adgang til en klagekanal og genåbning.

• [ ] Øvelser med scenarier for kontoovertagelse og fejlbehæftede transaktioner er gennemført.

17. Retlig ramme og databeskyttelse ved svindelbekæmpelse

Svindelbekæmpelse kan gøre brug af data om konti, enheder, adfærd og transaktionshistorik. Virksomheden skal derfor samtidig sikre et klart behandlingsformål, relevante data og medarbejdernes privatliv.

I Vietnam træder loven om beskyttelse af personoplysninger nr. 91/2025/QH15 i kraft den 1. januar 2026. Bekendtgørelse 356/2025/NĐ-CP, der ligeledes træder i kraft den 1. januar 2026, fastsætter nærmere regler for og gennemførelsesforanstaltninger til loven. Afhængigt af sin rolle og sit betalingsflow skal virksomheden desuden overveje bekendtgørelse 52/2024/NĐ-CP om kontantløse betalinger samt relevante brancheregler.

At overvåge svindel er ikke det samme som at indsamle alle mulige data. Hvert signal skal knyttes til et formål, et nødvendighedsniveau, en opbevaringsperiode, adgangsrettigheder samt en proces for forklaring og behandling af medarbejdernes henvendelser. Konkrete juridiske konklusioner skal gennemgås ud fra den faktiske arkitektur og de faktiske kontrakter.

Inden for informationssikkerhedsstyring giver NIST Cybersecurity Framework 2.0 en tilgang baseret på funktionerne Govern, Identify, Protect, Detect, Respond og Recover. OWASP Application Security Verification Standard kan danne grundlag for test af applikationers og API'ers tekniske kontroller. Disse er referencerammer og erstatter ikke virksomhedens juridiske forpligtelser eller egen risikovurdering.

Konklusion

Effektiv risikostyring i EWA bygger på flere lag af kontroller: pålidelige kildedata, korrekt identifikation, verificerede ændringer af modtager, transaktioner med idempotency, klare betalingsstatusser, adskilte interne rettigheder, forklarlige advarsler og afstemning helt ned på transaktionsniveau.

Målet er ikke at blokere så meget som muligt, men at forhindre tab i rette tid, samtidig med at legitime medarbejdere beskyttes. Hvis virksomheden overvejer at implementere adgang til optjent løn, bør den forberede risikoscenarier, et rettighedsdiagram og de UAT-situationer, der skal testes, og derefter undersøge adgang til optjent løn for virksomheder for at anmode om dokumentation for transaktionskontrol, afstemning og et passende pilotomfang.

Referencer

• Lov om beskyttelse af personoplysninger nr. 91/2025/QH15

• Bekendtgørelse 356/2025/NĐ-CP om gennemførelse af loven om beskyttelse af personoplysninger

• Bekendtgørelse 52/2024/NĐ-CP om kontantløse betalinger

• NIST Cybersecurity Framework

• OWASP Application Security Verification Standard

• OWASP Logging Cheat Sheet

---

Forfatter: Tran Van Tai — Assistent for viceadministrerende direktør, ansvarlig for udviklingsstrategi, Nhan Kiet Manpower Supply Co., Ltd.

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