DORA rammer også jer: sådan undgår du at miste finans-kunderne på målstregen

Tre ting først:

1) Hvis du leverer software, drift eller konsulenter til banker og forsikring, bliver du med stor sandsynlighed ramt af DORA-krav gennem dine kunders kontrakter. Ikke kun “de store”.

2) Det, der afgør, om du virker professionel eller kaotisk i kundens øjne, er ikke, om du er 100 % perfekt compliant, men om du har et gennemtænkt sæt svar, dokumenter og kontroller klar.

3) Du kan komme fra 0 til et brugbart DORA readiness kit på 6 uger, hvis du arbejder fokuseret og ikke forsøger at bygge en mini-bankregulering ind i din egen virksomhed.

Resten af artiklen folder de tre pointer ud: hvad DORA betyder set fra leverandørsiden, hvad dine finans-kunder typisk vil kræve, og hvordan du konkret bygger et genbrugeligt svarbibliotek og dokumentpakke, der gør livet lettere for både salg, kundesucces og it.

Hvad er DORA, når man ikke er bank, men leverandør?

DORA (Digital Operational Resilience Act) er EU-regulering, der skal gøre finanssektoren mere digitalt robust. Fokus er på, at finansielle virksomheder skal kunne tåle it-nedbrud, cyberangreb og leverandørfejl uden at kundernes penge og data ryger ud over kanten.

Det formelle ansvar ligger hos de finansielle virksomheder. De bliver målt og vejet af tilsynet. Men en stor del af deres digitale hverdag kører på jeres platforme, jeres driftsmiljø og jeres folk. Derfor bliver presset på jer.

Det mærker man typisk sådan her:

En kunde, der plejer at sende en standard-IT-sikkerhedstjekliste på 20 spørgsmål, vender pludselig tilbage med et regneark på 180 linjer, hvor halvdelen handler om hændelsesrapportering, exit-planer, test af beredskab og kontrol af jeres underleverandører. Deadlinen for svar er 5 arbejdsdage. Og salget står på pause, til I har afleveret noget, der virker overbevisende.

Set fra leverandørsiden er DORA derfor mindre jura og meget mere struktur i dokumentation, kontroller og svar. Hvis I selv får styr på det, bliver det markant lettere at arbejde med finanssektoren som kundegruppe.

Er I egentlig en “ICT third-party provider”?

DORA bruger begrebet “ICT third-party provider” om leverandører, finansvirksomheder er afhængige af for deres it og data. Mange undervurderer, hvor hurtigt de falder ind i den kategori.

Typiske cases:

SaaS-leverandører til finans

Hvis I leverer software som service, der håndterer kundedata, transaktioner, risikoberegninger, rådgivning eller bare medarbejdernes daglige værktøjer, er svaret næsten altid ja: I bliver behandlet som ICT third-party. Også selv om jeres løsning “bare” er et workflowværktøj eller et nichemodul.

Jeg har set mindre fintechs blive overraskede over, at et tilsyn kunne stille indirekte krav til deres it-setup, selv om de formelt kun havde kontrakt med en enkelt bankkunde. Banken trak DORA ned i kontrakten, og pludselig var alt fra releaseprocesser til logning til diskussion.

Drift, hosting og managed services

Hvis I driver kundens løsninger, hoster dem, leverer overvågning eller står for sikkerhedsoperationer, er I nærmest prototypen på en ICT third-party. Her vil finans-kunderne typisk gå tungt ind i jeres beredskabsplaner, kapacitetsstyring og hændelseshåndtering. DORA er tæt beslægtet med det, mange allerede kender fra mere klassisk arbejde med cyber og informationssikkerhed, men nu strammes kravene og bliver mere ens på tværs af EU.

Cloud og infrastruktur

Hvis I er ren infrastrukturleverandør eller bygger oven på hyperscalere, kommer DORA-kravene ofte i flere led. Banken spørger jer om jeres brug af fx AWS eller Azure, og I skal både kunne forklare jeres egne kontroller og dokumentere, hvordan I styrer risikoen hos cloud-leverandøren.

