Digital suverænitet

Exit‑plan i en lille organisation: de første skridt med få ressourcer

Exit-plan i en lille organisation: de første skridt med få ressourcer

En lille organisation har sjældent en IT-afdeling, der kan sætte et projekt i gang om exit fra leverandører. Første skridt hviler derfor på en skarp afgrænsning, så arbejdet kan klares på få dage og stadig give et brugbart resultat.

Artiklen viser en enkel rækkefølge for en virksomhed eller en mindre kommune. Den peger ind i de ti trin, hvor der er brug for mere, og skelner mellem det, der skal gøres nu, og det, der kan vente.

Mange er ikke kommet i gang

Akademikerbladet kortlagde i august 2025 via aktindsigt kommunernes forberedelse på, at amerikanske cloudtjenester kunne blive ulovlige at bruge. Ifølge Ingeniøren og HK, der begge gengiver kortlægningen, havde 74 af 98 kommuner ingen exitstrategi for det tilfælde. Ifølge Ingeniøren nævnte nogle mindre kommuner manglende ressourcer som begrundelse.

Blandt virksomheder er billedet lignende. I Dansk Erhvervs medlemsundersøgelse fra december 2025 svarede 23 procent, at de ikke ved, hvilken cloudleverandør de bruger. Undersøgelsen bygger på 695 svar og er ifølge Dansk Erhverv repræsentativ for foreningens medlemmer, men ikke nødvendigvis for hele erhvervslivet.

Af de virksomheder, der kender deres leverandør, bruger 88 procent mindst én amerikansk cloudleverandør. Som største barriere for at skifte pegede 23 procent på manglende kendskab til europæiske udbydere, mens 26 procent svarede “ved ikke”. Uden en liste over egne leverandører er det svært at tage stilling til nogen af delene.

Tallene peger på, at mange mangler det første skridt. Det er det skridt, artiklen handler om.

Afgræns til de systemer, der gør mest ondt

En lille organisation kan ikke behandle alle systemer på én gang, og det er heller ikke nødvendigt. Vælg tre til fem systemer, hvor et stop i en uge ville ramme kunder, borgere, løn eller økonomi.

Det kan fx være mail og dokumenter, økonomisystemet, et fagsystem og hjemmesiden med domænet. Afgrænsningen er et valg, ledelsen bør stå bag, fordi den afgør, hvad der ikke bliver set på i første omgang. Forskellen på det overordnede valg og den praktiske plan er forklaret i → exitstrategi, exit-plan og beredskabsplan.

Udpeg én ansvarlig, der har ledelsens mandat til at bede kolleger og leverandører om oplysninger. Det kan være økonomichefen, kontorchefen eller den, der i dag bestiller licenser. Personen behøver ikke være IT-specialist, men skal have tid i kalenderen de tre dage.

Dag 1: én side med systemer og leverandører

Skriv de valgte systemer op i et regneark med én række pr. system. Notér leverandøren, hvem der har administratoradgang, hvilke data systemet rummer, og hvornår aftalen kan opsiges.

Oplysningerne kan findes i fakturaer, ordrebekræftelser, administrationskonsollen og mails fra leverandøren. Mangler et felt, så skriv “ukendt” og gå videre. Den fulde fremgangsmåde står i → trin 1 i exit-planen, men en side med fem rækker er nok til at begynde.

Dag 2: hvem står bag, og hvem kan lukke

Slå den juridiske enhed op for hver leverandør, så I ved, hvem I har aftale med, og hvem der ejer dem. CVR-registret er stedet at starte for danske selskaber, som beskrevet i → trin 2. For udenlandske leverandører står selskabsoplysningerne ofte i aftalen, på udbyderens egen side om juridiske forhold eller i årsrapporten.

Har I en lokal IT-partner, der videresælger tjenesterne, så notér både partneren og den bagvedliggende udbyder. Det er udbyderen, der i sidste ende kan lukke tjenesten.

Stil derefter ét spørgsmål pr. system. Hvem kan lukke adgangen, og med hvilket varsel? Svaret skrives i rækken med en henvisning til det vilkår, det står i. Den udvidede vurdering af at lukke, se og ændre findes i → trin 4.

Dag 3: kan I få data ud

Prøv at eksportere data fra hvert af de valgte systemer. Notér formatet, og om filen kan åbnes i et andet program. En eksport, der er afprøvet, siger mere end en hensigt i en kontrakt.

For cloudtjenester skal udbyderen efter dataforordningens artikel 26 oplyse om metoder og formater til skift og om kendte tekniske begrænsninger. Bed om oplysningerne, hvis de ikke ligger fremme. Et groft skøn over tiden til at komme ud kan skrives i rækken nu, og et egentligt overslag kan vente til → trin 5.

En kort beredskabsplan for de vigtigste systemer

