For the complete documentation index, see /llms.txt. Markdown version of this page: /insights/compliance/verktoy-for-dora-etterlevelse.md.
Compliance ↗

Hva DORA-programvare dekker, og hva styret må avgjøre

Programvare kan holde DORA-registeret og loggene fra hendelsene. Den kan ikke avgjøre hva som er kritisk, eller skrive exit-strategien.

DORA Tooling, FM CyberSecurity forsidegrafikk

Dere kan kjøpe programvare som leverer DORA-registeret i tide. Dere kan ikke kjøpe noe som avgjør hvilke leverandører som er kritiske. Den avgjørelsen ligger hos styret, og Finanstilsynet kommer til å spørre hvordan dere kom fram til den.

I compliance-møter med norske finansforetak i år åpner samtalen nesten alltid med hvilket produkt de bør kjøpe. Spørsmålet er rimelig, men svaret er ubehagelig. Omtrent halvparten av det DORA ber om, er dokumentasjonsarbeid, og programvare gjør dokumentasjonsarbeid bedre enn mennesker. Den andre halvparten er skjønn, og ingen leverandør signerer på skjønn.

Feil fordeling koster dere omarbeid lenge før den koster dere gebyr. Norske foretak måtte rapportere registeret over IKT-tjenesteavtaler til Finanstilsynet innen 13. mars 2026, og filene gikk videre til Den europeiske banktilsynsmyndigheten (EBA) innen 31. mars. Flere kom i retur som avvist. En avvist fil skyldes sjelden programvaren. Som regel er det ingen som har ansvaret for dataene inni den. Har dere ikke kartlagt hvilke plikter som gjelder ennå, er DORA-sjekklisten for finansforetak et billigere sted å begynne.

Dette dekker DORA-programvare godt

Programvare dekker de delene av DORA som handler om registre, skanning og lagret bevis. Tre av dem er verdt å betale for.

Informasjonsregisteret kommer først. Registeret lister hver eneste IKT-tjenesteavtale dere har, rapportert i et fast EU-format (DORA artikkel 28(3), med formatet satt i gjennomføringsforordning (EU) 2024/2956). Et regneark tar et lite foretak gjennom første rapporteringsrunde. I gjennomgangene jeg har kjørt, slår regnearket sprekker i runde to, når fornyelser, underleverandører og koblingen mellom avtale og funksjon flytter seg uavhengig av hverandre. Selve rapporteringsmekanikken tar vi for oss i artikkelen om DORA-revisjon og rapporteringskrav.

Oversikt over verdier og sårbarhetshåndtering kommer nummer to. DORA ber dere identifisere alle kilder til IKT-risiko og alle informasjons- og IKT-verdier løpende (artikkel 8(2) og 8(3)). Tenable kobler sin egen DORA-veiledning til nøyaktig de to leddene, i tillegg til artikkel 16(1)(d) om å oppdage avvik, i dokumentasjonen sin om verdikartlegging under DORA. Påstanden holder: plattformen finner verdier og graderer svakhetene deres. Etterlevelse gir den dere ikke. Testplikten som ligger like ved, dekker vi i DORA og løpende penetrasjonstesting.

Deteksjon, respons og dokumentasjon fra hendelser kommer nummer tre. Dere har fire timer fra dere klassifiserer en hendelse som alvorlig til varselet skal ligge hos Finanstilsynet, og aldri mer enn 24 timer fra dere ble kjent med hendelsen (delegert forordning (EU) 2025/301). Tidslinjen kan ikke settes sammen i time tre. CrowdStrike holder deteksjonsdata søkbare i årevis og rapporterer på dem, som gir råmaterialet varselet bygges av. Hva dere gjør med råmaterialet, står i DORA, kontinuitet og beredskapsplaner.

Dette avgjør ingen DORA-plattform for dere

Fire plikter blir liggende hos mennesker. Mer programvare flytter ingen av dem.

