Sammanfattning: De flesta organisationer lägger stor energi på att välja och införa en kritisk IT- eller SaaS-leverantör – men få har en plan för att lämna den. En uppsägningsklausul är inte en exitplan. En praktisk exitstrategi täcker tjänsten, data, integrationer, identitet, alternativ, övergång, leverantörens stöd och avslut – och den behöver testas innan den behövs. För finansiella aktörer gör DORA frågan till ett uttryckligt krav.

När en ny leverantör ska in läggs mycket energi på onboarding:

due diligence
säkerhetsgranskning
avtalsförhandling
personuppgiftsbiträdesavtal
integrationer
utbildning och införande

Men frågan som sällan ställs är den viktigaste för motståndskraften: Hur tar vi oss härifrån om vi måste?

Leverantören kan gå i konkurs, bli uppköpt, drabbas av en allvarlig incident, ändra villkoren, höja priset kraftigt eller helt enkelt sluta leverera det ni behöver. Om den enda planen då är ”vi säger upp avtalet” har ni inget val – ni har en förhandlingsposition som är noll.

Uppsägning är inte samma sak som exit

Att kunna säga upp ett avtal är juridik. Att kunna lämna en leverantör utan att verksamheten stannar är något helt annat. En verklig exit behöver svara på:

Hur får vi ut vår data – komplett, i ett användbart format och inom rimlig tid?
Vad händer med integrationerna som andra system är beroende av?
Vem tar över tjänsten – internt eller en annan leverantör?
Hur lång tid tar övergången i praktiken?
Hur upprätthåller vi verksamheten under tiden?
Vilka behörigheter, nycklar och identiteter måste flyttas eller återkallas?
Vilket stöd är leverantören skyldig att ge – och vad kostar det?
Hur säkerställer vi att data faktiskt raderas hos leverantören efteråt?

Om svaren saknas har ni en uppsägningsklausul, inte en exitplan.

DORA gör frågan mycket konkret

För finansiella aktörer är exitstrategier inte längre en god vana utan ett krav. DORA ställer krav på dokumenterade exitstrategier för IKT-tjänster som stödjer kritiska eller viktiga funktioner. Strategierna ska vara heltäckande, dokumenterade, tillräckligt testade och regelbundet omprövade, och de ska möjliggöra en exit utan att verksamheten avbryts, utan att efterlevnaden av regelverk brister och utan att tjänsterna mot kunderna påverkas negativt.

DORA kräver också att avtalen innehåller uppsägningsrätter och en övergångsperiod under vilken leverantören fortsätter att leverera för att minska risken för störningar. Med andra ord: exit ska vara planerad, avtalad och testad – inte improviserad.

Men logiken gäller alla organisationer med kritiska leverantörsberoenden. Cybersäkerhetslagen och ISO 27001 ställer krav på leverantörskontroll och kontinuitet, och en verksamhet som inte kan lämna sin viktigaste leverantör har en svag punkt i sin operativa motståndskraft – oavsett bransch.

Vad bör en praktisk exitplan innehålla?

En exitplan behöver inte vara ett hundrasidigt dokument. Den behöver svara på rätt frågor inom åtta områden.

Tjänsten

Vilka processer i verksamheten är beroende av tjänsten, och hur kritiska är de?
Hur länge kan verksamheten klara sig utan tjänsten?
Vilka funktioner är oersättliga och vilka kan tillfälligt förenklas?

Data

Vilken data finns hos leverantören, inklusive konfiguration, historik, loggar och bilagor?
I vilket format kan den exporteras, och är formatet användbart utan leverantörens verktyg?
Hur lång tid tar en fullständig export, och har ni provat?

Integrationer

Vilka system skickar data till eller hämtar data från tjänsten?
Vilka API:er, filflöden och automatiseringar slutar fungera vid en exit?
Finns integrationerna dokumenterade, eller sitter kunskapen hos enskilda personer?

Identitet och behörigheter

Är tjänsten kopplad till er identitetslösning, eller har den egna konton och lösenord?
Vilka API-nycklar, certifikat och servicekonton behöver återkallas eller flyttas?
Har leverantören behörigheter i er miljö som måste avslutas?