Konsulenter og udviklingspartnere

Her bliver det hurtigt gråt. Hvis I “bare” leverer timer, men ikke driver noget selvstændigt, kan kravene være mildere. Men så snart I har ansvar for miljøer, kodebaser, pipelinen eller væsentlige processer, vil mange finans-kunder behandle jer som en del af deres kritiske drift.

Min erfaring er, at det sjældent kan betale sig at diskutere, om man lige akkurat falder ind eller ud af definitionen. Det, der betaler sig, er at have et fornuftigt grundniveau af kontroller og dokumentation, så I kan møde kundernes forventninger uden kamp.

Hvad vil finans-kunderne typisk kræve i jeres kontrakter?

Hvis du allerede har set de første DORA-inspirerede kontrakttillæg, har du sikkert bemærket mønstret: flere rettigheder til kunden, flere pligter for jer, og en højere grad af gennemsigtighed.

Typisk ser man krav på mindst disse områder:

Audit-rettigheder og adgang til information

Kunden vil have mulighed for at føre tilsyn med jeres kontroller, selv eller via tredjepart. Det kan være alt fra ret til at modtage revisionsrapporter, til at stille op til interviews, til on-site audits. De færreste finans-kunder har tid til at stå fysisk hos jer hvert år, men de vil have rettigheden på plads.

Incident reporting og klassifikation

DORA skærper kravene til, at finansvirksomheder opdager og rapporterer væsentlige it-hændelser hurtigt. Det betyder, at de vil kræve, at I:

• opdager hændelser i rimelig tid (overvågning og alarmer)
• klassificerer dem efter kritikalitet
• giver dem besked inden for bestemte frister
• deler relevante logs og root cause-analyser.

Her er det vigtigt, at I er ærlige om, hvad I faktisk kan. At love 24/7/365 detektion og 1-times reaktionstid uden at have bemanding og processer til det, er en sikker vej til konflikt senere.

Resiliens- og beredskabstest

Mange finans-kunder vil have dokumentation for, at I tester jeres backup, failover, gendannelse og beredskab. Ikke nødvendigvis med store tværgående øvelser, men mindst årlige test af gendannelse fra backup og scenarier som tab af primært datacenter eller større leverandørnedbrud.

Ændringshåndtering og release management

Hvis I deployer kode til produktion, vil kunderne ofte se en beskrevet proces for:

• godkendelse af ændringer
• test og kvalitetssikring
• rollback-muligheder
• kommunikation ved større releases.

Her kan selv en forholdsvis “lean” DevOps-proces oversættes til noget, der ligner kontrol, hvis man gider få det skrevet ned på menneskesprog.

Adgangsstyring, logging og segregation of duties

Banker og forsikringsselskaber er vant til at tænke i roller og rettigheder. De vil gerne se, at:

• ikke alle har adgang til alt
• produktion og udvikling ikke flyder fuldstændig sammen
• adgange revurderes jævnligt
• der logges tilstrækkeligt til, at man kan undersøge en hændelse.

Det er her, mange mindre leverandører opdager, at deres “vi stoler på folk”-kultur ikke lige oversættes til revisionssprog. Man behøver ikke lave militærstat, men man skal kunne vise, at der er en eller anden form for styring.

Fra krav til kontroller: hvad skal I faktisk have på plads?

DORA lægger sig tæt op ad god praksis for it- og informationssikkerhed. Hvis I allerede arbejder struktureret med ISO 27001, SOC 2 eller lignende, har I et forspring. Hvis ikke, kan I starte med nogle få, tydelige kontrolområder.

Incident management

Lav en enkel proces for, hvordan I opdager, håndterer, dokumenterer og følger op på it-hændelser. Det kan være et flow på én side, understøttet af et simpelt skema eller ticket-skabelon. Det vigtige er, at I:

• har defineret roller (hvem gør hvad)
• har en simpel klassifikation af hændelser
• kan forklare, hvornår I informerer kunderne, og hvordan.

Change management og release

Beskriv den proces, I allerede bruger: kode-review, automatiske tests, staging-miljøer, approvals i jeres pipeline. I behøver ikke opfinde et tungt change board, hvis jeres udviklingsmodel bygger på hyppige, kontrollerede releases. Men I skal kunne forklare styringen.

Backup, gendannelse og tilgængelighed

Dokumenter kort, hvad I laver i dag:

• backup-frekvens og retention
• hvor data ligger (regioner, cloud provider)
• hvor ofte I har testet gendannelse de sidste 12 måneder
• jeres mål for RPO (datatab) og RTO (nedetid) for kritiske systemer.

Det er langt bedre at sige “vi har realistisk RTO på 8 timer” og kunne dokumentere det, end at skrive 1 time med krydsede fingre.

Access management

Få besluttet et par simple principper:

• alle medarbejdere har personlige brugere
• administratoradgange tildeles efter “need to know”
• brugere deaktiveres hurtigt, når folk stopper
• der er mindst årlig gennemgang af kritiske adgange.

Skriv det samlet i en kort adgangspolitik. Det er sådan noget, vendor assessments elsker at se.

Logging og overvågning

Lav en oversigt over, hvad I logger hvor, og hvor længe I gemmer det. Og hvordan I bruger logs i praksis: til performance, fejlfinding, sikkerhed. Det behøver ikke være raketvidenskab, men det skal hænge sammen.

Dokumentpakken: hvad er “good enough” som leverandør?

Mange går i stå her, fordi de tror, de skal have 40 politikker og 300 sider procesbeskrivelser. Det behøver I ikke, før I er ret langt oppe i størrelse. Men I har brug for en lille, skarp pakke.

Et realistisk DORA readiness kit for en mindre eller mellemstor leverandør kan bestå af:

1. Politikker på 2-4 centrale områder

For eksempel:

• informationssikkerhed (overordnet principper og ansvar)
• adgangsstyring
• change- og release management
• beredskab og hændelseshåndtering.

En god tommelfingerregel er, at hver politik kan ligge på 2-5 sider, hvis den er præcis og koblet til jeres praksis.

2. 3-6 procesbeskrivelser og skabeloner

Her vil en finans-kunde ofte gerne se:

• incident management-flow og skabelon til hændelsesrapport
• beskrivelse af jeres releaseproces
• kort beskrivelse af backup og restore-test
• skabelon til kundekommunikation ved større hændelser.

Det lyder tørt, men det kan være lige så kortfattet som den slags “implementerings tjekliste”, vi arbejder med i andre sammenhænge: hvad gør vi før, under og efter.

3. Beviser: hvad har I faktisk gjort?

Her er det fristende at skrive lange intentioner. Dine finans-kunder er mere interesserede i beviser. Eksempler:

• log fra en gennemført backup-restore-test
• ændringslog og testresultater fra en større release
• referat eller notat fra en håndteret it-hændelse
• meet-noter eller Jira-tickets, der viser, at I har gennemført en adgangsgennemgang.

Det er meget lettere at svare på vendor assessments, hvis I kan hæfte et konkret bilag på i stedet for at skrive op ad skærmen hver gang.

Tredjepartsstyring: når jeres egne leverandører også bliver en del af regnestykket

DORA presser finansvirksomhederne til at få styr på hele værdikæden. Det smitter nedad, så I også skal kunne forklare, hvordan I arbejder med jeres underleverandører.

Det gælder særligt:

• cloud providers
• hosting-partnere
• underleverandører, der har adgang til kundedata
• kritiske konsulent- og udviklingspartnere.

I praksis efterspørger finans-kunderne ofte:

• en oversigt over jeres væsentlige underleverandører
• eksempler på kontraktkrav, I stiller til dem
• hvordan I følger op (fx årlig vurdering, SOC-rapporter, sikkerhedsspørgeskemaer).

Hvis I endnu ikke har et systematisk blik på egne leverandører, kan DORA være en kærkommen anledning til at få ryddet lidt op. Det behøver ikke være et kæmpe governance-program, men en enkel registrering af de vigtigste, et par minimumskrav og en fast rytme for genvurdering vil allerede sætte jer foran mange andre. Det spiller direkte ind i den mere overordnede disciplin organisering og governance, bare i it-versionen.

Exit og portability: sådan lover I nok, men ikke for meget

Finans-kunderne er begyndt at stille skarpere krav til, hvad der sker, hvis samarbejdet stopper, eller hvis I får alvorlige problemer. Det hænger tæt sammen med DORAs fokus på koncentrationsrisiko og mulighed for at skifte leverandør.

Her er det fristende at skrive “kunden kan til enhver tid eksportere alle data i et standardformat” og krydse fingre. Jeg vil anbefale en lidt mere jordnær tilgang.

Overvej at beskrive:

• hvordan kunden kan få udleveret data (format, tidspunkt, sikker kanal)
• hvor længe I opbevarer data efter ophør
• hvilken support I yder i en overgangsperiode, og hvordan den honoreres
• hvad I realistisk kan hjælpe med i forhold til migrering.

Det er bedre at have en klar, gennemtænkt exit-model, som jeres produkt og arkitektur kan bære, end at love en glidende mirakelovergang, som alle ved ikke findes. Brug gerne en konkret, teknisk kollega til at sanity-tjekke, hvad der faktisk er muligt.

Salg og kundesucces: fra panik-Excel til svarbibliotek

Når DORA for alvor slår igennem hos finans-kunderne, vil salgs- og CS-teams ofte være dem, der mærker det først. Pludselig tikker der tunge spørgeskemaer ind, og hver deal hænger fast, indtil “it-sikkerhed har kigget”.

Det kan I håndtere langt smartere ved at bygge et simpel svarbibliotek, der kan genbruges.

Fang mønstrene i spørgsmålene

Start med at samle 3-5 af de seneste spørgeskemaer fra banker og forsikring. Ja, de er lange, og ja, strukturen er forskellig. Men spørgsmålenes indhold klumper sig typisk om de samme temaer: governance, hændelser, backup, adgang, underleverandører, exit.

Kategorisér spørgsmålene efter tema i stedet for efter kundens rækkefølge. Det behøver ikke være kønt. Et delt dokument eller en simpel database er nok til at starte.

Byg “standardsvar” med plads til nuancer

For hvert tema skriver I et standardsvar på 5-15 linjer, der:

• starter med en klar påstand (“Vi har 24/7 overvågning” eller “Vi har i dag overvågning i tidsrummet…”)
• beskriver kort kontroller og processer
• henviser til 1-2 konkrete dokumenter eller beviser i jeres DORA-pakke.

Når en ny kunde sender et skema, kan salg/CS og sikkerheds- eller it-ansvarlig hurtigt kombinere standardsvarene og tilpasse dem få steder i stedet for at skrive fra scratch hver gang.

Aftal grænserne for, hvad I lover

En af de farligste ting i den her øvelse er, at salg og CS af ren hjælpsomhed lover mere, end organisationen kan levere. Det løses bedst ved at tage en fælles runde internt:

• hvilke servicemål vil vi forpligte os på skrift?
• hvad er bedst effort, og hvad er garanteret?
• hvordan ser vores standard SLA og sikkerheds-bilag ud?

Her kan det være nyttigt at tage udgangspunkt i eksisterende praksis fra fx NIS2-arbejdet. Vi har tidligere skrevet om at gøre sikkerhedskrav håndterbare i artiklen om NIS2 uden panik, og meget af den tænkning kan genbruges i DORA-konteksten.