Vurderingen av hva som er kritisk, kommer først. Før dere signerer en IKT-avtale, skal dere vurdere om den støtter en kritisk eller viktig funksjon, om den forsterker konsentrasjonsrisikoen, og om leverandøren tåler en aktsomhetsvurdering (artikkel 28(4)). En plattform lagrer vurderingen. Noen hos dere må fortsatt gjøre den, og forsvare den overfor tilsynet.

Styrets ansvar kommer nummer to. DORA legger det endelige ansvaret for IKT-risiko på styret, og forventer at styremedlemmene holder kunnskapen ved like gjennom opplæring (artikkel 5). Ingen innkjøpsordre flytter det ansvaret.

Exit-strategien kommer nummer tre. For leverandører som står bak en kritisk eller viktig funksjon, vil DORA ha en dokumentert exit-plan som er testet og gjennomgått, med et navngitt alternativ og en overgangsplan (artikkel 28(8)). “Vi ville flyttet til en annen leverandør” er en setning, ikke en plan.

Klassifiseringen på dagen kommer nummer fire. EU-reglene setter kriteriene og vesentlighetsgrensene for en alvorlig hendelse (delegert forordning (EU) 2024/1772), men et menneske bruker dem mens hendelsen fortsatt pågår og halve bildet mangler. Kaller dere det for sent, ryker firetimersfristen. Kaller dere alt alvorlig, bruker dere året på å sende støy.

Beslutningen styret skal ta

Bestem hvem som har ansvaret for DORA-dataene før dere bestemmer hva dere skal kjøpe. Sett navn på den som svarer for registeret, den som tar kritikalitetsvurderingen på en ny leverandør, og den som klassifiserer en hendelse som alvorlig klokken to om natten. Kjøp deretter verktøy som betjener de tre rollene. Foretak som kjøper først, sitter gjerne igjen med en lisens og et halvtomt register.

Se hvem FM CyberSecurity er og hva vi er sertifisert til å levere på om oss-siden. Eller avtal 30 minutter med Johan Vorgaard om hvor deres egen fordeling går, gjennom DORA-rådgivningen vår.

FAQ

Finnes det en DORA-løsning som dekker hele regelverket?

Nei. Produkter dekker pliktene som handler om dokumentasjon og logging godt: informasjonsregisteret, oversikt over verdier, sårbarhetshåndtering, hendelseslogg og lagring av bevis. Pliktene som krever en avgjørelse, altså kritikalitet, styreansvar, exit-planlegging og klassifisering av hendelser, er ikke funksjoner i et produkt. Lover en leverandør full DORA-dekning, beskriver de sitt eget omfang og ikke regelverkets.

Trenger vi et eget verktøy for informasjonsregisteret?

Det kommer an på antall avtaler og hvor ofte leverandørbildet endrer seg. Foretak med en kort og stabil liste over IKT-avtaler klarer de første rundene fra et kontrollert regneark. Når underleverandører og koblingen mellom avtale og funksjon begynner å flytte seg mellom rapporteringsrundene, koster regnearket mer i avstemming enn verktøyet koster i lisens.

Kan IKT-leverandøren vår klassifisere en hendelse som alvorlig på våre vegne?

Nei. Plikten til å klassifisere og rapportere ligger hos finansforetaket. Leverandøren kan gi dere tidslinjen, de tekniske detaljene og tallene for påvirkning, og en god leverandør gjør nettopp det. Avgjørelsen om at hendelsen er alvorlig, og varselet til Finanstilsynet, blir liggende hos dere.

Blir vi DORA-etterlevende av å kjøpe Tenable eller CrowdStrike?

Nei, og ingen av leverandørene påstår det. Tenable dekker kartlegging av verdier og sårbarhetshåndtering, som kobler mot kravene om identifisering i artikkel 8. CrowdStrike dekker deteksjon, respons og det lagrede beviset dere bygger en hendelsesrapport på. Begge er verktøy inn i et DORA-program dere fortsatt må kjøre selv.

Skrevet med AI-assistanse, gjennomgått og redigert av Johan Vorgaard og FM CyberSecurity-redaksjonen.

← Tilbake til all innsikt
Spørsmål eller forespørsel? hello@fmcybersecurity.com Kontakt oss →