DORA-forordningen for fintech: IKT- og tredjepartsrisiko

Hva det er

DORA er en forordning, så den gjelder direkte i medlemsstatene, støttet av tekniske standarder. Den bygger på fem pilarer. IKT-risikostyring krever et dokumentert rammeverk som dekker identifisering, beskyttelse, deteksjon, respons og gjenoppretting, læring og kommunikasjon, der ledelsesorganet har det endelige ansvaret. Håndtering av IKT-relaterte hendelser krever klassifisering av hendelser og rapportering av alvorlige hendelser til kompetent myndighet innen fastsatte frister. Testing av digital operasjonell motstandsdyktighet krever et testprogram som står i forhold til enheten; visse enheter utpekt av myndighetene må i tillegg gjennomgå trusselbasert penetrasjonstesting etter egne regler. Styring av IKT-tredjepartsrisiko krever et informasjonsregister over alle avtaler om IKT-tjenester, risikovurdering før avtaleinngåelse, særskilte kontraktsbestemmelser og exitstrategier. Deling av informasjon om trusler oppmuntres innenfor betrodde fellesskap. Proporsjonalitet gjelder gjennomgående, og en definert liste over mindre enheter, som små og ikke-sammenkoblede verdipapirforetak og visse unntatte betalingsforetak og e-pengeforetak, kan bruke det forenklede rammeverket for IKT-risikostyring i artikkel 16.

Hvem det er for

Denne guiden er rettet mot:

• Betalings-, e-penge-, kryptoeiendels-, verdipapir- og andre konsesjonspliktige fintech-selskaper som faller inn under DORAs liste over finansielle enheter
• Ansvarlige for etterlevelse, risiko og teknologi som bygger opp eller gjennomgår et DORA-program
• IKT-leverandører og programvareleverandører som betjener finansielle enheter og mottar kontraktskrav knyttet til DORA
• Gründere som må forklare DORA-forventningene for investorer eller styrer

Hva det hjelper med å klarlegge

En gjennomgang av pilarene bidrar til å avklare:

• Hvilke kritiske eller viktige funksjoner virksomheten støtter, og hvilke IKT-systemer de er avhengige av
• Om tredjepartsregisteret og kontraktene inneholder det DORA forventer
• Hva testprogrammet for motstandsdyktighet bør omfatte gitt størrelse og risikoprofil
• Hvor det mangler teknisk dokumentasjon som underbygger styringsdokumentene

Hva er inkludert

• Styring: bekreft at ledelsesorganet godkjenner og fører tilsyn med rammeverket for IKT-risiko, og dokumenter roller
• Kartlegging av eiendeler og funksjoner: identifiser kritiske eller viktige funksjoner og systemene, dataene og leverandørene bak dem
• Beskyttelse og deteksjon: gjennomgå tilgangskontroll, MFA, logging og overvåking for disse systemene
• Hendelseshåndtering: definer klassifiseringskriterier, beslutningstakere og arbeidsflyt for rapportering av alvorlige hendelser
• Kontinuitet: test mål for sikkerhetskopiering, gjenoppretting og gjenopprettingstid for kritiske funksjoner
• Testprogram: planlegg sårbarhetsvurderinger, scenariotester og penetrasjonstester i forhold til risiko
• Tredjepartsregister: list opp alle IKT-avtaler med funksjon, data, lokasjon og detaljer om underleveranser
• Kontrakter: kontroller at påkrevde bestemmelser finnes, som tjenestebeskrivelser, datalokasjon, revisjons- og tilgangsrettigheter, støtte ved hendelser og vilkår for avslutning
• Exitstrategier: dokumenter hvordan dere ville gå bort fra en kritisk leverandør
• Konsentrasjonsrisiko: noter hvor flere kritiske funksjoner er avhengige av én leverandør

Hva er ikke inkludert

• Juridisk rådgivning eller regulatorisk tolkning for deres konkrete konsesjon
• Trusselbasert penetrasjonstesting under et rammeverk utpekt av tilsynsmyndigheten
• Innsending av hendelsesrapporter eller registre til myndigheter
• Sertifisering eller godkjenning av etterlevelse

Når skal den velges

Bruk denne guiden når dere forbereder eller gjennomgår DORA-programmet, før dere fornyer kontrakter med viktige IKT-leverandører, og før den årlige testplanen fastsettes. Hvis kompetent myndighet har gitt egen veiledning eller anmodninger, følg dem først. Leverandører som betjener finansielle enheter, bør bruke delen om tredjeparter til å forutse forespørsler om kontrakter og revisjon. Denne artikkelen er generell informasjon og ikke juridisk rådgivning.

Vår tilnærming

De fleste fintech-selskaper opplever at dokumentasjonen finnes, men at det tekniske grunnlaget er tynt. Start med å kartlegge kritiske funksjoner mot systemer og leverandører; denne ene øvelsen driver registeret, testomfanget og kontinuitetsplanleggingen. Samle deretter bevis på hvordan sentrale kontroller faktisk fungerer. Tjenesten vår Security Baseline Review kan gi en skriftlig oversikt over avtalte eiendeler, gradert etter alvorlighet, som viser hvor konfigurasjon og tilgangskontroller står. For testing av applikasjoner og API-er innenfor testprogrammet for motstandsdyktighet arbeider tjenesten vår Penetration Testing ut fra skriftlig omfang og autorisasjon og leverer funn gradert etter alvorlighet, med ny test av avtalte funn der det er inkludert. Begge utfyller trusselbasert testing utpekt av tilsynsmyndigheten, juridisk rådgivning og godkjenning av etterlevelse, som følger egne prosesser. Datér hvert bevis og knytt det til funksjonen det støtter, slik at gjennomganger i ledelsen og spørsmål fra tilsynet kan besvares ut fra dokumentasjon i stedet for hukommelse.

Security Baseline Review

Ofte stilte spørsmål

Beslektede artikler