En exit-plan forudsætter tid. Hvis et system forsvinder fra den ene dag til den anden, er det beredskabet, der skal bære. For en lille organisation kan det være en side pr. system.

Digitaliseringsstyrelsens Vejledning i it-beredskab har skabeloner til organisationer med og uden egen it-drift, herunder en miniberedskabsplan i lommeformat. Siden bør som minimum svare på, hvem der beslutter, hvordan opgaven løses uden systemet, og hvor den seneste kopi af data ligger.

For cloududbydere, datacentre og visse andre digitale udbydere stiller gennemførelsesforordning (EU) 2024/2690 krav til en driftskontinuitets- og katastrofeberedskabsplan. Forordningen gælder ikke for de fleste små organisationer. Dens liste kan alligevel bruges som tjekliste, fordi den nævner roller, kontakter, betingelser for at aktivere planen, rækkefølgen for genopretning og de nødvendige ressourcer. Hvorfor kopien bør ligge et andet sted end hos udbyderen, står i → Backup hos samme udbyder.

Exit-vilkår ved næste fornyelse

Små organisationer kan have svært ved at genforhandle en standardaftale midt i perioden. Fornyelsen er derfor det naturlige tidspunkt at stille krav.

Center for Cybersikkerhed og Digitaliseringsstyrelsen anbefaler i Cybersikkerhed i leverandørforhold fra maj 2022 en række ophørsbestemmelser. De omfatter blandt andet leverandørens servicemål i ophørsperioden og en komplet liste over kundens aktiver, inklusive backup. De omfatter også leverandørens pligt til at bidrage til en smidig overgang. Vejledningen er skrevet til myndigheder, men listen kan bruges af alle. Mere om kontraktvilkårene står i → trin 8.

Hvad der kan vente

Gennemgangen af hele leverandørkæden, den systematiske vurdering af alternativer og en afprøvet overgang med parallel drift kan vente, til de første systemer er beskrevet. De kræver mere tid, og de giver mest værdi, når prioriteringen er på plads.

Prioriteringen selv kan gøres enkelt. Sæt de fem rækker i rækkefølge efter konsekvens ved stop og efter, hvornår kontrakten giver et vindue. Fremgangsmåden står i → trin 6. Hvordan graden af binding kan måles mere præcist, er beskrevet i → Vendor lock-in.

Typiske fejl i en lille plan

  • For mange systemer på én gang · arbejdet går i stå, før det første system er beskrevet.
  • Kun licenser på listen · tjenester, der betales via kreditkort eller en anden leverandør, bliver overset.
  • Svar uden kilde · et mundtligt svar fra leverandøren kan ikke efterprøves ved næste gennemgang.
  • Ingen ejer · uden en navngiven ansvarlig bliver planen ikke opdateret.
  • Ingen afprøvet eksport · planen bygger på antagelser om, at data kan komme ud.

Fast tidspunkt for gennemgang

En plan, der laves én gang, mister værdi, når leverandørerne skifter ejer eller vilkår. Sæt et fast tidspunkt i kalenderen, fx en gang om året, og knyt det til budgetlægningen eller den årlige gennemgang af kontrakter.

Ved gennemgangen tilføjes et nyt system eller to, og felterne med “ukendt” udfyldes. Sådan vokser planen trin for trin uden et stort projekt. Hvad der skal udløse en ekstra gennemgang, fx et opkøb af en leverandør, står i → trin 10.

Hvad en lille plan kan og ikke kan

En plan med fem systemer kan vise, hvor organisationen er mest sårbar, og hvem der skal kontaktes, hvis noget går galt. Den kan også gøre næste kontraktfornyelse til en planlagt beslutning.

Planen kan ikke afgøre, om en bestemt tjeneste er lovlig at bruge, eller hvor stor risikoen er for, at en myndighed i et andet land griber ind. Datatilsynets syn på en plan B for cloudtjenester er gennemgået i → Datatilsynet og plan B. Planen dækker heller ikke de systemer, der er valgt fra i første omgang.

Næste skridt

Sæt tre dage af inden for den næste måned, og vælg de systemer, der skal med. Bed ledelsen godkende afgrænsningen, og aftal hvornår planen gennemgås første gang.

Hvis listen viser et forretningskritisk system, hvor ejerskab, jurisdiktion eller vejen ud er uklar, kan en uvildig gennemgang give et sikrere grundlag. Nielco IT laver en exit-plan for de systemer, I ikke kan undvære, på jeres eget materiale.

Kilder

Skrevet af John Nielsen, indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Om John Nielsen · LinkedIn

John Nielsen, Nielco IT

Skal afhængigheden kortlægges?

Skriv kort, hvilke systemer eller leverandører det drejer sig om, og hvad anledningen er. Så vender jeg tilbage. Jeg sælger rådgivning, ikke produkter, og har ingen leverandørpartnerskaber.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.