Alternativ

Finns det realistiska alternativa leverantörer, eller en intern lösning?
Hur lång tid tar det att få ett alternativ i drift?
Finns det en tillfällig nödlösning som håller verksamheten igång under övergången?

Övergång

Vem leder övergången, och vilka resurser krävs?
I vilken ordning flyttas data, integrationer och användare?
Hur verifierar ni att allt kommit över korrekt innan det gamla stängs?

Leverantörens stöd

Vad är leverantören avtalsmässigt skyldig att göra vid exit – export, övergångsperiod, migreringsstöd?
Vad kostar stödet, och hur lång är övergångsperioden?
Vad händer om leverantören inte längre finns eller inte samarbetar?

Radering och avslut

Hur och när raderas er data hos leverantören och dess underleverantörer?
Får ni en bekräftelse eller ett raderingsintyg?
Vilka avtal, licenser och behörigheter ska formellt avslutas?

Testa exit innan ni behöver den

En exitplan som aldrig testats är ett antagande. Testet behöver inte innebära att ni faktiskt byter leverantör – men det behöver bevisa att de kritiska stegen fungerar. Frågor att pröva i praktiken:

Kan ni göra en fullständig dataexport i dag, och hur lång tid tar den?
Går exporten att läsa in i ett annat verktyg, eller är den bara läsbar i leverantörens system?
Stämmer antalet poster, bilagor och historik med vad ni förväntar er?
Vet ni exakt vilka integrationer som slutar fungera, och har ni provat att stänga av en?
Kan ni återkalla leverantörens åtkomst till er miljö på en timme?
Har ni gått igenom exitscenariot i en tabletop-övning med verksamhet, IT och juridik?
Håller de tidsuppskattningar ni gjort i planen när ni jämför med testet?

Det räcker ofta att testa utvalda delar – exporten, en integration, åtkomståterkallelsen – för att upptäcka de antaganden som inte håller.

När bör planen omprövas?

En exitplan är färskvara. Den bör ses över minst årligen och dessutom när något av följande inträffar:

leverantören köps upp, byter ägare eller ändrar strategi
leverantören drabbas av en allvarlig incident eller får finansiella problem
tjänsten får en mer kritisk roll i er verksamhet
nya integrationer eller nya dataflöden införs
leverantören byter underleverantör, driftmodell eller region
avtalet förnyas eller villkoren ändras
regulatoriska krav ändras
ett test har visat att planen inte höll

Bäst fungerar det när exitplanen är en del av den löpande tredjepartshanteringen – inte ett separat dokument som någon råkar hitta när krisen redan är här.

Så kan Kristensson i Skåne stödja

Vi hjälper organisationer att gå från uppsägningsklausul till fungerande exitstrategi. Beroende på behov kan vi bidra med:

kritikalitetsbedömning av leverantörer och tjänster
tredjepartsriskanalys
exitstrategi och exitplan för kritiska leverantörer
avtalskrav för exit, övergångsperiod och dataexport
kartläggning av beroenden, integrationer och dataflöden
koppling till kontinuitets- och krishantering
exit-tabletop med verksamhet, IT och juridik
test av utvalda delar av exitplanen
löpande leverantörsgranskning och omprövning

Den bästa tidpunkten att bygga en exitplan är innan ni behöver den. Den näst bästa är nu.

Vet ni hur ni lämnar era kritiska leverantörer? Läs mer om vårt erbjudande inom finansiella regelverk och DORA eller kontakta oss för ett förutsättningslöst samtal.

Källor: Förordning (EU) 2022/2554 (DORA), artikel 28 om allmänna principer för hantering av IKT-tredjepartsrisk, inklusive exitstrategier, och artikel 30 om avtalsvillkor; Cybersäkerhetslag (2025:1506); ISO/IEC 27001:2022, kontroller för leverantörsrelationer och kontinuitet.

Den här texten är allmän information och utgör inte juridisk rådgivning i ett enskilt ärende.