DORA og tredjepartsrisiko: hva regulerte foretak må gjøre

DORA er ikke en frist som nærmer seg. Den passerte 17. januar 2025. Siden da forventer Finanstilsynet at finansforetak i EU og EØS har reell kontroll på risikoen fra ICT-leverandørene sine, ikke bare på papiret. Banker, forsikringsselskap, verdipapirforetak, betalingsforetak og deres leverandører er omfattet, og for norske foretak er regelverket innlemmet i EØS-avtalen.

Den vanskeligste delen er sjelden de egne systemene. Det er det du ikke ser: en underleverandør som ikke står på noen liste, en sikkerhetskontroll revisjonsrapporten forutsetter at du har på plass, men som ingen har sjekket, en skyleverandør som er blitt kritisk uten at noen oppdaterte vurderingen. Det er i de hullene en hendelse eller et tilsyn treffer. DORA kapittel 5 (artikkel 28 til 30) handler om å lukke dem, systematisk og dokumentert.

Leverandørstyring er en livssyklus, ikke et engangstiltak

DORA behandler tredjepartsrisiko som noe som følges gjennom hele forholdet til en leverandør, fra du vurderer å inngå en avtale til du eventuelt avvikler den.

Hver fase har sine krav, men poenget er sammenhengen: en kontrakt uten exit-vilkår, eller en attestasjon som aldri følges opp, bryter kjeden uansett hvor god resten er.

Kritiske og ikke-kritiske leverandører er ikke det samme

DORA skiller tydelig mellom leverandører som støtter “kritiske eller viktige funksjoner” og de som ikke gjør det. Kritiske leverandører får strengere krav: grundigere due diligence, hyppigere oppfølging, obligatoriske og testede exit-planer, og mer detaljerte kontraktsbestemmelser.

Kritikalitet avgjøres normalt gjennom en Business Impact Analysis, og det er her mange forenkler for mye. Ta en leverandør som drifter kjernebanksystemet: faller den bort i en time, stopper betalinger. Det er kritisk, rødt. Den samme leverandøren kan også levere et internt intranett som tåler en dags nedetid uten reell konsekvens, og da er den ikke kritisk. Poenget er at kritikalitet følger funksjonen, ikke leverandørnavnet, og må vurderes per tjeneste.

De fleste ender opp med en slik trinnvis modell, så vurderingene blir konsistente på tvers av organisasjonen i stedet for å avhenge av hvem som gjorde dem.

Registeret over informasjon

DORA krever at foretak fører et register over alle ICT-tredjepartsavtaler og rapporterer det til tilsynsmyndigheten, i et format spesifisert gjennom de tekniske standardene fra de europeiske tilsynsmyndighetene. Registeret skal blant annet inneholde leverandørens navn, land, hvilken funksjon tjenesten støtter, kritikalitet, og kontraktsdetaljer, helt ned til underleverandører som støtter kritiske funksjoner.

Det høres ut som en administrativ øvelse, men det er her mange faller fra. Registeret er bare så godt som dataene bak det, og de dataene endrer seg: leverandører bytter underleverandører, tjenester skifter kritikalitet, nye avtaler inngås i forretningsenheter compliance ikke hører om før i ettertid. Et register som ble fylt ut ved onboarding og så stod stille, er ikke et register tilsynet stoler på. Dette er også grunnen til at registeret bør bygges på den samme leverandørgjennomgangen du gjør ellers, ikke som et løsrevet regneark ved siden av.

Hva tilsynet ser etter, og hva som står på spill

Et tilsyn ser ikke bare etter at dokumentene finnes, men at de henger sammen: at registeret er komplett og oppdatert, at kritikalitet er begrunnet og ikke gjettet, at kontraktene for kritiske leverandører faktisk inneholder det artikkel 30(3) krever, at exit-planene er testet, og at attestasjonene er gjennomgått og ikke bare arkivert.

Konsekvensene er reelle. Finanstilsynet kan kreve utbedring innen frist, gi pålegg, og i ytterste konsekvens begrense aktivitet. På EU-nivå kan tilsynsmyndighetene utpeke kritiske ICT-tredjeparter, typisk de store skyleverandørene, til direkte overvåking. Men den vanligste og mest ubehagelige “straffen” er enklere: et gap som dukker opp midt i en hendelse eller en revisjon, et gap du burde ha funnet selv, lenge før noen andre gjorde det.

De vanligste hullene

Når vi ser på leverandørgjennomganger i regulerte foretak, går de fleste i noen av de samme fellene.

• Underleverandørlisten mangler eller er utdatert. Databehandleravtalen viser til underleverandører, men en oppdatert oversikt finnes ikke. Deler av kjeden er rett og slett usynlig.
• Attestasjonene leses aldri. En ISAE 3402- eller SOC 2-rapport på mellom 80 og 200 sider blir arkivert i stedet for gjennomgått. Da overses ofte de komplementære brukerkontrollene (CUECs): sikkerhetstiltakene rapporten forutsetter at du som kunde har på plass selv. En enkelt oversett CUEC kan være nettopp kontrollen som mangler den dagen noe svikter.
• Tilgangsgjennomganger gjøres for sjelden. Bransjepraksis og ISO 27001 Annex A peker mot kvartalsvise gjennomganger av privilegert tilgang, men mange gjør det årlig eller sjeldnere.
• Exit-planer som aldri er testet. Planen finnes på papir, men er aldri kjørt som en øvelse.
• Registeret vedlikeholdes ikke etter onboarding, mens leverandørbildet endrer seg under det.

Problemet er sjelden vilje. Det er volum. En ISAE 3402-rapport på 150 sider tar timer å lese grundig, og med titalls leverandører rekker ingen det. Så gapene blir liggende, usett, til noen andre finner dem. Det er nettopp dette VendorGuard er bygget for: vi leser hele rapporten på rundt 60 sekunder og løfter frem funnene som ellers gjemmer seg, fra manglende underleverandørliste til oversette CUECs og kontroller som ikke dekker det du faktisk trenger. Gjennomgangen blir noe som skjer, ikke noe som står igjen på to-do-listen.

Slik kommer du i gang

Du trenger ikke å løse alt på én gang. En fornuftig rekkefølge er:

1. Kartlegg kritikalitet først. Identifiser hvilke leverandører som støtter kritiske eller viktige funksjoner, og prioriter gjennomgangen deretter. Det er her risikoen og kravene er størst.
2. Sett en konsistent kritikalitetsmodell som hele organisasjonen bruker likt.
3. Etabler en rytme for å lese attestasjoner, ikke bare samle dem. Fang opp CUECs og vurder om kontrollene faktisk dekker behovet ditt. Du kan lese mer om forskjellen på ISAE 3402 og SOC 2, og om hvordan du leser en slik rapport.
4. Behandle registeret som et levende dokument som oppdateres når leverandører, underleverandører eller kritikalitet endrer seg.

DORA er ikke en sjekkliste du krysser av én gang. Det er en måte å jobbe med leverandørrisiko på kontinuerlig, og fristen for å begynne var i fjor. Foretakene som kommer godt ut, er de som har gjort gjennomgangen til en rutine i stedet for et årlig brannslukningsprosjekt.

---

Denne artikkelen er ment som generell veiledning, ikke juridisk rådgivning. Konkrete vurderinger bør gjøres sammen med kvalifisert compliance- og juridisk kompetanse.