Det betyder, at jeres system kan stoppe af grunde, jeres leverandør ikke selv styrer, og at flere af jeres systemer kan stoppe samtidig. SaaS er software, I bruger gennem browseren, og mange af leverandørerne lejer deres servere hos en underleverandør. Kæden står sjældent i jeres aftale, og den ændrer scenarierne i exit-planen. Der skal et par ekstra linjer til, og dem kan I skrive uden at flytte noget.
Kæden set fra planen
Kortlægningen af selskaberne bag er beskrevet i det tredje trin på digital-suveraenitet.dk. Her er spørgsmålet, hvad oplysningerne skal bruges til. For hvert kritisk system skal planen kunne svare på to ting: hvad sker der med jer, hvis underleverandøren får et problem, og hvad kan jeres leverandør gøre ved det?
Svaret afhænger af, hvordan leverandøren har bygget sin tjeneste. Nogle kan flytte til et andet område eller en anden udbyder på kort tid. Andre har bygget tjenesten så tæt på underleverandørens værktøjer, at de selv står med en stor exit-opgave. Det er en oplysning, I kun får ved at spørge.
Fire scenarier, der ændrer sig
Tag de tre situationer, planen skal dække, og læg kæden ind.
Nedbrud hos underleverandøren. Jeres leverandør kan ikke gøre andet end at vente, og serviceniveauet i jeres aftale hjælper kun i det omfang, det dækker situationen. Læs, om aftalen undtager hændelser hos tredjeparter. Planen skal bygge på den tid, det faktisk kan tage, se nedbrud i flere dage.
Flere systemer rammes samtidig. Ligger jeres SaaS til økonomi, løn og salg alle hos samme cloududbyder, er de i praksis ét fælles punkt, selv om de har tre leverandører. Omvejene i jeres konsekvensanalyse må ikke regne med et system, der stopper af samme grund.
Leverandøren mister adgangen. Betaler jeres leverandør ikke, får den sin konto lukket, eller opstår der uenighed med underleverandøren, kan jeres data ligge et sted, hvor ingen af jer kommer til dem. Her er en egen kopi den praktiske beskyttelse.
Underleverandøren skiftes. Leverandøren kan flytte til en anden cloud, fx efter et opkøb. Det kan ændre lokation, vilkår og risiko, uden at jeres aftale ser anderledes ud. Noter, hvad I har krav på at få at vide.
Spørgsmål til leverandøren
Spørg roligt og ét sted, gerne på næste statusmøde eller i det faste skema. Svarene hører hjemme i planen med en dato.
- Hvilke underleverandører bærer tjenesten, og i hvilke områder ligger driften?
- Hvad er jeres egen plan, hvis den vigtigste underleverandør falder ud?
- Hvornår har I sidst testet en gendannelse uden for den primære lokation?
- Hvor længe var tjenesten nede ved jeres seneste større hændelse?
- Får vi besked, før I skifter en væsentlig underleverandør?
- Har I backup af vores data et andet sted end hos underleverandøren?
Får I korte svar, er det også en oplysning. Mange leverandører har gode svar på driftsspørgsmål. Spørgsmålet om den vigtigste underleverandør er sværere, så giv dem tid til det.
Det ændrer I i planen
Fire rettelser er som regel nok.
- Marker fælles punkter på systemlisten, så I kan se, hvilke systemer der deler cloud eller underleverandør.
- Læg tiden til rette efter det scenarie, I ikke selv kan påvirke.
- Kontrollér omvejene, så reserven ikke ligger samme sted som det, den skal erstatte.
- Skriv overvågning ind, så en ændring af underleverandør fanges, se det, I skal holde øje med.
Store cloududbydere kan fint være en del af løsningen. Målet er at vide, hvor jeres systemer deler skæbne, og beslutte, om det er acceptabelt.
Det siger reglerne
NIS2-loven taler i § 6, stk. 1, nr. 4, om forsyningskædesikkerhed og enhedens direkte leverandører. Et krav om at kortlægge underleverandører står der ikke. Det er vores vurdering, at et spørgsmål til den direkte leverandør er en naturlig måde at håndtere dem på. For persondata forventer Datatilsynet, at den dataansvarlige kender hele leverandørkæden.
For finansielle virksomheder kræver DORA, at de ved underentreprise afvejer fordele og risici og tager hensyn til blandt andet insolvensret og begrænsninger ved hastende genopretning af data (art. 29, stk. 2). Delegeret forordning 2025/532 giver dem ret til at aftale opsigelse ved visse væsentlige ændringer i underentreprisen (art. 6). Uden for finans gælder bestemmelserne ikke. Her er de en model for de spørgsmål, en privat køber kan stille.
Hvad det kræver, og hvad det koster at lade være
Opgaven består af at læse leverandørens oversigter og få spørgsmålene besvaret. Vurder selv tiden pr. kritisk system, og notér bedste og værste bud med dato.
Springes den over, kan planen ligne en plan, men bygge på omveje, der forsvinder samtidig med det system, de skal erstatte. Et fælles stop rammer alle afdelinger på samme dag, og tabet skal regnes i egne tal for hele kæden.
Sammenhold arbejdet med det tab og med det, I får, selv om intet sker: et bedre grundlag for samtalen med leverandøren, et svar på kunders spørgsmål om leverandørkæden og færre overraskelser ved opkøb og ændringer.
Det skal I lade være med
- At tro, at jeres leverandør styrer det hele · dens aftale med underleverandøren binder den også.
- At regne tre leverandører som tre risici · de kan være samme punkt.
- At gøre svarene til et krav om flytning · oplysningen er det, I skal bruge.
Det skal planen kunne vise
- ☐ Underleverandøren bag hvert kritisk SaaS-system med dato.
- ☐ Fælles punkter markeret på systemlisten.
- ☐ Leverandørens svar om egen plan og seneste test.
- ☐ Omveje, der ikke deler punkt med systemet.
- ☐ Hvem der fanger, at en underleverandør skifter.
Kilder
- Lov nr. 434 af 6. maj 2025 (NIS2-loven): § 6, stk. 1, nr. 4.
- Datatilsynet: Cloud: om overblik over leverandørkæden.
- Forordning (EU) 2022/2554 (DORA): art. 29, stk. 2, gælder finansielle virksomheder.
- Delegeret forordning (EU) 2025/532: art. 6, gælder finansielle virksomheder.
Senest gennemgået: november 2026.
Næste skridt
Vælg de tre vigtigste SaaS-systemer, og send de seks spørgsmål til leverandørerne. Når svarene er kommet, kan ledelsen tage stilling til, om de fælles punkter er acceptable.
Læs også: Spørg leverandøren om exit · Lille leverandør med et kritisk system
→ Kontakt · Tlf. 70 13 63 23 · Exit-plan og exit-rådgivning hos Nielco IT