En realistisk 6-ugers plan for et DORA readiness kit

Hvis jeg skulle lave et koncentreret DORA readiness forløb med en leverandør, der i dag stort set kun har uformelle processer, ville jeg dele det sådan her. Det er ambitiøst, men ikke urealistisk, hvis man sætter 1-2 nøglepersoner fri et par dage om ugen.

Uge 1-2: Overblik og prioritering

• Kortlæg, hvilke finans-kunder I har, og hvilke krav de allerede stiller.
• Indsaml de seneste spørgeskemaer, kontraktbilag og sikkerhedskrav.
• Identificér jeres mest kritiske systemer og services til finanssektoren.
• Udpeg 3-5 kontrolområder, hvor I tydeligt mangler dokumentation.

Målet efter uge 2 er et enkelt overbliksnotat: hvilke kunder, hvilke krav, hvor er hullerne størst.

Uge 3-4: Kontroller og dokumenter

• Få de vigtigste processer beskrevet: incident, change, backup, adgange.
• Skriv korte politikker på de områder, hvor I reelt har praksis, men ingen tekst.
• Saml eksisterende beviser (rapporter, logs, mødenoter) i en mappe-struktur.
• Planlæg og gennemfør mindst én test af backup-restore og dokumentér den.

Målet efter uge 4 er en første version af jeres interne DORA-pakke: politikker, processer og beviser. Ikke perfekt, men nok til at begynde at sende til kunder under NDA.

Uge 5: Svarbibliotek og salg/CS-setup

• Kategorisér tidligere kundespørgsmål på tværs af kunder.
• Skriv standardsvar per tema med henvisning til konkrete dokumenter.
• Lav en intern guide til, hvem der skal involveres hvornår i nye vendor assessments.
• Aftal klare spilleregler for, hvad der må ændres i standardsvar og SLA uden ekstra godkendelse.

Målet efter uge 5 er, at salg og CS ikke længere skal opfinde hjulet ved hvert nyt DORA-inspireret spørgeskema.

Uge 6: Finpudsning og fremadrettet rytme

• Test jeres readiness kit på en konkret kundeforespørgsel, helst en krævende finans-kunde.
• Få feedback internt og fra 1-2 nøglekunder, hvis muligt.
• Beslut en simpel kadence for opdatering (fx kvartalsvis review af dokumenter og beviser).
• Sæt evt. et par nøgletal op: tid brugt pr. vendor assessment før/efter, antal tilbagevendende spørgsmål I nu kan svare standardiseret på.

Herfra handler det om drift. DORA bliver ikke “færdig”, men I står stærkere, hver gang en ny kunde banker på.

Hvad betyder alt det her for jeres forretning?

Hvis vi trækker os lidt op i helikopteren, er pointen faktisk ret simpel: DORA er endnu et lag regulering, men for jer som leverandør er det også en konkurrenceparameter.

De leverandører, der kan lægge et gennemtænkt, realistisk DORA readiness kit på bordet, vil:

• glide hurtigere gennem procurement hos finans-kunderne
• virke mere modne og troværdige, også over for mindre regulerede kunder
• kunne genbruge svar og dokumentation på tværs i stedet for brandslukning hver gang.

Det kræver noget arbejde at komme dertil, ingen tvivl om det. Men sammenlignet med at køre hvert nyt spørgeskema som et lille kriseprojekt, er gevinsten til at tage og føle på. Og hvis du alligevel arbejder strategisk med digitalisering og teknologi i forretningen, passer DORA egentlig fint ind som endnu et struktureret lag oven på det, I burde gøre fornuftigt alligevel.

Mit råd som data-nørd med lidt for stor kærlighed til regneark: tag kontrol over DORA-kravene, før de tager kontrol over jer. Lav jeres eget setup, jeres egne tal og jeres egen dokumentpakke. Så bliver DORA mest af alt en anledning til at stramme op, ikke et evigt påskud for forsinkede deals og stressede aftener.