En exit-plan kan ikke vurdere en afhængighed, som ingen har skrevet ned. Trinnet hviler på en opgørelse af tre ting pr. system: hvad det gør, hvilke data det rummer, og hvem der leverer og driver det.
Listen er råmaterialet for de næste ni trin. Den bliver aldrig færdig, men den skal være god nok til, at nogen uden for IT-afdelingen kan læse den og forstå, hvad organisationen står på.
Bindingerne ligger sjældent dér, hvor man kigger først
De fleste kan nævne kontorpakken, mailen og økonomisystemet. Færre kan sige, hvilke systemer der logger ind gennem samme identitetstjeneste, eller hvilke integrationer der flytter data mellem dem. Det er de skjulte koblinger, der gør et skifte dyrt.
Aarhus Kommune er et dokumenteret eksempel. Budgetforliget for 2026 afsatte ifølge kommunens egen side om digital handlefrihed 3 mio. kr. årligt i 2026 til 2029. Inden 2030 skal mindst en fjerdedel af kommunens licenser til kontorpakken være baseret på open source.
Kommunen er ifølge SKI gået i gang med hele it-stakken frem for kontorpakken alene. Kortlægningen omfatter infrastruktur, hosting, integrationer, licenser og de tekniske koblinger mellem systemerne. Formålet er at forstå, hvor kommunen er bundet, før nye løsninger vælges. Forløbet gennemgås i → Aarhus Kommune.
Hvad listen skal indeholde
Listen er en fortegnelse med én række pr. system og faste kolonner. Et regneark er nok til at begynde med.
- System og formål · navnet internt og den opgave, systemet løser.
- Ejer i organisationen · den person eller afdeling, der kan træffe beslutninger om systemet.
- Data · hvilke typer data systemet rummer, og om de findes andre steder.
- Leverandør · hvem der sælger, og hvem der driver systemet, hvis det er to forskellige.
- Driftsform · egen server, hostet hos en partner eller en tjeneste i skyen.
- Administratorer · hvem der har fuld adgang, både internt og hos leverandøren.
- Koblinger · hvilke andre systemer der afhænger af det, herunder login.
- Kontrakt · udløbsdato og opsigelsesvarsel.
- Konsekvens ved stop · hvad der sker i organisationen, hvis systemet er utilgængeligt i en dag, en uge og en måned.
Den sidste kolonne udfyldes af systemejeren i forretningen. Den bliver grundlaget for prioriteringen i → Trin 6, og den er svær at rekonstruere bagefter.
Kolonnerne om juridisk enhed og moderselskab tilføjes i → Trin 2. Her handler det om at få alle systemer med.
Fremgangsmåden
- Start med regnskabet · Gennemgå betalinger til IT-leverandører for de seneste tolv måneder. Hvert abonnement er en kandidat til listen.
- Spørg afdelingerne · Bed hver afdeling nævne de systemer, de ikke kan arbejde uden. Svarene afslører fagsystemer og tjenester købt uden om IT.
- Læs identitetstjenesten · Listen over applikationer med enkeltlogin viser, hvilke systemer der hænger på samme login.
- Følg data · Notér for hvert system, hvor data kommer fra, og hvor de sendes hen.
- Notér administratorerne · Skriv ned, hvem der kan oprette brugere, nulstille adgang og ændre opsætningen.
- Find kontrakterne · Knyt hver række til en kontrakt eller et sæt standardvilkår med dato.
- Lad ejerne godkende · Send hver systemejer sin række til kontrol, og dater godkendelsen.
Hvor oplysningerne findes
Økonomisystemet viser leverandørerne og beløbene. Kontraktarkivet viser vilkår og udløb. Identitetstjenestens oversigt over tilknyttede applikationer viser, hvad der logger ind hvordan.
Administratorkonsollerne i de store platforme viser, hvem der har administratorroller. Netværksdokumentation og firewallregler viser, hvilke eksterne tjenester der kommunikeres med. Leverandørernes egne vilkår viser, hvad der sker med data, når aftalen ophører.
Abonnementer betalt med firmakort og gratis tjenester, som medarbejdere selv har oprettet, dukker sjældent op i kontraktarkivet. De findes oftere i udgiftsbilag, i firewallens logs over eksterne tjenester eller ved at spørge brugerne direkte. De hører også med, når de rummer organisationens data.
Vilkårene om ophør varierer fra udbyder til udbyder og bør stå på listen. Microsoft oplyser i sin dokumentation om sletning i Microsoft 365, at data bevares i en konto med begrænset funktion i 90 dage efter, at et betalt abonnement ophører. Senest 180 dage efter ophøret slettes alle kundedata.
Google oplyser i sin vejledning til eksport af en organisations data, at en fuld eksport fra Google Workspace typisk tager 72 timer og kan tage op til 14 dage. Med Googles standardlager slettes eksporten 60 dage efter, at den er startet.
Kopier, der ligger lokalt, og kopier, der ikke gør
Listen bør vise, om der findes en kopi af data uden for leverandørens platform. Mange tror, at mailen ligger på den enkelte computer, men standardindstillingen siger noget andet.
Microsoft skriver i sin vejledning om Cached Exchange Mode, at klassisk Outlook som standard holder 12 måneders mail tilgængelig offline. Samme side oplyser, at tilstanden ikke findes i den nye Outlook til Windows. Ældre mail ligger dermed kun hos udbyderen, medmindre indstillingen er ændret eller der tages backup andre steder.
Microsofts serviceaftale, der gælder fra 30. september 2026, anbefaler brugerne at tage backup af deres indhold regelmæssigt. Hvorfor en kopi hos samme udbyder giver ringe beskyttelse, forklares i → Backup hos samme udbyder.
Administratoradgangen hører med
En exit kræver, at nogen kan logge ind, eksportere og lukke ned. Står samme navn som eneste administrator på mail, økonomi og firewall, er planen afhængig af én person.
Notér derfor mindst to navngivne administratorer pr. kritisk system, og notér, om en ekstern partner har administratorrettigheder. Notér også, om leverandøren selv har adgang til opsætningen. Den oplysning bruges igen, når det vurderes, hvem der kan lukke, se eller ændre, i → Trin 4.
Krav, der allerede peger på en liste
For en række udbydere af digitale tjenester er en sådan fortegnelse et lovkrav. EU-Kommissionens gennemførelsesforordning 2024/2690 gælder blandt andre cloududbydere, datacentre og administrerede tjenesteudbydere under NIS2.
Forordningens bilag kræver i punkt 12.4 en fuldstændig, nøjagtig og opdateret fortegnelse over aktiver, herunder de net- og informationssystemer, der understøtter tjenesterne. Punkt 5.2 kræver et register over direkte leverandører og tjenesteudbydere med kontaktpunkter og de IKT-produkter og -tjenester, de leverer.
Andre organisationer er ikke omfattet af forordningen, men strukturen kan bruges som skabelon. Sammenhængen med leverandørstyringen beskrives i → NIS2 og jurisdiktion i leverandørstyringen.
Typiske fejl
- Kun de store systemer kommer med · fagsystemer, tilføjelsesprogrammer og tjenester købt på kreditkort mangler, og det er ofte dem, der binder data.
- Login glemmes · en identitetstjeneste står som ét system, selv om tyve andre afhænger af den.
- Formaterne noteres ikke · data, der kun kan læses af ét program, er bundet, selv om de kan eksporteres. Se → Dokumentformater som binding.
- Listen ejes af IT alene · uden systemejere i forretningen bliver prioriteringen senere gætværk.
- Listen dateres ikke · en udateret liste kan ikke vise, hvad der har ændret sig.
Hvad trinnet kan og ikke kan vise
Trinnet viser, hvilke systemer organisationen står på, hvem der leverer dem, og hvor data og administratoradgang ligger. Det giver et fælles billede, som ledelse, IT og indkøb kan tale ud fra.
Trinnet viser ikke, hvilke love der kan ramme den enkelte leverandør, og heller ikke, hvad en exit koster. Det siger intet om, hvor sandsynligt det er, at en adgang lukkes. De vurderinger kommer i de følgende trin, og de bliver kun så gode som listen her. Forskellen på hvor data ligger, og hvem der har magten over dem, forklares i → De tre lag i digital suverænitet.
Tjekliste
- ☐ Alle betalinger til IT-leverandører i de seneste tolv måneder er gennemgået.
- ☐ Hver afdeling har nævnt de systemer, den ikke kan arbejde uden.
- ☐ Hvert system har en navngiven ejer i organisationen.
- ☐ Datatyper og dataflow er noteret pr. system.
- ☐ Systemer, der logger ind gennem samme identitetstjeneste, er markeret.
- ☐ Mindst to administratorer er noteret for hvert kritisk system.
- ☐ Lokale kopier og backup uden for leverandøren er noteret.
- ☐ Kontraktens udløb og opsigelsesvarsel står på hver række.
- ☐ Listen er dateret og godkendt af systemejerne.
Næste trin
Med listen på plads findes den juridiske enhed og moderselskabet bag hver kontrakt i → Trin 2: Find den juridiske enhed og moderselskabet. Senere bruges listen til at opgøre, hvad det koster at komme ud af hvert system, i → Trin 5.
Er systemlandskabet stort, eller ligger der mange koblinger og fagsystemer under overfladen, kan en uvildig kortlægning spare tid. Nielco IT’s jurisdiktions- og afhængighedsvurdering gennemføres på organisationens eget materiale, uden at noget installeres.
Kilder
- Aarhus Kommune: Digital handlefrihed, Fælles om Aarhus (opdateret 14. september 2026). https://faellesomaarhus.aarhus.dk/digitalisering-og-ai/handlefrihed
- SKI, Staten og Kommunernes Indkøbsservice: Aarhus Kommune: Her starter arbejdet med digital handlefrihed ikke med skift af leverandør (set 30. oktober 2026). https://www.ski.dk/nyheder/aarhus-kommune-her-starter-arbejdet-med-digital-handlefrihed-ikke-med-skift-af-leverandor/
- Microsoft Learn: Data retention, deletion, and destruction in Microsoft 365 (opdateret 28. maj 2026). https://learn.microsoft.com/en-us/compliance/assurance/assurance-data-retention-deletion-and-destruction-overview
- Google Workspace: Export all your organization’s data (set 30. oktober 2026). https://knowledge.workspace.google.com/admin/migrate/export-all-your-organizations-data?hl=en
- Microsoft Support: Turn on Cached Exchange Mode (set 30. oktober 2026). https://support.microsoft.com/outlook/turn-on-cached-exchange-mode
- Microsoft: Microsoft Services Agreement, gældende fra 30. september 2026. https://www.microsoft.com/en-us/servicesagreement
- Europa-Kommissionen: Gennemførelsesforordning (EU) 2024/2690 af 17. oktober 2024 om tekniske og metodologiske krav til cybersikkerhedsforanstaltninger under direktiv (EU) 2022/2555, bilag punkt 5.2 og 12.4. http://data.europa.eu/eli/reg_impl/2024/2690/oj
