En bank, et forsikringsselskab eller en pensionskasse vil gerne købe jeres produkt, og kontraktudkastet er pludselig dobbelt så langt som normalt. Årsagen er ofte DORA, EU-forordningen om finanssektorens digitale modstandskraft, som har gældt siden 17. januar 2025. Den retter sig mod finansielle virksomheder, men art. 30 bestemmer, hvad der skal stå i deres aftaler med leverandører af IT-tjenester. Dermed lander kravene hos jer. Her ser vi på, hvad de betyder for produktet og arkitekturen. Selve aftaleteksten er et spørgsmål til advokat.
Først: hvor vigtig er I for kunden?
DORA kalder jer en tredjepartsudbyder af IKT-tjenester, altså en virksomhed, der leverer digitale tjenester eller datatjenester løbende. En SaaS-løsning falder naturligt ind under det. Forordningen stiller grundkrav til alle sådanne aftaler og ekstra krav, hvis kunden bruger tjenesten til det, DORA kalder en kritisk eller vigtig funktion, dvs. en funktion, hvis svigt i væsentlig grad kan ramme kundens tjenester, resultater eller tilladelse.
Det første spørgsmål til kunden er derfor: betragter I vores tjeneste som understøttelse af en kritisk eller vigtig funktion? Det er kundens vurdering, og den afgør, hvor tungt det bliver. Et værktøj til intern mødeplanlægning er et andet tilfælde end et system, der indgår i kundens betalinger. Hvilke finansielle virksomheder der er omfattet, står i er vi omfattet af DORA?, og kundens side af aftalen er gennemgået i kontraktkrav efter DORA.
Grundkravene set fra produktet
Art. 30, stk. 2, gælder alle aftaler om IKT-tjenester. Fem punkter har tekniske følger:
Hvor tjenesten leveres, og hvor data behandles. Aftalen skal angive stederne, og kunden skal have besked forud for ændringer. I skal altså kende alle regioner og alle tjenester, data kommer forbi, og et skift af region eller underleverandør skal kunne varsles. Svaret bygger på det samme overblik som hvor ligger data?.
Underentreprise. Aftalen skal sige, om dele må lægges ud til underleverandører. Hver cloudtjeneste, I bruger, er relevant her, så en oversigt over dem bør ligge klar i arkitekturbeskrivelsen.
Adgang, genopretning og tilbagelevering af data. Kunden skal kunne få sine data tilbage ved opsigelse, insolvens eller afvikling hos jer. Det kræver en eksport, der virker for én kunde ad gangen og i et format, kunden kan bruge. Hvis data ligger blandet sammen uden en klar adskillelse, er det opgaven at løse.
Serviceniveau. Aftalen skal beskrive det, og I skal kunne måle det, se SLA og oppetid.
Bistand ved IKT-hændelser. I skal hjælpe kunden ved hændelser, enten uden ekstra betaling eller til en pris, der er fastsat på forhånd. Kunden har selv korte frister over for tilsynet ved større hændelser, så I skal kunne levere oplysninger hurtigt. Overvågning og en vagtordning, der kan svare, er derfor en del af produktet.
De ekstra krav ved kritiske eller vigtige funktioner
Art. 30, stk. 3, lægger flere krav oveni. Disse har størst betydning for arkitektur og organisation:
- Præstationsmål. Præcise mål, der kan følges, og varsler, når noget kan påvirke leverancen. Det stiller krav til målinger og rapportering.
- Beredskab, som testes. I skal have beredskabsplaner og sikkerhedsforanstaltninger, og de skal testes. En plan, der aldrig er prøvet, holder ikke her. Begynd med kan I genskabe produktet?.
- Adgang, inspektion og revision. Kunden, en udpeget tredjepart og myndigheden skal have ret til løbende overvågning, adgang, inspektion og revision. Forbered et svar på, hvordan det kan ske uden at røre andre kunders data.
- Deltagelse i avanceret test. Kunden kan være underlagt trusselsbaseret test af sine kritiske systemer, og aftalen skal så sige, hvordan I deltager. Bliver det aktuelt, kræver det særlig planlægning, for I har andre kunder på samme installation.
- Exit med overgangsperiode. Aftalen skal indeholde en exitstrategi med en obligatorisk overgangsperiode. Produktet skal altså kunne køre videre, mens kunden flytter.
Sådan kan I forberede jer
Hvis finansielle kunder er en del af planen, kan I gøre meget, før den første kontrakt kommer:
- Lav en liste over underleverandører og regioner, og hold den ajour.
- Prøv en fuld dataudlevering for én kunde.
- Test gendannelse, og skriv resultatet ned.
- Lav en kort beskrivelse af, hvordan kunder og revisorer kan få indsigt, uden at andre kunders data bliver berørt.
- Beslut, hvem der svarer kunden ved en hændelse, og hvordan.
Punkterne overlapper meget med almindelige enterprise-krav, og det meste gavner også jeres andre kunder. Vurder dog, om segmentet er kravene værd. Finanskunder kan fylde meget i et lille team, og det er en beslutning for ledelsen, før salget går i gang. Kunden har desuden pligt til at føre et register over sine IKT-aftaler, så I skal regne med at blive bedt om oplysninger til det.
Forordningen er kundens regelsæt. Hvad I selv forpligter jer til, afgøres af kontrakten, og den skal en advokat med kendskab til området læse.
Det skal I lade være med
- At underskrive en revisionsret uden at vide, hvordan den kan udføres · den skal kunne opfyldes uden at åbne for andre kunders data.
- At sige ja til alt, fordi navnet er stort · hvert punkt skal kunne leveres af jeres team.
- At love en region, I ikke selv kontrollerer · kontrollér supporttjenester og logning også.
Det skal I kræve af den eksterne
- ☐ En gennemgang af kravene med tekniske konsekvenser for produktet.
- ☐ En prøve på dataudlevering for én kunde.
- ☐ Et overblik over underleverandører og placering af data.
- ☐ En vurdering af, om segmentet passer til jeres størrelse.
- ☐ Klar henvisning til advokat, hvor det er kontraktens ordlyd, der afgør det.
Kilder
- Forordning (EU) 2022/2554 (DORA): art. 3, art. 28 og art. 30.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Kundens spørgeskema om produktet · Jeres SaaS skal kunne forlades
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
