En exit-plan for alle systemer på én gang bliver sjældent til noget. Trinnet hviler på en prioritering, der kombinerer tre ting fra de forrige trin: hvad et stop koster, hvor udsat systemet er, og hvad det koster at komme ud.
Resultatet er en kort liste. For de fleste organisationer vil to eller tre systemer skille sig ud, og det er dem, der får en egentlig exit-plan først. Resten følges og vurderes igen ved næste gennemgang.
Afhængigheden af systemerne er stor og stigende
Styrelsen for Samfundssikkerhed har opgjort, hvor afhængige danske virksomheder er af deres IT. I rapporten Digital sikkerhed i danske SMV’er 2024 angiver 60 procent af virksomhederne med 10 til 249 ansatte, at kerneopgaverne enten står helt stille eller kun i begrænset omfang kan løses, hvis de centrale interne it-systemer er utilgængelige. For virksomheder med mindst 250 ansatte er andelen 62 procent.
Andelen, hvor kerneopgaverne helt ville gå i stå, steg ifølge rapporten fra 25 procent i 2022 til 30 procent i 2023. Rapporten bygger på Danmarks Statistiks obligatoriske undersøgelse af it-anvendelse i virksomheder med svar fra 4.557 virksomheder.
Rapporten nævner ordresystem, lagersystem, økonomisystem, kommunikationsmidler og kundedatabaser som eksempler på de systemer, virksomheder typisk er afhængige af. Det er ofte blandt dem, prioriteringen ender.
Tre mål for hvert system
Konsekvens er det, der sker i organisationen, hvis systemet er utilgængeligt, eller hvis data udleveres til andre. Den vurdering kommer fra systemejeren og står i rækken fra → Trin 1.
Udsathed er vurderingen fra → Trin 4 af, hvem der har magt over systemet, og hvor hurtigt de kan bruge den. Exit-omkostning er overslaget fra → Trin 5 i tid og penge.
Et system med høj konsekvens, høj udsathed og lang exit-tid hører øverst. Et system med lav konsekvens og nem exit kan vente, uanset hvor leverandøren hører hjemme.
Fremgangsmåden
- Saml de tre mål · Sæt konsekvens, udsathed og exit-omkostning ved siden af hinanden for hvert system.
- Giv hvert mål en enkel karakter · Brug lav, middel og høj, og skriv begrundelsen.
- Sorter listen · Systemer med høj karakter i alle tre mål kommer først, derefter dem med høj konsekvens og høj udsathed.
- Vælg to eller tre · Begræns den aktive liste, så der er ressourcer til at gøre arbejdet ordentligt.
- Find vinduet · Notér næste kontraktfornyelse, opsigelsesfrist og planlagte systemskift for de valgte systemer.
- Få ledelsen til at beslutte · Prioriteringen er en ledelsesbeslutning og skal dokumenteres som sådan.
- Sæt en dato for næste gennemgang · Listen ændrer sig, når systemer, leverandører og vilkår gør.
Konsekvensen ved stop skal komme fra forretningen
IT kan vurdere, hvor svært et system er at flytte. Forretningen ved, hvad det koster, når det står stille. Spørg derfor dem, der arbejder i systemet, hvor længe arbejdet kan fortsætte uden det, og hvad der sker efter en dag, en uge og en måned.
Sæt et beløb på konsekvensen, hvor det kan lade sig gøre. Medtag omsætning, der går tabt for altid, medarbejdere, der ikke kan arbejde, manuelle nødløsninger og kontraktlige forpligtelser over for kunder. Et groft tal er bedre end intet, fordi det gør systemerne sammenlignelige.
Konsekvensen ved udlevering er en anden dimension. Et system med forretningshemmeligheder eller følsomme persondata kan have lav driftskritikalitet, men høj konsekvens, hvis data kan kræves udleveret. Rapporten fra Styrelsen for Samfundssikkerhed angiver, at 61 procent af SMV’erne har systemer med forretningskritiske data, og 28 procent har systemer med følsomme persondata.
Kontraktfornyelsen er vinduet
Den billigste tid at ændre en afhængighed på er, når aftalen alligevel skal fornys. Microsoft beskriver i sin vejledning om Enterprise Agreement aftalen som en treårig aftale, der ved udløb kan fornyes for endnu tre år. Andre store udbydere har tilsvarende aftaleperioder, og datoerne står i kontrakterne.
Notér også, om aftalen fornyes automatisk, og hvad der skal til for at stoppe det. En automatisk fornyelse, som ingen har sat i kalenderen, er en af de mest almindelige grunde til, at et vindue går tabt.
Notér for hvert prioriteret system, hvornår næste fornyelse er, og hvornår en beslutning senest skal træffes for at nå den. Opsigelsesfristen og den tid, et alternativ skal vurderes i, skal regnes baglæns fra fornyelsesdatoen.
For cloudtjenester sætter EU’s dataforordning en ramme. Artikel 25 kræver, at kontrakten fastsætter et varsel for at sætte et skifte i gang på højst to måneder, efterfulgt af en overgangsperiode på normalt højst 30 kalenderdage. Reglerne har gældt siden 12. september 2025 og gennemgås i → Data Act.
Er vinduet lige overstået, kan den aktive plan i stedet handle om at forbedre exit-vilkårene, sikre en kopi af data uden for leverandøren og forberede vurderingen af alternativer. Hvordan exit skrives ind i kontrakten, gennemgås i → Trin 8.
En enkel prioriteringstabel
Exit-planen får tre nye felter pr. system.
- Prioritet · 1, 2 eller 3 for de aktive systemer, og “følges” for resten.
- Vindue · næste kontraktfornyelse eller planlagte systemskift med dato.
- Seneste beslutningsdato · datoen, hvor ledelsen skal have besluttet, for at vinduet kan nås.
Tabellen kan stå i samme regneark som resten af planen. Det vigtige er, at prioriteten kan forklares ud fra de tre mål, og at den kan genbruges, når planen skal opdateres i → Trin 10.
Når kritikalitet vejer tungere end prisen
For de fleste systemer er pris og funktion afgørende. For de mest kritiske kan leverandørens jurisdiktion veje tungere. Hvordan et finsk ministerium vejede pris mod kritikalitet for landets valgsystem, gennemgås i → Finland valgte den billigste cloud-løsning fra til valgsystemet.
Prioriteringen afgør, hvor den afvejning skal laves. Den betyder ikke, at de prioriterede systemer skal flyttes. For hvert af dem er der typisk tre mulige udfald.
- Flyt · afhængigheden er for stor, og et alternativ vurderes i Trin 7.
- Forbered · systemet bliver, men exit-vilkår, kopi af data og en reserveløsning etableres.
- Accepter · afhængigheden er kendt og dokumenteret, og ledelsen har besluttet at leve med den.
Alle tre udfald er gyldige, når beslutningen er truffet på et oplyst grundlag og skrevet ned. Koncentrationen af mange systemer hos samme leverandør behandles i → Koncentrationsrisiko.
Typiske fejl
- Alle systemer prioriteres · en liste med tyve aktive punkter bliver ikke gennemført.
- Leverandørens hjemland afgør alt · et system med lav konsekvens kræver sjældent en exit, uanset hvem der leverer det.
- Udlevering glemmes · kun driftsstop vurderes, selv om data kan være det mest følsomme.
- Vinduet opdages for sent · fornyelsen sker automatisk, fordi ingen har regnet baglæns fra datoen.
- Prioriteringen besluttes i IT alene · uden ledelsens beslutning mangler både mandat og ressourcer.
Hvad trinnet kan og ikke kan vise
Trinnet viser, hvilke systemer der bør have en exit-plan først, og hvornår der er en naturlig anledning til at handle. Det giver ledelsen et konkret beslutningsgrundlag frem for en generel bekymring.
Trinnet kan ikke vise, hvad der vil ske med et bestemt system, eller om en leverandør vil ændre adfærd. Karaktererne er skøn, og de er kun så gode som oplysningerne fra de tidligere trin. Prioriteringen skal derfor gennemgås igen, når de ændrer sig, fx ved et opkøb af en leverandør, nye vilkår eller et nyt system, der bliver kritisk.
Tjekliste
- ☐ Konsekvens, udsathed og exit-omkostning er vurderet for hvert system.
- ☐ Konsekvensen ved både stop og udlevering er vurderet af forretningen.
- ☐ Højst tre systemer er på den aktive liste.
- ☐ Næste kontraktfornyelse og opsigelsesfrist er noteret for de prioriterede systemer.
- ☐ Seneste beslutningsdato er regnet baglæns fra fornyelsen.
- ☐ Ledelsen har besluttet prioriteringen, og beslutningen er dokumenteret.
- ☐ Dato for næste gennemgang er sat.
Næste trin
Med de vigtigste systemer udpeget vurderes alternativerne efter ejerskab, hosting, aktualitet og pris i → Trin 7: Vurder alternativerne.
Skal prioriteringen bruges i en bestyrelsesrapport eller i NIS2-leverandørstyringen, kan en uvildig vurdering give et dokumenteret grundlag. Nielco IT laver en exit-plan pr. kritisk system med rækkefølge og tidsplan, som kan sendes videre til ledelse og bestyrelse. Planen er ikke en anbefaling om at forlade bestemte leverandører.
Kilder
- Styrelsen for Samfundssikkerhed: Digital sikkerhed i danske SMV’er 2024, december 2024 (data fra Danmarks Statistiks undersøgelse IT-anvendelse i virksomheder 2023). https://admin.sikkerdigital.dk/Media/638762615322602677/Digital%20sikkerhed%20i%20danske%20SMV’er%202024_Webtilg%C3%A6ngelig.pdf
- Microsoft: Enterprise Agreement, Licensing guidance (set 30. oktober 2026). https://www.microsoft.com/licensing/guidance/Enterprise-Agreement
- Europa-Parlamentet og Rådet: Forordning (EU) 2023/2854 af 13. december 2023 (dataforordningen), artikel 25 og 50. http://data.europa.eu/eli/reg/2023/2854/oj
