En exit-plan skal indeholde felter om formål, ansvar, aftale, data, afhængigheder, vej ud, tid og afprøvning for hvert kritisk system. Når alle planer har de samme felter, kan ledelsen sammenligne systemerne, og det, der mangler, bliver synligt som et tomt felt. Listen nedenfor kan bruges som skabelon til en exit-plan, og den fylder sjældent mere end to til fire sider pr. system.
Der findes ingen dansk standard for en privat virksomheds plan. Feltlisten er sitets egen. DORA-reglerne er brugt som model, og de gælder kun finansielle enheder. Her kræver forordning 2024/1773, art. 10, en dokumenteret plan for hver kontraktlig ordning om kritiske tjenester og en gennemførelsesplan, der passer til aftalens vilkår om udtræden og opsigelse. Art. 28, stk. 8, i DORA nævner alternative løsninger og overgangsplaner, og egen drift er udtrykkeligt en mulighed. Det er gode pejlemærker for en, der skal bygge sit eget eksempel.
Stamdata og ansvar
System og funktion. Navnet på systemet og den forretningsfunktion, det bærer. Skriv funktionen på forretningens sprog, fx ordrebehandling eller løn.
Ejer. En navngiven rolle i forretningen, en stedfortræder og den IT-ansvarlige. Fordelingen er beskrevet i hvem ejer exit-planen?.
Tolerance. Hvor længe funktionen kan være væk, og hvor meget data I kan miste.
Status. Dato for seneste gennemgang, hvem der har godkendt planen, og dato for næste.
Aftalen
Parter og dokumenter. Den juridiske enhed, I har aftalen med, partner eller direkte køb, og hvor de gældende vilkår ligger.
Tider. Løbetid, næste fornyelse, opsigelsesvarsel og eventuel binding.
Ophør. Hvad aftalen siger om overgangsperiode, bistand, dataudlevering og sletning. Står der intet, skriver I det. Et tomt punkt i aftalen er en oplysning i planen. Konkrete tvivl om aftalen er et spørgsmål til advokat.
Data og afhængigheder
Data. Hvilke data der ligger i systemet, cirka hvor meget, og i hvilke formater de kan komme ud. Notér metadata, historik og logs særskilt.
Opsætning. Konfiguration, rettigheder, skabeloner og andre digitale aktiver, der ikke følger med en almindelig eksport.
Integrationer. Liste over de systemer, der sender til eller henter fra systemet.
Login og konti. Hvor brugerne logger ind, og hvem der ejer kontoen, domænet og abonnementet.
Underleverandører. De leverandører, der ligger bag, så vidt I kan se dem.
Særlige krav. Persondata, bogføringsmateriale og andet med egne regler om opbevaring. Reglerne om databehandling ved ophør hører til jeres databehandleraftale, så henvis til den.
Vej ud
Situationer. Hvordan planen virker ved svigt, mislykket levering og uventet opsigelse, se de tre situationer.
Alternativer. Et eller to mulige steder at tage hen, herunder egen drift og et andet produkt. Planen noterer dem uden at vælge.
Udløsere. De hændelser, der får nogen til at tage planen frem.
Trin. En kort rækkefølge fra beslutningen til flytningen kan begynde: besked til leverandøren, datahentning, kontrol af data, brugere. Planen slutter her.
Overgang. Hvordan I planlægger parallel drift og vej tilbage, hvis flytningen fejler.
Sletning. Hvem der bekræfter, at data er væk hos leverandøren, når alt er modtaget.
Tid, arbejde og afprøvning
Tid ud. Et interval fra forsigtigt til optimistisk, opdelt på beslutning, data, integrationer og brugere. Læg det ved siden af varslet i aftalen, som beskrevet i beregningen af tiden ud.
Arbejde. Egne folk, ny leverandør og parallel drift i timer og roller, med dato. Beløbene står i jeres eget ark.
Test. Hvad der er prøvet, hvornår, med hvilket resultat, og hvad der blev rettet bagefter. Står feltet tomt, er planen en antagelse.
Åbne punkter. Det, I ikke kender endnu, og hvem der finder ud af det.
Hvor detaljeret skal den være?
Så detaljeret, at en person, der ikke har skrevet planen, kan bruge den. Det er den bedste prøve. Giv den til en kollega, og spørg, hvad vedkommende ville gøre først.
For et mindre kritisk system kan hvert felt være én linje. For det vigtigste system kan feltet om data have sit eget bilag. Art. 4, stk. 2, i DORA kalder det at anvende reglerne i rimeligt forhold til størrelse og risiko. Den tanke er lige så brugbar i en privat virksomhed.
Hvad det kræver, og hvad det koster at lade være
Den første plan tager længst, fordi I også skal finde kontrakter og tale med folk. De næste går hurtigere, når skabelonen findes. Notér pr. system, hvor mange timer I venter, i et interval med dato, og sammenlign bagefter med det faktiske forbrug.
Uden felterne ligger viden i hovederne på få mennesker, og et stop bliver dyrere, fordi nogen først skal finde ud af det hele. Regn tabet med forretningens egne tal pr. dag, og læg de dage til, det tager at genskabe overblikket.
Felterne giver en gevinst, selv om planen aldrig bliver brugt. De samme oplysninger besvarer leverandørskemaer og fornyelser, og de gør et skifte af IT-chef mindre sårbart.
Ønsker I hjælp til at udfylde felterne, er det den opgave, Nielco IT løser under Exit-rådgivning. Hvad der påvirker prisen, og hvordan I får et tilbud, står under pris og tilbud.
Det skal I lade være med
- At skrive en ny skabelon for hvert system · sammenligningen er en stor del af værdien.
- At lade felter stå tomme uden kommentar · skriv “ukendt”, og hvem der finder ud af det.
- At lægge kroner ind i dokumentet · planen deles bredt, og beløbene hører til økonomiarket.
Det skal planen kunne vise
- ☐ Samme felter for alle kritiske systemer.
- ☐ En ejer, en dato og en godkendelse.
- ☐ Tiden ud sammenholdt med aftalens varsel.
- ☐ Testresultat og åbne punkter.
- ☐ At en udenforstående kan læse og bruge den.
Kilder
- Forordning (EU) 2022/2554 (DORA): art. 4, stk. 2, og art. 28, stk. 8.
- Delegeret forordning (EU) 2024/1773: art. 10.
Senest gennemgået: november 2026.
Næste skridt
Kopiér felterne til et dokument, og udfyld dem for ét system. De tomme felter er jeres arbejdsliste.
Læs også: Hvad kræver en exit-plan af jer? · Hvad er en exit-plan?
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
