...
Spørgsmål om exit-planer
Her står svarene på det, ledelser, compliance-ansvarlige og IT-chefer oftest spørger om, når et kritisk system eller en leverandør kommer på dagsordenen. Hvert svar kan læses alene, og sidste linje peger på den side, som uddyber emnet. Svarene er generel orientering og ingen juridisk rådgivning, og står der, at et spørgsmål er åbent, så har vi ikke fundet en kilde, der afgør det.
Grundbegreber
Hvad er en exit-plan?
En exit-plan er et kort dokument pr. kritisk system, som beskriver vejen væk fra systemet eller leverandøren. Det fortæller, hvilke data der skal med, hvor de kan tage hen, hvor lang tid det vil vare, og hvem der træffer beslutningen. Dokumentet laves i en rolig periode, og I binder jer ikke til at flytte noget. Læs Hvad er en exit-plan?.
Er exitplan og plan B det samme?
Ja, det er samme emne, og stavemåden gør ingen forskel. DI bruger også udtrykket plan B om en exitstrategi. På dette site står ordene for det at kunne forlade et system eller en aftale med en leverandør. Se Plan B uden at flytte noget.
Hvad er forskellen på en exitstrategi og en exit-plan?
Exitstrategien er ledelsens afgørelse af, hvor I vil kunne trække jer ud, og exit-planen er den praktiske vej ud for ét system. Finans Norge skiller også strategi og detaljeret plan i et norsk brancheoplæg fra 2025, og vi låner sondringen, fordi den er nem at arbejde med. Strategien fylder ofte en enkelt side. Se Exitstrategi, exit-plan og beredskabsplan.
Hvad er forskellen på en exit-plan og en beredskabsplan?
Beredskabsplanen holder forretningen kørende, mens et system er nede, og exit-planen tager over, når leverandøren ikke længere er vejen frem. En virksomhed kan derfor klare et kort nedbrud og alligevel mangle svar, hvis tjenesten aldrig vender tilbage. En beredskabsøvelse siger heller intet om, hvorvidt data kan komme ud. Forskellen står i Exitstrategi, exit-plan og beredskabsplan.
Er backup det samme som en exit-plan?
Nej, en backup fører jer tilbage til det system, I har, og en exit-plan fører jer væk fra det. En kopi hos samme leverandør hjælper kun lidt, den dag leverandøren er det, der mangler. Backuppen kan indgå i planen, hvis den kan læses og bruges et andet sted. Læs Backup er ikke en exit-plan.
Handler exit her om salg af virksomheden?
Nej, sitet handler alene om at komme ud af IT-systemer og leverandøraftaler. Ordet dækker også virksomhedssalg og investorers udtræden, og de emner er ikke med her. Se Afgrænsning.
Hvad betyder RTO og RPO?
RTO er målet for, hvor hurtigt systemet skal være oppe igen, og RPO er målet for, hvor stort et datatab I kan tåle. Tages der kopi hver nat, ligger jeres RPO i praksis omkring et døgn. Begge tal er ledelsens beslutning, og både gendannelse og exit kan måles mod dem. Læs Hvor længe kan I undvære systemet?.
Skal vi have en plan?
Er en exit-plan et lovkrav?
Nej, for størstedelen af de private virksomheder er planen frivillig. Undtagelsen er finansielle enheder, hvor DORA art. 28, stk. 8, kræver exitstrategier for de IKT-tjenester, som en kritisk eller vigtig funktion hviler på. NIS2-loven nævner ikke exit. For andre er planen ledelsens egen beslutning, medmindre en kundeaftale eller en sektorregel siger andet. Læs Hvad er en exit-plan?.
Skal alle systemer have en exit-plan?
Nej, kun de systemer, hvor et stop gør ondt, og hvor afløsningen ikke er enkel. Spørg for hvert system, om det kan undværes en uge, om noget tilsvarende kan købes på en uge, om det rummer data, der kun findes dér, om andre systemer afhænger af det, og om nogen stiller krav udefra. Falder det igennem alle fem, er en linje i systemlisten nok. Læs Hvornår er en exit-plan spild af tid?.
Hvilke systemer skal have en plan først?
Først kommer de systemer, hvor et stop inden for kort tid går ud over salg, leverancer eller jeres pligter over for andre. Afdelingerne giver det bedste svar, så stil hver afdeling fem faste spørgsmål, og del resultatet i tre grupper. Et lille system kan ende øverst, hvis fakturaerne til den største kunde afhænger af det. Læs Hvilke systemer kan I ikke undvære?.
Hvor meget leverandørafhængighed må vi have?
Det afgør ledelsen ved at sætte på skrift, hvilke funktioner virksomheden vil kunne drive uden dagens leverandør, og hvor hurtigt. Vi kender ingen almindelig regel, der sætter grænsen for private virksomheder uden for finans. Tre klasser er som regel nok: skal kunne forlades, bør kunne forlades med længere tid, og accepteret afhængighed. Læs Hvor meget afhængighed vil ledelsen acceptere?.
Hvem har ansvaret for exit-planen?
Ledelsen har beslutningen, systemejeren i forretningen har planen for sit system, og IT, indkøb og jura bidrager med hver sin del. Fordelingen er vores forslag, for vi kender ingen almindelig regel, der fastlægger den i en privat virksomhed uden for finans. Planen bør ligge i et fælles system og overleve, at en person stopper. Læs Hvem ejer exit-planen?.
En kunde kræver en exit-plan. Hvad gør vi?
Afklar først, om kunden spørger til sin egen vej ud af samarbejdet med jer, eller til jeres beredskab over for jeres kritiske leverandør. Vis derefter det, I har, og giv en dato for det, der mangler. Et krav i en aftale gælder, selv om jeres eget skøn siger noget andet. Se Kunden kræver en exit-plan.
Bestyrelsen spørger, hvad vi gør, hvis vi mister systemet. Hvad svarer vi?
Svaret kan stå på fem linjer med systemet, tolerancen, den første uge, seneste test og det, der mangler. Har I ikke svaret i dag, så sig det, og kom tilbage med en dato. Se Bestyrelsen spørger.
Må vi vælge ikke at lave en plan?
Ja, for de fleste private virksomheder er det lovligt, når den rette person har truffet valget, og det står på skrift. En risikoaccept nævner systemet, risikoen, begrundelsen, hvem der har truffet valget, og hvornår det tages op igen. Finansielle virksomheder og aftaler med et kundekrav stiller sig anderledes. Læs Vi gør ingenting.
Kan vi lave en plan uden en IT-afdeling?
Ja, og den mindste udgave er én ansvarlig i ledelsen, de vigtigste systemer, en side om hvert og en enkelt prøve på at få data ud. IT-leverandøren kan hjælpe med oplysningerne, mens ejerskabet bliver hos jer. Læs Exit-plan uden en IT-afdeling.
Hvad planen indeholder
Hvad skal en exit-plan indeholde?
Hvert kritisk system skal have felter om formål, ansvar, aftale, data, afhængigheder, vejen ud, tid og test. Når felterne er ens, kan ledelsen sammenligne planerne, og et hul viser sig som et tomt felt. To til fire sider pr. system er sædvanligvis nok, og feltlisten er sitets egen. Læs Hvad skal en exit-plan indeholde?.
Findes der en skabelon til en exit-plan?
Ja, sitet har lister, I kan kopiere ind i et dokument, I selv ejer. Ingen af dem er en officiel form, og private virksomheder har ingen dansk standard at følge. Se Tjeklister og skabeloner.
Hvilke situationer skal planen dække?
Tre situationer bør stå i planen: en vedvarende afbrydelse, en leverance, der ikke lever op til det aftalte, og en uventet opsigelse. Opdelingen kommer fra art. 10 i delegeret forordning (EU) 2024/1773, som kun gælder finansielle virksomheder, og andre kan bruge den som model. Tiden til rådighed er meget forskellig i de tre tilfælde, så én tidsplan dækker dem ikke. Læs De tre situationer, planen skal dække.
Hvor lang tid tager et leverandørskifte?
Det kan ingen sige fra markedet, så I må selv lægge beslutning, data, integrationer og brugere sammen. Sæt resultatet op mod opsigelsesvarslet, for hullet mellem de to tal er det interessante. Tiden skrives som et dateret interval, og den høje vurdering er den, I planlægger efter. Læs Jeres egen tid ud.
Hvornår skal planen aktiveres?
Planen tages i brug, når en hændelse fra jeres liste over udløsere er sket, og den person, I har udpeget, har vurderet sagen. Et godt kriterium er så konkret, at to mennesker når samme resultat. Ejerskifte, varslede vilkår og gentagne brud på serviceniveauet er typiske eksempler. Læs Hvornår aktiveres planen?.
Hvorfor skal integrationer tælles?
Fordi hver kobling skal flyttes, bygges om eller afløses, og tallet ofte ændrer tidsoverslaget mest. Al automatisk trafik mellem to systemer tæller med, også fælles login, filoverførsler om natten og udveksling med banken. Hver kobling får en række med formål, retning og ejer. Læs Integrationer.
Hvem ejer domænet og kontoen?
Ejeren er den, der står registreret hos registratoren og udbyderen, og det kan sagtens være IT-leverandøren. Slå domæner, DNS, tenant, abonnementer, kode og certifikater op, og flyt det hjem, mens samarbejdet går godt. Hvem der ejer en konto ved en konkret tvist, afgør Data Act ikke, så det er et spørgsmål til advokat. Læs Hvem ejer kontoen, domænet og abonnementet?.
Hører login med i en exit-plan?
Ja, for mister I brugerkataloget, står medarbejderne også uden adgang til systemer, der kører fint. Behandl login som et selvstændigt system med en liste over alt, der hænger på det, også servicekonti. En nødkonto uden om det fælles login er den enkleste forbedring, og den skal prøves med faste mellemrum. Læs Login og to-faktor.
Hvad sker der med makroer, flows og rapporter?
De følger sjældent med, fordi de er skrevet til det gamle system. Find dem ved at følge en månedsafslutning fra start til slut, og beskriv resultat og regler med almindelige ord. En prøve er at lave den vigtigste rapport på eksporterede data alene. Læs Det, ingen har på listen.
Vores SaaS kører på en andens cloud. Betyder det noget?
Ja, systemet kan stoppe af grunde, jeres leverandør ikke råder over, og flere systemer kan falde samtidig. Markér derfor fælles punkter på systemlisten, og kontrollér, at reserven ikke står samme sted som det, den skal afløse. Spørg leverandøren, hvad dens egen plan er, hvis den vigtigste underleverandør forsvinder. Læs Jeres SaaS kører på en andens cloud.
Kontrakten
Hvad skal der stå om exit i kontrakten?
Læs syv punkter igennem: data, format, varsel, overgang, bistand, sletning og overdragelse af dokumentation. Vilkårene ligger sjældent i én exit-klausul og er tit spredt mellem hovedaftale, bilag og onlinevilkår. De to første og en del af dokumentationen kan I prøve af nu, og resten vurderes på ordlyden. Syv-punkts-opdelingen er vores forenkling. Læs Exit-vilkår i kontrakten.
Hvad er ophørsbistand?
Ophørsbistand er leverandørens hjælp, når en aftale slutter, så I eller en ny leverandør kan tage over. Aftalen bør sige, hvad hjælpen omfatter, hvem der yder den, og hvordan den afregnes. For cloudtjenester under Data Act skal udbyderen under overgangen yde rimelig bistand, og det gælder også over for tredjeparter, som kunden har godkendt (art. 25, stk. 2, litra a). Læs Ophørsbistand.
Hvor lang skal en overgangsperiode være?
Den bør mindst svare til den tid, I selv skal bruge for at komme ud, regnet fra opsigelsen. DORA kræver en passende periode ved kritiske eller vigtige funktioner uden at sætte en længde (art. 30, stk. 3, litra f). Data Act sætter for cloudtjenester højst 30 kalenderdage, eller højst syv måneder, hvis 30 dage er teknisk umuligt. Læs Overgangsperioden.
Hvornår skal leverandøren slette vores data?
Først efter at I har modtaget data og selv har kontrolleret dem. For cloudtjenester sker den fuldstændige sletning efter udtræksperioden, når skiftet er vellykket (Data Act art. 25, stk. 2, litra h). Bed om en skriftlig bekræftelse, der også omtaler backup. Læs Sletning ved ophør.
Hvad gør vi, når vilkårene ikke kan forhandles?
Så hviler planen på det, I selv råder over, nemlig en egen kopi, en prøvet eksport, en reserveløsning og ledelsens stillingtagen. Det er tilladt at købe standard, og Datatilsynet skriver, at en standardaftale ikke i sig selv diskvalificerer en ydelse. Skifterettighederne efter Data Act skal udbyderen give i aftalen, også når den er en standardaftale. Læs Standardvilkår, I ikke kan forhandle.
Kontrakten siger intet om exit. Hvad nu?
I kan bede om en tillægsaftale, skrive til leverandøren og få svarene skriftligt, eller vente til fornyelsen. Valget afhænger af, hvor kritisk systemet er, og hvor langt der er til næste fornyelse. Tjek også, om tjenesten er en cloudtjeneste under Data Act. Læs Kontrakten siger intet om exit.
Hvad er escrow, og hjælper det ved konkurs?
Escrow er deponering af kildekoden hos en uafhængig tredjepart, som udleverer den ved en aftalt hændelse. Det kan have værdi ved software, der er installeret hos jer eller bygget til jer, når nogen kan tage over, og ved SaaS er det sjældent nok. Hvordan konkursloven rammer en sådan aftale, har vi ikke fundet belæg for, så det spørgsmål står åbent og hører til hos en advokat. Læs Escrow.
Hvordan spørger vi leverandøren uden at true med at gå?
Spørg på et roligt tidspunkt, på skrift og som led i jeres eget overblik over kritiske systemer. Er der ingen flytning på vej, så skriv det. Dele af svaret er en pligt for cloududbydere, som efter Data Act art. 26 skal beskrive fremgangsmåder, formater og kendte begrænsninger. Læs Sådan spørger I leverandøren.
Data og dataudlevering
Hvilke data får vi ud ved ophør?
I kan regne med det, aftalen nævner, og som en prøve har vist er brugbart. Data Act bruger for cloudtjenester to begreber: eksporterbare data, som omfatter input, output og metadata fra jeres brug, og digitale aktiver som fx applikationer (art. 2, nr. 32 og 38). Aftalen skal specificere udtømmende, hvad der kan porteres (art. 25, stk. 2, litra e). Læs Hvilke data får I reelt ud?.
Hvad mangler oftest i en eksport?
Sammenhængen mangler oftest, altså datoer, ændringshistorik, koblinger mellem poster, rettigheder og logfiler. Hold en prøveeksport op mod jeres liste over felter, og skriv en beslutning ud for hvert hul. Det kan være fornuftigt at lade gammel historik blive tilbage, når valget er truffet åbent. Læs Det, der mangler i eksporten.
Hvad skal en egen kopi kunne?
Den skal kunne åbnes og bruges, også når leverandøren er tavs. Kravene gælder sted, konto, format, adgang og test. Fordi I selv råder over den, virker den også i de værste scenarier. Læs Egen kopi uden for leverandøren.
Hvor lang tid tager selve dataoverførslen?
Mål det selv med en prøveflytning af en kendt mængde data, og regn op til det hele. Mængden, leverandørens begrænsninger og de tidsvinduer, I har, afgør tallet, og derfor hjælper tal fra markedet ikke. Cloududbydere skal oplyse om kendte begrænsninger efter Data Act art. 26. Læs Hvor lang tid tager selve overførslen?.
Hvor længe skal gamle data kunne læses efter exit?
Regnskabsmateriale skal efter bogføringslovens § 12, stk. 1, gemmes på betryggende vis i 5 år, og perioden løber fra udgangen af det pågældende regnskabsår. Andre områder kan have egne frister, og dem har vi ikke gennemgået alle, så spørg advokat eller revisor. Persondata trækker den modsatte vej, for de må ikke gemmes længere end nødvendigt. Læs Arkivet efter exit.
Leverandøren vil ikke udlevere vores data. Hvad gør vi?
Gå frem i trin: læs kontrakten, se om Data Act gælder, send en skriftlig og præcis anmodning, og tag en advokat med, når sagen står stille. Hent imens det, I allerede kan få ud. Påberåber leverandøren sig forretningshemmeligheder, skal undtagelsen specificeres udtømmende, og skiftet må ikke blokeres af den (art. 25, stk. 2, litra f). Læs Leverandøren vil ikke udlevere jeres data.
Hvordan ved vi, at alle data er kommet med?
Det ved I, når fire kontroller er gjort: optælling, stikprøver, prøveåbning i et andet system og en godkendelse fra dataejeren. Kriterierne skal stå på skrift, før data kommer, og alt skal være kontrolleret, inden adgangen ophører. For cloudtjenester giver Data Act mindst 30 kalenderdage til dataudtræk efter overgangsperioden. Læs Er det hele kommet med?.
Hvad gælder for persondata under en dataudlevering?
Eksporten samler i én kopi det, der ellers var delt op efter roller, og derfor er data mest udsat på vej ud. Planen skal angive transport, mellemlager, hvem der kan se kopien, og hvornår den slettes igen. Data Act kræver af cloududbydere et højt sikkerhedsniveau, mens skiftet står på og i perioden for dataudtræk (art. 25, stk. 2, litra a). Læs Persondata på vej ud.
Test
Hvordan tester vi en eksport af data?
Vælg ét kritisk system, hent et udsnit af data, og læs det i et andet værktøj. Det kræver en, der kender eksportfunktionen, et par timer og en orienteret systemejer. Skriv tiden, formatet og manglerne ned. Læs Test en eksport nu.
Hvad viser en test af gendannelse et andet sted?
Testen viser, om jeres kopi kan blive til et arbejdende system væk fra det miljø og den leverandør, I bruger i dag. Data, opsætning, nøgler og viden skal altså tilsammen være nok. En almindelig restore-test bringer blot filer tilbage til samme sted. Læs Gendannelse et andet sted.
Kan vi teste uden at forstyrre driften?
Ja, hvis testen er fysisk og logisk adskilt fra driften, så den kører i et separat miljø på kopierede data, med særskilte konti og uden kobling til produktion. Kan det ikke lade sig gøre, kan I spørge leverandøren om et testmiljø, afgrænse testen eller holde en gennemgang ved bordet. Læs Sådan tester I uden at forstyrre driften.
Hvor ofte skal en exit-plan testes?
Ingen regel giver et tal, så I må selv vælge en rytme og begrunde den på skrift. Vores forslag er skrivebordsøvelse og delvis test én gang om året for det mest kritiske, hvert andet år for det kritiske, og en gennemgang ved fornyelse for det, der er let at erstatte. Fuld test vælger ledelsen fra sag til sag. Læs Skrivebord, delvis eller fuld.
Hvad er en bestået test?
En test er bestået, når kriterier fra før testen er opfyldt, og en udenforstående kan kontrollere det i det skrevne. Resultatet kan også være bestået med fund eller ikke bestået, og begge dele er brugbare. Læs Hvad er en bestået test?.
Hvad skal der stå i en testrapport?
Rapporten skal vise, hvad der blev testet, kriterierne, resultatet, afvigelserne og godkendelsen. En side eller to er nok, og afvigelserne er den vigtigste del. Adgangskoder og nøgler hører ikke hjemme her, fordi mange læser rapporten. SAMSIK anbefaler, at resultater af test af backup og gendannelse dokumenteres og godkendes af den relevante ledelse. Læs Testrapporten.
Hvordan tester vi gendannelse i SaaS?
Tre ting kan I selv prøve: eksporten, brugen af data uden for tjenesten og tilbagehentning af enkelte poster. Selve systemet kan I ikke gendanne, så resten må hvile på leverandørens oplysninger. Hold dem adskilt fra det, I selv har set, og gem det skriftlige svar med dato. Læs Test af gendannelse i SaaS.
Økonomi og business case
Hvad koster en exit-plan?
Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud. Laver I planen selv, er prisen først og fremmest jeres egen tid, og den kan I gøre op med arbejdet i en exit-plan.
Hvor meget arbejde kræver en exit-plan?
Antallet af systemer, antallet af integrationer og en eventuel kortlægning afgør det meste. Første plan tager længst, fordi kontrakter skal findes, og folk skal tales med. Derefter er det løbende arbejde lille, når det ligger fast i kalenderen. Læs Hvad kræver en exit-plan af jer?.
Hvordan laver vi en business case for en exit-plan?
Stil på ét ark indsatsen, prisen for et stop og udbyttet i hverdagen op over for hinanden. Ledelsen kan så sige ja, nej eller ja for de vigtigste systemer. Beløbene regner I selv med jeres egne tal. Læs Business case for en exit-plan.
Hvad koster det at mangle en plan?
Omkostningen viser sig, når en beslutning skal træffes under pres, og derfor står den sjældent i et budget. Den består af valg, I ikke kan tage, tabt tid og arbejde, der må gøres to gange. Sandsynligheden er svær at kende, så beskriv posten roligt som en konsekvens. Læs Det koster at mangle en plan.
Hvordan omsætter vi et stop til egne tal?
Vælg én funktion, find dens dagstab i jeres egne tal, og se på, hvordan tabet vokser med varigheden. Tallet bliver til en tolerance, som planen og testen kan måles mod. Sitet giver ingen markedstal, for de hjælper jer ikke. Læs Et stop omsat til jeres egne tal.
Hvad er et exit-overslag?
Exit-overslaget er et felt i planen med tid og arbejde pr. system, skrevet som to daterede bud, et lavt og et højt. Det skal være groft og let at rette, og det justeres efter hver test. Beløbene hører hjemme i jeres eget ark. Læs Exit-overslaget.
Hvad får vi ud af planen, hvis vi aldrig flytter?
I får et overblik over de kritiske systemer, ryddede konti og aftaler, papirer at vise kunder og ledelse og kortere svartid. Gevinsten begynder, så snart planen er skrevet, og bør stå for sig selv i beslutningen. Læs Gevinsterne uden flytning.
Hvordan får vi en beslutning fra ledelsen?
Skriv ét notat på en side med ét spørgsmål: skal disse systemer have en plan og en test? Notatet rummer baggrund, valgmuligheder, indsats, anbefaling og opfølgning. Bestyrelse eller direktion behøver ikke kende systemerne for at beslutte. Læs Beslutningsnotat om exit-planen.
NIS2, DORA, Datatilsynet og Data Act
Kræver NIS2 en exit-plan?
Nej, ordet exit står ikke i loven om NIS2 (nr. 434 af 6. maj 2025). Kravene i § 6, stk. 1, omfatter forsyningskædesikkerhed (nr. 4) og driftskontinuitet (nr. 3), og efter § 7, stk. 1, godkender ledelsesorganet foranstaltningerne. At en exit-plan kan være en måde at arbejde med kravene på, er vores vurdering. Læs Kræver NIS2 en exit-plan?.
Kan vi skifte kritiske leverandører i tide?
Få kan svare ja på stående fod. Et brugbart svar nævner de kritiske leverandører, tiden ud og jeres tiltag for det, tiden ikke rækker til. Spørgsmålet er et eksempelspørgsmål i SAMSIK’s vejledning fra juni 2025 og står ikke i loven. Læs Kan I skifte kritiske leverandører i tide?.
Skal gendannelse testes under NIS2?
Loven nævner backupstyring og reetablering, mens SAMSIK’s vejledning taler om jævnlige test af backup og gendannelse. I bør derfor kunne vise, at I tester, hvad resultatet blev, og at ledelsen har godkendt det. Om kravene er opfyldt, afgør den sektoransvarlige myndighed. Læs Test af gendannelse under NIS2.
Kræver Datatilsynet en exitstrategi?
Nej, tilsynets vejledning om cloud fra marts 2022 og dets side om emnet, læst 6. november 2026, bruger ikke ordene exit, exitstrategi eller plan B. Vejledningen taler om tjenester, I kan blive nødt til at fravælge, og om, at oplysninger skal kunne slettes eller leveres tilbage ved ophør. Siden siger, at vejledningen vil blive opdateret. Læs Datatilsynet og exitstrategien.
Hvad kræver DORA om exit?
Finansielle enheder skal have exitstrategier for IKT-tjenester bag kritiske eller vigtige funktioner (forordning (EU) 2022/2554, art. 28, stk. 8). Forordningen kalder planerne “omfattende, veldokumenterede”, og de skal desuden testes i tilstrækkeligt omfang og gennemgås regelmæssigt. Delegeret forordning 2024/1773, art. 10, kræver en dokumenteret plan for hver kontraktlig ordning. Uden for finans er reglerne kun en model. Læs DORA og exitstrategien.
Hvor ofte skal exitplaner testes efter DORA?
Forordningerne fastlægger hverken hyppighed eller testform for exitplaner, så begrundelsen for omfanget skal stå på skrift. Art. 11, stk. 6, om test mindst hvert år handler om driftsstabilitet samt indsats og genopretning. Finans Norges brancheoplæg regner bord- og skrivebordsøvelser for brugbare, og det er en norsk tolkning. Dansk tilsynspraksis kender vi ikke. Læs Test af exitplaner efter DORA.
Gælder DORA’s exit-krav for små finansielle virksomheder?
Det er et åbent spørgsmål. Art. 28, stk. 2, fritager art. 16-enheder og mikrovirksomheder for strategien om IKT-tredjepartsrisiko, mens ordlyden af stk. 8 om exitstrategier ingen tilsvarende undtagelse rummer. De kilder, vi har læst, afklarer ikke, hvor langt kravet rækker for dem, så spørg Finanstilsynet, hvis det har betydning for jer. Læs Mindre finansiel virksomhed.
Vi leverer til en bank. Rammer DORA os?
Kravet møder jer gennem kontrakten, for pligten til at have en exitplan ligger hos kunden. Forvent ønsker om en overgangsperiode, data tilbage i et lettilgængeligt format, vilkår for opsigelse og medvirken ved test. Lad en advokat se på det, I skal underskrive. Læs Leverandør til en bank.
Hvad giver Data Act os ret til?
Data Act (dataforordningen, forordning (EU) 2023/2854) pålægger cloududbydere at gøre skift muligt gennem en skriftlig aftale, og forordningen gælder fra 12. september 2025. Jeres ret hviler altså på den aftale, udbyderen skal tilbyde. Art. 23 forbyder hindringer for at skifte, og art. 25, stk. 2, litra b, pålægger udbyderen at give relevante oplysninger til kundens exitstrategi. Læs Data Act i planen.
Hvad er fristerne i Data Act?
Fristen for at opsige med henblik på skift må højst være to måneder (litra d i art. 25, stk. 2), og overgangen må højst vare 30 kalenderdage (litra a). Er 30 dage teknisk umuligt, skal udbyderen sige det inden for 14 arbejdsdage og angive en periode på højst syv måneder (stk. 4). Kunden kan forlænge overgangsperioden én gang (stk. 5), og derefter følger dataudtræk i mindst 30 kalenderdage (stk. 2, litra g). Læs Data Act’s frister i jeres plan.
Er vores tjeneste omfattet af Data Act?
Det er den, hvis den er en databehandlingstjeneste efter art. 2, nr. 8, og ordet betyder her en cloudtjeneste og har intet med databehandleraftaler at gøre. De fleste almindelige cloudtjenester hører til, herunder SaaS. Outsourcet drift og branchesystemer afgøres konkret, så del en blandet driftsaftale op, og spørg udbyderen. Læs Hvornår er tjenesten omfattet?.
Hvad falder uden for Data Act?
Ofte gælder det licenser på egne servere, noget af den klassiske drift og systemer, I selv har fået udviklet, og så er det aftalen, der bestemmer. Grænsen er ikke afklaret i praksis, så tag tvivlstilfælde med til en advokat. Læs Kontrakter uden for Data Act.
Forsvinder skiftegebyrerne?
Ja, art. 29, stk. 1, forbyder udbydere at tage skiftegebyrer for skifteprocessen fra 12. januar 2027. Frem til datoen må de alene være nedsatte og højst dække udbyderens direkte omkostninger. Skræddersyede tjenester kan være undtaget efter art. 31. Arbejde hos jer selv, en ny leverandør og parallel drift er efter vores læsning ikke skiftegebyrer, så dem skal I stadig regne med. Om betaling for resten af en bindingsperiode kan kræves, er åbent, fordi art. 2, nr. 36, undtager sanktioner ved førtidig opsigelse, og grænsen er omstridt. Læs Skiftegebyrer fra 12. januar 2027.
Gælder Data Act for kontrakter fra før 12. september 2025?
Ja, sådan læser vi den gældende tekst, for art. 50 har overgangsregler for kapitel IV og ingen for kapitel VI. Kommissionens FAQ tager ikke direkte stilling i de afsnit, vi har læst. Digital Omnibus er et forslag, der kan lempe reglerne for visse ældre aftaler om andet end infrastrukturtjenester, og det er ikke vedtaget. Parlamentet havde ingen stilling 6. november 2026. Læs Kontrakter fra før 12. september 2025.
Er der undtagelser for skræddersyede tjenester?
Ja, art. 31, stk. 1, fritager tjenester, der i hovedsagen er bygget til én kunde og ikke sælges bredt via kataloget, fra dele af kapitel VI, bl.a. art. 29 om skiftegebyrer. Resten af kapitlet gælder stadig, og inden aftalen skal kunden have besked om undtagelsen (stk. 3). Vores kilder afklarer ikke, hvornår en tilpasning koster jer dele af retten. Læs Skræddersyede tjenester og andre undtagelser.
Findes der standardvilkår for cloud fra Kommissionen?
Ja, de frivillige vilkår findes i Henstilling (EU) 2026/2394 af 29. oktober 2026, offentliggjort i EU-Tidende 6. november 2026. Henstillingen binder ingen, så et vilkår gælder kun, hvis det er med i jeres aftale. Delene om skift og exit egner sig som tjekliste mod jeres plan. Læs Kommissionens standardvilkår for cloud.
Hvor klager vi, hvis leverandøren ikke overholder Data Act?
I klager til Digitaliseringsstyrelsen, som er kompetent myndighed efter datadelingslovens § 2 (lov nr. 1618 af 16. december 2025). Klageadgangen følger af Data Act art. 38. Dokumentér først problemet, og giv leverandøren en frist på skrift. En klage hjælper sjældent her og nu, så planen må sige, hvad I gør imens. Læs Leverandøren overholder ikke Data Act.
Platforme
Oplysningerne om de navngivne produkter bygger på leverandørernes dokumentation, læst 6. november 2026. Alle platforme er vurderet efter samme disposition, og intet her er en anbefaling.
Hvad skal en exit-plan for Microsoft 365 rumme?
Planen skal dække mail, filer, samtaler, login og arbejdsgange, og den kræver ingen beslutning om at forlade tjenesten. Planen er en langt mindre opgave end en migrering og kan laves ved siden af driften. Læs Exit-plan for Microsoft 365.
Hvad skal en exit-plan for Google Workspace rumme?
Den skal beskrive eksporten af mail, filer, chat og kalender og behandlingen af Docs-filer, scripts og login. Tidspunktet er afgørende, for kernedata kan kun eksporteres med et aktivt abonnement, altså før opsigelsen. Læs Exit-plan for Google Workspace.
Hvad kan flyttes fra AWS og Azure?
Standardkomponenter som virtuelle maskiner og gængse databaser er lettest at flytte, mens løsninger på udbyderens egne tjenester ofte skal laves om. Planen sorterer miljøet efter den forskel. For Azure hører det med, at identitet og ofte også aftalen er fælles med Microsoft 365. Læs Exit-plan for AWS og Exit-plan for Azure.
Hvad skal en exit-plan for VMware vise?
Den skal samle fornyelse og support på én dato-linje, vise de værktøjer, en flytning hviler på, og dokumentere med en prøve, at en maskine kan startes uden for det nuværende miljø. Resultatet kan sagtens være, at I bliver. Læs Exit-plan for VMware.
Kan vi komme tilbage fra cloud til egen drift?
Det kan I, hvis I har et sted at køre systemet, folk til at drive det og sikkerhed på dagens niveau. DORA art. 28, stk. 8, nævner intern indarbejdelse som en mulighed, og Data Act omfatter skift til lokal IKT-infrastruktur (art. 25, stk. 2, litra a). Mangler én af de tre ting, står muligheden kun på papiret. Læs Tilbage i egen drift.
Hvad kan vi forberede før et ERP-skifte?
I kan forberede en datakopi, en liste over tilpasninger med rettighederne til dem, et overblik over koblinger og adgang til regnskabsmaterialet. Det hele kan ske, uden at noget skifteprojekt er startet. Læs Exit-plan for ERP.
Giver en exit-plan mening for et branchesystem uden alternativ?
Ja, planen går så ud på, at arbejdet kan fortsætte uden systemet. Indholdet er en reserveprocedure, en egen kopi af data, krav stillet i fællesskab i branchen og opmærksomhed på leverandøren. Tjek dog først, om der reelt ingen alternativer findes. Læs Uden alternativ og Exit-plan for et branchesystem.
Hvad gør vi, når driftsleverandøren har det hele?
Afklar, hvad I selv ejer, og få nøglerne til det ind i huset, før nogen siger noget op. Arbejdet kan ske i godt samarbejde, og CFCS og Digitaliseringsstyrelsens vejledning fra maj 2022 kan bruges som model, selv om den er skrevet til myndigheder. Læs Driftsleverandøren har det hele.
Hører AI-tjenester med i exit-planen?
Ja, så snart en arbejdsgang afhænger af dem, fordi leverandøren kan sætte en slutdato for en model. Planen skal vise modellerne, hvor prompter og data ligger, og hvad et skifte til en anden model kræver. Læs AI-tjenester i exit-planen.
Når planen skal bruges
Hvad gør vi i de første 48 timer efter beslutningen?
Sikr jeres egne muligheder, før leverandøren hører om det: bekræft beslutningen, tjek kopien, læs aftalen, og vælg tidspunktet for opsigelsen. Send derefter én samlet besked. Lad en advokat afklare tvivl om opsigelsens følger, inden brevet sendes. Læs Planen skal bruges.
Hvornår bliver et nedbrud en exit-situation?
Det sker, når ventetiden bliver dyrere end handling, og grænsen skal ligge fast, inden nedbruddet kommer. De fleste nedbrud går over af sig selv, så det rigtige er oftest at vente. Planen fastlægger grænsen, og hvem der beslutter. Læs Nedbrud i flere dage.
Hvad sker der med vores data, hvis leverandøren går konkurs?
Det er et åbent spørgsmål, for vi har ikke fundet en dansk afgørelse om kundedata i en cloudtjeneste ved konkurs. Konkurslovens § 82 om det, der tilhører tredjemand, er nærliggende, men rækkevidden er uafklaret, og efter § 61 kan boet afslutte et løbende aftaleforhold med sædvanligt eller rimeligt varsel. Adgangen kan altså stoppe før en afklaring, så kopien skal ligge hos jer i forvejen. Læs Leverandøren går konkurs.
Hvad gør vi, når leverandøren bliver opkøbt?
Brug de første 30 dage på at se, om planen stadig holder, hvad angår ejer, vilkår, support, data og kontakter. Flytning er sjældent svaret, for meget fortsætter ofte uændret i en periode. Det er til gengæld et godt tidspunkt at gentage en test. Læs Leverandøren er blevet opkøbt.
Hvad gør vi, hvis leverandøren opsiger os?
Sæt varslet op mod jeres egen exit-tid den første dag, for nu er det leverandøren, der sætter fristen. Art. 25 i Data Act gælder ikke uden videre, når udbyderen selv siger op, og det er åbent, om en skriftlig anmodning om skifte fra jer udløser pligterne. Lad planen hvile på kontrakten og jeres kopi. Læs Leverandøren opsiger jer.
Hvad gør vi, hvis kontoen bliver lukket uden varsel?
Så råder I alene over det, der i forvejen findes andre steder, og derfor består planen af forberedelser. Det vigtigste er en læsbar kopi af centrale data, kontaktoplysninger og en kanal til at nå hinanden. Hvad Data Act giver ved en spærret konto, siger de læste bestemmelser intet om. Læs Kontoen lukkes uden varsel.
Hvad gør vi, når et produkt udgår?
Find datoen for de sidste sikkerhedsopdateringer, og regn baglæns derfra. Inden den dag skal I enten være væk fra produktet, have begrundet en undtagelse eller have besluttet noget andet. Læs Udfasningsbrevet.
Hvornår er parallel drift nødvendig?
Når en fejl i den nye løsning bliver dyrere end at lade to løsninger køre side om side i en afgrænset periode. For mange systemer er det et valg. Efter Data Act art. 34, stk. 2, må udbyderen tage gebyr for udgående data ved parallel brug, dog højst til dækning af omkostningerne, og grænsen til et egentligt skifte står ikke klart. Læs Parallel drift.
Hvornår må det gamle system lukkes?
Det må det, når lukkekriterier, I har skrevet før flytningen, er opfyldt. Planen skal også nævne, hvad der stadig skal virke, og hvem der har mandat til at vende om. Når leverandøren har slettet data, er vejen tilbage væk. Læs Vejen tilbage.
Hvad er en reserveløsning?
En reserveløsning er det, der ligger parat, så kerneopgaverne kan køre videre, når en tjeneste falder bort. Den kan bestå af en manuel arbejdsgang, en anden kommunikationskanal og en kopi af de kritiske data, der er klar til brug. Det er vores vurdering, at den hører hjemme i planen. Læs Reserveløsning.
Vedligehold
Hvordan holder vi exit-planen opdateret?
Kombinér en fast, selvvalgt dato for gennemgang med en ekstra runde ved bestemte ændringer. Begge dele har samme navngivne ejer, og systemejeren bekræfter, at indholdet stadig holder. Læs Sådan holder I exit-planen opdateret.
Hvad er et årshjul for exit-arbejdet?
Et årshjul fordeler gennemgang, test, kontrakttjek og status på faste måneder ved siden af det, I gør i forvejen. Så kræver det intet særskilt projekt at holde planen i live. Læs Årshjul for exit-arbejdet.
Hvad skal vi holde øje med hos leverandørerne?
Følg vilkår, ejerskab, regnskab, supportdatoer og underleverandører hos dem, der leverer kritiske systemer. Ændringer på de fem punkter viser sig ofte i god tid, så I kan nå at tage planen frem. Læs Hold øje med leverandørerne.
Hvad skal ledelsen se om exit-status?
Ledelsen skal have én side med plan, seneste test og punkter til stillingtagen for hvert kritisk system. Den skal kunne læses på et minut. Læs Exit-status på én side.
Rådgivning
Hvem skal lave exit-planen?
I selv, IT-leverandøren eller en uvildig rådgiver kan lave den, og det ender tit som en blanding, der lader ejerskabet blive hos jer. Valget afhænger af jeres viden og tid, og af hvor tæt leverandøren står på systemet. Læs Selv, IT-leverandøren eller en uvildig.
Må IT-leverandøren skrive planen?
Ja, det er der ingen regler imod, og ingen kender opsætningen bedre. Leverandøren har dog en interessekonflikt, så I skal selv beslutte, eje og kontrollere planen. Læs Må IT-leverandøren skrive planen?.
Hvad kommer først, afhængighedsvurdering eller exit-plan?
Kender I ikke jeres afhængigheder, begynder I med vurderingen, og ved I allerede, hvilke systemer der bekymrer, kan I gå direkte til planen. Vurderingen finder problemet, og planen beskriver vejen ud. Læs Afhængighedsvurdering eller exit-plan.
Hvad er forskellen på en exit-rådgiver og en migrationsleverandør?
Migrationsleverandøren udfører flytningen, når den er besluttet, og exit-rådgiveren hjælper med at afgøre, om I kan komme ud, og om noget skal flytte. De står forskellige steder i forløbet og får forskelligt ud af, at noget flytter sig. Læs Exit-rådgiver eller migrationsleverandør.
Hvad får vi ud af Exit-rådgivning?
Resultatet er en skriftlig plan pr. kritisk system, som er jeres egen og kan sendes videre til dem, der skal se den. Nielco IT arbejder ud fra jeres kontrakter, systemoversigt og leverandørliste og samtaler med dem, der har ansvaret, uden installationer og uden adgang til produktion. Rådgivningen er uvildig, der er ingen forhandleraftaler, og resultatet kan være, at et system bliver, hvor det er. Den er ingen juridisk vurdering af kontrakten. Læs Exit-rådgivning.
Hvad skal vi forberede til en exit-gennemgang?
Saml kontrakter, systemoversigt og leverandørliste, og skriv ned, hvem der kan svare på spørgsmål om systemer, drift og aftaler. Materialet må gerne have huller, når I ved, hvor de er. Læs Sådan forbereder I materialet.
Senest gennemgået: november 2026.
Næste skridt
Skriv de tre systemer ned, som forretningen har sværest ved at undvære, og vælg det spørgsmål ovenfor, I ikke kan svare på i dag.
Læs også: Exit-rådgivning · Ordliste
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
Skal I have en plan B?
Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad der sætter arbejdet i gang. Så vender jeg tilbage. Rådgivningen er uvildig og uafhængig, og Nielco IT har ikke indgået forhandleraftaler med leverandører.