När ett försäkringsbolag köper ett nytt IT-system, en molntjänst eller en extern IT-tjänst räcker det inte att bedöma funktionalitet, pris och teknisk arkitektur. Lösningen måste också göra det möjligt för försäkringsbolaget att uppfylla de regulatoriska krav som gäller för verksamheten.

DORA, Solvens II, försäkringsrörelselagen, GDPR, AI-förordningen och Data Act påverkar både hur leverantören ska granskas och vilka krav som behöver ställas i en RFP. Beroende på vad systemet ska användas till kan även regler om försäkringsdistribution, penningtvätt, digital tillgänglighet och produktsäkerhet bli aktuella.

Det innebär att den regulatoriska analysen måste påbörjas innan RFP skickas ut. Om klassificeringen görs först när en leverantör redan har valts finns en betydande risk att försäkringsbolaget får ett system som inte kan uppfylla kraven – eller att leverantörens standardavtal inte ger de rättigheter som bolaget behöver.

Ett IT-inköp är också ett beslut om risk och styrning

Ett nytt försäkringssystem påverkar ofta flera delar av verksamheten samtidigt. Systemet kan exempelvis behandla känsliga personuppgifter, stödja en kritisk verksamhetsprocess, fatta automatiserade beslut, användas i kundrådgivning eller vara beroende av flera underleverantörer och molnplattformar.

Därför behöver inköpsprocessen involvera fler funktioner än inköp och IT. Normalt behöver även verksamheten, informationssäkerhet, juridik, dataskydd, risk, kontinuitet och ibland compliance delta.

RFP behöver översätta dessa funktioners krav till tydliga, mätbara och avtalsbara krav. Det räcker inte att fråga leverantören om den ”följer DORA” eller ”är GDPR-compliant”. Leverantören behöver visa hur tjänsten är uppbyggd, vilka kontroller som finns, vilken dokumentation som kan lämnas och vilka avtalsvillkor leverantören accepterar.

Vilka regelverk påverkar IT-upphandlingen?

DORA – huvudregelverket för externa IKT-tjänster

DORA började tillämpas den 17 januari 2025 och är det centrala regelverket för försäkringsföretagets digitala operativa motståndskraft och hantering av externa IKT-leverantörer.

Regelverket omfattar betydligt fler tjänster än traditionell outsourcing. SaaS-system, molntjänster, hosting, IT-support, systemförvaltning, integrationsplattformar, säkerhetstjänster och olika data- och analystjänster kan omfattas.

Försäkringsföretaget behöver bland annat:

  • identifiera och klassificera IKT-tjänsten,
  • bedöma om tjänsten stödjer en kritisk eller viktig funktion,
  • genomföra en dokumenterad risk- och leverantörsbedömning,
  • bedöma koncentrationsrisker och underleverantörsberoenden,
  • säkerställa att avtalet innehåller obligatoriska bestämmelser,
  • registrera avtalet i företagets informationsregister,
  • följa upp leverantören och tjänsten under hela avtalsperioden,
  • planera för avveckling, övergång och byte av leverantör.

Finansinspektionen utövar tillsyn över hur svenska finansiella företag hanterar sina IKT-risker och tar bland annat emot rapportering om allvarliga IKT-incidenter och företagens informationsregister.

DORA innebär inte att leverantören tar över försäkringsföretagets ansvar. Det är fortfarande försäkringsföretaget som ansvarar för att verksamheten uppfyller regelverket. RFP måste därför säkerställa att leverantören ger företaget de rättigheter, den information och det stöd som krävs för att bolaget ska kunna fullgöra sitt ansvar.

Solvens II och försäkringsrörelselagen – när verksamhet läggs ut

En separat bedömning behöver göras enligt Solvens II och försäkringsrörelselagen när en extern leverantör ska utföra en funktion eller arbetsuppgift som annars skulle ha utförts av försäkringsföretaget.

Det kan exempelvis handla om:

  • skadereglering,
  • försäkringsadministration,
  • premiehantering,
  • kundservice,
  • aktuarieberäkningar,
  • kapitalförvaltning,
  • ekonomiadministration,
  • drift av system som är avgörande för centrala verksamhetsprocesser.

Försäkringsföretaget får lägga ut verksamhet men behåller hela ansvaret. En operativ verksamhet eller funktion av väsentlig betydelse får inte läggas ut om det exempelvis medför att företagsstyrningen försämras väsentligt, den operativa risken ökar väsentligt, Finansinspektionens tillsyn försvåras eller servicen till försäkringstagarna inte kan upprätthållas.

Leverantören behöver också acceptera att samarbeta med Finansinspektionen och ge försäkringsföretaget, dess revisorer och tillsynsmyndigheten tillgång till relevant information. Väsentliga uppdragsavtal ska anmälas till Finansinspektionen innan avtalet börjar gälla.

DORA-bedömningen och bedömningen av utlagd verksamhet är två olika bedömningar. Ett SaaS-system kan omfattas av DORA utan att utgöra utlagd verksamhet. En tjänst kan samtidigt omfattas av både DORA och reglerna om uppdragsavtal.

GDPR – när personuppgifter behandlas

Nästan alla försäkringssystem behandlar personuppgifter. Det kan röra sig om kontaktuppgifter, betalningsinformation, försäkringsuppgifter, skadehistorik och i många fall känsliga personuppgifter om hälsa.

När leverantören behandlar personuppgifter för försäkringsföretagets räkning behöver ett personuppgiftsbiträdesavtal ingås. Avtalet ska bland annat reglera instruktioner, sekretess, säkerhetsåtgärder, underbiträden, stöd vid registrerades rättigheter, incidenthantering, återlämning eller radering av uppgifter samt rätt till revision och inspektion.

Underbiträden får inte anlitas utan den personuppgiftsansvariges skriftliga godkännande enligt de former som anges i avtalet. Motsvarande dataskyddskrav behöver föras vidare till underbiträdet.

RFP behöver därför kartlägga hela behandlingskedjan. Det räcker inte att veta var den primära databasen finns. Försäkringsföretaget behöver även känna till var säkerhetskopior lagras, från vilka länder support kan utföras och vilka underleverantörer som kan få åtkomst till uppgifterna.

AI-förordningen – när systemet innehåller AI

AI-förordningen behöver bedömas när systemet innehåller AI-funktioner för exempelvis riskbedömning, premiesättning, skadehantering, bedrägeridetektion, kundrådgivning, dokumentanalys eller kundservice.

AI-förordningen bygger på en riskbaserad modell. Kraven varierar beroende på hur AI-systemet används och vilken riskklassificering det får. AI-system som används för riskbedömning och premiesättning av fysiska personer inom liv- och sjukförsäkring är uttryckligen klassificerade som högrisk-AI.

För högrisksystem finns bland annat krav på riskhantering, dokumentation, loggning, datakvalitet, mänsklig kontroll, noggrannhet, robusthet och cybersäkerhet. Enligt de nuvarande övergångsreglerna gäller AI-förordningen generellt sedan den 2 augusti 2026, medan de särskilda kraven för högrisksystem i bilaga III börjar tillämpas den 2 december 2027.

Alla AI-funktioner i ett försäkringssystem är inte automatiskt högrisk. Användningsområdet behöver bedömas separat. RFP bör därför kräva att leverantören redovisar samtliga AI-komponenter, modeller, användningsområden och beroenden – även när AI-funktionen ingår i en större standardplattform.

Data Act – möjlighet att byta leverantör

Data Act började tillämpas den 12 september 2025 och innehåller bland annat regler som ska underlätta byte mellan leverantörer av databehandlingstjänster, exempelvis moln-, SaaS-, PaaS- och IaaS-tjänster.

Regelverket stärker betydelsen av dataportabilitet, interoperabilitet och praktiskt genomförbara leverantörsbyten.

För ett försäkringsföretag är detta nära kopplat till DORA krav på exitstrategier. RFP bör därför ställa tydliga krav på hur data, metadata, konfigurationer, loggar och dokumentation kan exporteras och överföras till försäkringsföretaget eller en ny leverantör.

Verksamhetsspecifika regelverk

Utöver de generella IT- och säkerhetsregelverken behöver RFP anpassas efter vad systemet ska användas till.

Ett system för digital försäkringsdistribution behöver exempelvis stödja kartläggning av kundens krav och behov, presentation av tydlig produktinformation, dokumentation av rekommendationer samt bevisning om vilken information kunden har fått. Information kan behöva lämnas på papper eller annat varaktigt medium, och distributionen ska dokumenteras på ett sätt som gör det möjligt att följa vad som har hänt.

System som används inom livförsäkringsverksamhet kan också behöva stödja kraven i penningtvättslagstiftningen, exempelvis kundkännedom, identifiering av verklig huvudman, riskklassificering, löpande uppföljning, varningshantering och bevarande av dokumentation.

Webbplatser, appar och digitala kundflöden där en konsument kan ingå ett försäkringsavtal kan omfattas av lagen om vissa produkters och tjänsters tillgänglighet. Lagen gäller sedan den 28 juni 2025 och ställer krav på att berörda tjänster ska vara tillgängliga och att tjänsteleverantören ska kunna dokumentera hur kraven uppfylls.

Cyber Resilience Act kan bli relevant när försäkringsföretaget köper programvara eller hårdvara som utgör en produkt med digitala element. Regelverket ställer krav på bland annat säker utveckling, sårbarhetshantering och säkerhetsuppdateringar under produktens livscykel. Rapporteringskraven börjar tillämpas den 11 september 2026 och huvuddelen av övriga krav den 11 december 2027.

Klassificera tjänsten innan RFP färdigställs

Innan kraven formuleras behöver försäkringsföretaget genomföra en inledande klassificering. Klassificeringen avgör vilka frågor som ska ställas, vilka krav som ska vara obligatoriska och vilka avtalsbilagor som behöver ingå.

Följande frågor bör besvaras:

  1. Är det en IKT-tjänst enligt DORA?
  2. Stödjer tjänsten en kritisk eller viktig funktion?
  3. Ska leverantören utföra en funktion eller arbetsuppgift som annars skulle ha utförts av försäkringsföretaget?
  4. Är den utlagda verksamheten eller funktionen av väsentlig betydelse?
  5. Vilka personuppgifter och informationsklasser ska behandlas?
  6. Kommer uppgifter att lagras, behandlas eller göras tillgängliga utanför EU eller EES?
  7. Innehåller lösningen AI eller andra former av automatiserat beslutsstöd?
  8. Ska systemet användas för försäkringsdistribution, rådgivning, kundkännedom, skadereglering eller ekonomisk rapportering?
  9. Är tjänsten beroende av koncentrerade molnleverantörer eller flera led av underleverantörer?
  10. Vilka konsekvenser får ett avbrott, en incident, en dataförlust eller ett leverantörsbyte?

Klassificeringen bör dokumenteras och godkännas innan RFP skickas ut. Den bör även uppdateras när leverantörernas lösningar och leveransmodeller blir kända.

Så bör kraven utformas i RFP

1. Beskrivning av tjänsten och leveransmodellen

Försäkringsföretaget måste förstå vad som faktiskt köps. Leverantören bör därför lämna en fullständig beskrivning av lösningen, inte bara marknadsföringsmaterial eller en övergripande produktpresentation.

RFP bör kräva information om:

  • samtliga tjänstekomponenter,
  • funktioner och moduler,
  • integrationer och API,
  • drift- och supportmodell,
  • tekniska beroenden,
  • datalagrings- och behandlingsplatser,
  • ansvarsfördelning mellan kund och leverantör,
  • vilka delar som utförs av underleverantörer,
  • vilka standardtjänster som inte kan anpassas.

Exempel på RFP-krav:

Leverantören ska lämna en fullständig beskrivning av samtliga funktioner, tjänstekomponenter, integrationspunkter, driftmiljöer, supporttjänster och tekniska beroenden. Det ska tydligt framgå vilka delar som utförs av leverantören respektive av underleverantörer samt vilka åtgärder och kontroller som förutsätter medverkan från Kunden.

2. Regulatoriskt stöd och dokumentation

RFP bör inte innehålla ett generellt krav på att leverantören ska vara ”DORA-compliant”. DORA riktar sig i första hand mot försäkringsföretaget, som behöver säkerställa att leverantörens tjänst och avtal gör det möjligt att uppfylla regelverket.

Leverantören bör därför beskriva:

  • hur tjänsten stödjer kundens efterlevnad,
  • vilken kontroll- och säkerhetsdokumentation som finns,
  • hur leverantören stödjer kundens riskbedömningar,
  • hur information för DORA-registret lämnas och uppdateras,
  • hur leverantören hanterar myndighetsförfrågningar,
  • vilka avtalskrav leverantören accepterar,
  • vilka avvikelser som finns från kundens regulatoriska krav.

Exempel på RFP-krav:

Leverantören ska beskriva hur tjänsten, leveransmodellen och de föreslagna avtalsvillkoren möjliggör för Kunden att uppfylla tillämpliga krav enligt DORA, GDPR och, där det är relevant, reglerna om uppdragsavtal. Svaret ska redovisa ansvarsfördelning, kontrollmiljö, tillgänglig dokumentation samt samtliga avvikelser från Kundens krav.

Exempel på krav avseende informationsregistret:

Leverantören ska på begäran lämna och löpande uppdatera den information som Kunden behöver för sitt informationsregister och sin tillsynsrapportering. Informationen ska bland annat omfatta avtalsstruktur, juridiska enheter, tjänstekategorier, leveransplatser, datalagringsplatser, underleverantörer och de funktioner som tjänsten stödjer.

3. Informationssäkerhet

Informationssäkerhetskraven behöver vara konkreta och möjliga att verifiera. Hänvisningar till allmänna standarder kan vara värdefulla, men de ersätter inte krav på de kontroller som är viktiga för den aktuella tjänsten.

RFP bör exempelvis omfatta:

  • styrning och ledningssystem för informationssäkerhet,
  • identitets- och behörighetshantering,
  • multifaktorautentisering,
  • hantering av privilegierade konton,
  • kryptering under överföring och lagring,
  • nyckelhantering,
  • loggning och övervakning,
  • separation mellan kunder och miljöer,
  • säker utvecklingsprocess,
  • sårbarhetsskanning och penetrationstester,
  • patch- och uppdateringshantering,
  • bakgrundskontroller och säkerhetsutbildning,
  • fysisk säkerhet,
  • hantering av säkerhetsbrister.

Exempel på RFP-krav:

Leverantören ska beskriva de tekniska och organisatoriska säkerhetsåtgärder som skyddar tjänsten och Kundens information. Svaret ska minst omfatta behörighetsstyrning, autentisering, kryptering, loggning, sårbarhetshantering, säker utveckling, separation mellan kunder, övervakning och hantering av privilegierad åtkomst.

Leverantören bör även redovisa bevis, exempelvis certifieringar, oberoende granskningsrapporter, resultat från penetrationstester eller sammanfattningar av genomförda kontroller. Sådana underlag ska ses som stöd för bedömningen och inte som ersättning för försäkringsföretagets egen due diligence.

4. Personuppgifter, datalagring och tredjelandsöverföringar

Leverantören behöver redovisa hela kedjan för behandling av personuppgifter. Kravet bör omfatta produktion, test, support, säkerhetskopiering, loggning och katastrofåterställning.

Exempel på RFP-krav:

Leverantören ska redovisa samtliga länder och regioner där Kundens data kan lagras, behandlas, säkerhetskopieras eller göras tillgänglig för support. Redovisningen ska omfatta Leverantören och samtliga underleverantörer och underbiträden.

Planerade förändringar av datalagringsplats, behandlingsplats eller supportland ska meddelas Kunden i förväg. Kunden ska ges tillräcklig tid att genomföra en regulatorisk och dataskyddsrättslig riskbedömning innan förändringen genomförs.

RFP bör även fråga om:

  • personuppgifternas användningsändamål,
  • rättslig rollfördelning,
  • underbiträden,
  • lagrings- och gallringstider,
  • radering från säkerhetskopior,
  • överföringsmekanismer utanför EU/EES,
  • myndigheters möjliga åtkomst,
  • stöd vid konsekvensbedömningar,
  • hantering av registrerades rättigheter,
  • användning av kunddata för analys eller produktutveckling.

Leverantören bör inte få använda försäkringsföretagets data för egna ändamål utan uttryckligt och dokumenterat godkännande.

5. Incidenthantering och rapportering

Försäkringsföretaget kan ha korta tidsfrister för att bedöma och rapportera incidenter. Leverantören behöver därför informera bolaget tidigt, även om orsaken ännu inte är fullständigt utredd.

RFP bör reglera:

  • vad som ska betraktas som en incident,
  • initial rapporteringstid,
  • kontaktvägar och tillgänglighet,
  • vilken information som ska lämnas,
  • löpande statusuppdateringar,
  • bevarande av loggar och bevis,
  • rotorsaksanalys,
  • korrigerande åtgärder,
  • stöd vid myndighetsrapportering,
  • deltagande i efterföljande utredningar.

Exempel på RFP-krav:

Leverantören ska utan onödigt dröjsmål och senast inom den tidsfrist som anges i avtalet underrätta Kunden om en faktisk eller misstänkt IKT-incident, informationssäkerhetsincident eller personuppgiftsincident som kan påverka tjänsten, Kunden eller Kundens information.

Den initiala rapporteringen får inte fördröjas på grund av att incidentens omfattning eller grundorsak ännu inte är fullständigt fastställd. Leverantören ska därefter lämna löpande uppdateringar och det stöd som Kunden behöver för sin bedömning, hantering och rapportering.

Tidsfristen bör anpassas efter tjänstens kritikalitet. För kritiska tjänster kan det behövas en mycket kort initial rapporteringstid och en bemannad kontaktfunktion som är tillgänglig dygnet runt.

6. Kontinuitet och återställning

Leverantörens standardnivåer för återställning är inte alltid tillräckliga för försäkringsföretagets verksamhet. Kraven på RTO och RPO bör därför utgå från bolagets egen verksamhets- och konsekvensanalys.

RFP bör omfatta:

  • återställningstid, RTO,
  • tillåten dataförlust, RPO,
  • redundans och geografisk separation,
  • säkerhetskopiering,
  • återställning från backup,
  • reservrutiner,
  • kontinuitets- och katastrofplaner,
  • testfrekvens,
  • rapportering av testresultat,
  • hantering av identifierade brister,
  • deltagande i kundens kontinuitetsövningar.

Exempel på RFP-krav:

Leverantören ska uppfylla de RTO- och RPO-nivåer som anges av Kunden och upprätthålla dokumenterade och testade kontinuitets- och återställningsplaner. Leverantören ska regelbundet testa planerna, dokumentera resultatet och utan onödigt dröjsmål åtgärda identifierade brister.

Leverantören ska på begäran delta i Kundens kontinuitets-, återställnings- och krisövningar i den omfattning som är relevant för tjänsten.

Det bör också framgå hur leverantören prioriterar mellan sina kunder vid en omfattande störning. En generell uppgift om att leverantören har en kontinuitetsplan är inte tillräcklig.

7. Underleverantörer och leveranskedja

Många IT-tjänster bygger på flera leverantörsled. Ett SaaS-bolag kan använda en global molnplattform, externa supportbolag, säkerhetsleverantörer och specialiserade datatjänster.

RFP bör därför kräva en fullständig bild av leveranskedjan.

Exempel på RFP-krav:

Leverantören ska redovisa samtliga underleverantörer som används eller kan komma att användas för att leverera tjänsten. Redovisningen ska omfatta juridiskt namn, organisationsland, utförd tjänst, leveransplats, datalagringsplats och eventuell åtkomst till Kundens information.

Leverantören ansvarar fullt ut för underleverantörernas arbete och ska säkerställa att samtliga relevanta säkerhets-, sekretess-, dataskydds-, kontinuitets-, revisions- och regulatoriska krav förs vidare i underleverantörsavtalen.

Avtalet bör även ge försäkringsföretaget rätt att:

  • informeras i god tid före väsentliga förändringar,
  • genomföra en ny riskbedömning,
  • invända mot en ny underleverantör,
  • kräva riskreducerande åtgärder,
  • säga upp berörd tjänst om risken inte kan accepteras.

8. Revision, kontroll och myndighetsåtkomst

RFP behöver tydligt ange vilka revisions- och åtkomsträttigheter som krävs. Detta är särskilt viktigt när tjänsten stödjer en kritisk eller viktig funktion eller utgör ett väsentligt uppdragsavtal.

Exempel på RFP-krav:

Kunden, av Kunden utsedda granskare, revisorer och behöriga tillsynsmyndigheter ska ha rätt att få tillgång till den information som krävs för att granska tjänsten och Leverantörens efterlevnad av avtalade krav.

Rätten ska, när det är relevant och proportionerligt, omfatta dokumentgranskning, intervjuer, tekniska kontroller, revisioner, inspektioner och tillgång till lokaler från vilka tjänsten levereras.

Standardiserade granskningsrapporter, certifieringar och gemensamma revisioner kan användas som en del av kontrollmodellen. De bör däremot inte automatiskt ersätta rätten till egen granskning när en allvarlig incident, väsentlig brist eller myndighetsbegäran gör en riktad kontroll nödvändig.

9. SLA, KPI och KRI

SLA bör spegla tjänstens verkliga betydelse för försäkringsbolaget. Enbart ett generellt tillgänglighetsmått per månad ger sällan tillräcklig styrning.

RFP kan exempelvis ställa krav på:

  • tillgänglighet,
  • svarstider,
  • åtgärdstider,
  • incidenteskalering,
  • återställningstider,
  • genomförande av säkerhetsuppdateringar,
  • leverans av rapporter,
  • hantering av sårbarheter,
  • kapacitet och prestanda,
  • datakvalitet,
  • säkerhetskopiering,
  • genomförande av överenskomna åtgärder.

Exempel på RFP-krav:

Leverantören ska redovisa föreslagna SLA, KPI och KRI för tjänsten samt beskriva hur mätning, rapportering och eskalering ska genomföras. Mätvärdena ska vara objektivt verifierbara och tillgängliga för Kunden.

Upprepade eller allvarliga brister ska ge Kunden rätt att kräva en åtgärdsplan, förstärkt rapportering och andra riskreducerande åtgärder. Servicekrediter ska inte utgöra Kundens enda påföljd vid väsentliga eller återkommande brister.

10. Förändringshantering och tjänstens livscykel

En moln- eller SaaS-tjänst förändras kontinuerligt. Leverantören kan byta underleverantör, flytta data, ändra arkitektur eller avveckla funktioner. Förändringarna kan påverka försäkringsföretagets riskklassificering och regulatoriska bedömningar.

RFP bör kräva förhandsinformation om förändringar som påverkar:

  • funktionalitet,
  • säkerhet,
  • arkitektur,
  • integrationer,
  • datalagringsplatser,
  • underleverantörer,
  • AI-modeller,
  • kontrollmiljö,
  • support,
  • avveckling av produkt eller version,
  • ägande och kontroll över leverantören.

Exempel på RFP-krav:

Leverantören ska i god tid informera Kunden om planerade väsentliga förändringar av tjänsten eller leveransmodellen. Informationen ska vara tillräcklig för att Kunden ska kunna bedöma förändringens operativa, säkerhetsmässiga, regulatoriska och kommersiella konsekvenser innan förändringen genomförs.

Kunden ska ha rätt att invända, kräva riskreducerande åtgärder eller säga upp berörd tjänst om en förändring medför en väsentlig och oacceptabel risk.

11. Krav på AI-funktioner

AI-funktioner bör behandlas som en egen del av RFP. Leverantören ska inte enbart svara på om systemet ”använder AI”, utan redovisa hur AI används och vilka konsekvenser användningen får.

RFP bör kräva information om:

  • samtliga AI- och maskininlärningskomponenter,
  • funktionernas avsedda användning,
  • vilka beslut eller rekommendationer som påverkas,
  • leverantörens och kundens roller enligt AI-förordningen,
  • använda modeller och modellversioner,
  • tränings-, test- och indata,
  • användning av generella AI-modeller,
  • loggning och spårbarhet,
  • mänsklig kontroll,
  • noggrannhet och felmarginaler,
  • tester av diskriminerande utfall,
  • robusthet och cybersäkerhet,
  • modellförändringar och uppdateringar,
  • möjlighet att stänga av en AI-funktion.

Exempel på RFP-krav:

Leverantören ska redovisa samtliga AI-komponenter som ingår i eller används för att leverera tjänsten. Redovisningen ska omfatta avsett användningsområde, modelltyp, ansvarsfördelning, använda datakategorier, loggning, mänsklig kontroll, noggrannhet, robusthet, säkerhet och hantering av modellförändringar.

Kundens data får inte användas för träning, finjustering eller förbättring av Leverantörens eller tredje parts modeller utan Kundens föregående skriftliga godkännande.

Leverantören ska i förväg informera Kunden om väsentliga förändringar av en AI-modell eller dess användningsområde och lämna den dokumentation som Kunden behöver för att genomföra en ny risk- och regelefterlevnadsbedömning.

12. Exit, dataportabilitet och leverantörsbyte

Exitkraven bör utformas redan i RFP. När avtalet ska avslutas är det ofta för sent att börja förhandla om dataformat, migreringsstöd och kostnader.

RFP bör ställa krav på:

  • export av samtliga kunddata,
  • export av metadata och konfigurationer,
  • tillgång till loggar och historik,
  • dokumentation av integrationer och datamodeller,
  • strukturerade och maskinläsbara format,
  • övergångsstöd,
  • kunskapsöverföring,
  • fortsatt drift under migreringen,
  • stöd till ny leverantör,
  • tydliga och förutsebara kostnader,
  • radering efter genomförd övergång,
  • skriftligt raderingsintyg,
  • test av exitplanen.

Exempel på RFP-krav:

Vid avtalets upphörande ska Leverantören göra Kundens data, metadata, konfigurationer, loggar och relevant dokumentation tillgängliga i ett strukturerat, allmänt använt och maskinläsbart format.

Leverantören ska tillhandahålla det stöd som skäligen krävs för att överföra tjänsten till Kunden eller en ny leverantör och säkerställa kontinuitet under övergångsperioden.

Efter Kundens godkännande av genomförd övergång ska Leverantören radera samtliga kvarvarande kopior av Kundens data, med undantag för uppgifter som måste bevaras enligt lag, och lämna ett skriftligt raderingsintyg.

Exitplanen bör testas under avtalsperioden. Ett dokument som aldrig har prövats ger begränsad trygghet vid ett verkligt leverantörsbyte.

13. Kundinformation, försäkringsdistribution och tillgänglighet

För system som används i kundresan behöver RFP även innehålla verksamhetsspecifika krav.

Det kan exempelvis gälla stöd för:

  • dokumentation av kundens krav och behov,
  • versionshantering av produktinformation,
  • registrering av rekommendationer,
  • lämplighetsbedömningar,
  • bevisning om vilken information kunden har fått,
  • information på varaktigt medium,
  • samtycken och kundens val,
  • kundkännedom och riskklassificering,
  • spårbarhet och revisionsloggar,
  • digital tillgänglighet,
  • testning av webb- och mobilgränssnitt.

Exempel på RFP-krav:

Lösningen ska säkerställa fullständig och sökbar spårbarhet av kundens val, lämnad information, genomförda kontroller, rekommendationer och beslut. Det ska vara möjligt att i efterhand fastställa vilken version av information, villkor och produktdokumentation som presenterades för kunden vid en viss tidpunkt.

Leverantören ska beskriva hur lösningen uppfyller tillämpliga tillgänglighetskrav och hur tillgängligheten testas, dokumenteras och upprätthålls vid nya releaser och förändringar.

Kräv strukturerade och verifierbara leverantörssvar

Leverantörerna bör inte få besvara regulatoriska och säkerhetsmässiga krav med ett enkelt ”ja”.

För varje krav bör leverantören redovisa:

  1. Om kravet uppfylls fullt ut, delvis eller inte alls.
  2. Hur kravet uppfylls.
  3. Vilken dokumentation eller vilket bevis som styrker svaret.
  4. Var åtagandet kommer att regleras i avtalet.
  5. Vilka förutsättningar eller beroenden som finns.
  6. Eventuella avvikelser och föreslagna alternativa lösningar.
  7. När en eventuell kvarstående brist kommer att vara åtgärdad.

Ett lämpligt svarskrav kan formuleras så här:

För varje krav ska Leverantören ange ”Uppfylls”, ”Uppfylls delvis” eller ”Uppfylls inte”. Svaret ska innehålla en beskrivning av lösningen, hänvisning till tillgängligt bevismaterial, hänvisning till föreslagen avtalsbestämmelse samt en fullständig redovisning av eventuella reservationer, beroenden och avvikelser.

Det minskar risken för att leverantörens svar senare tolkas som allmän information som inte ingår i det bindande avtalet.

Skallkrav, utvärderingskrav och avtalskrav

Alla krav bör inte hanteras på samma sätt.

Regulatoriskt nödvändiga krav som inte kan hanteras genom alternativa kontroller bör normalt vara obligatoriska skallkrav. Det kan exempelvis gälla myndighetsåtkomst, incidentrapportering, personuppgiftsbiträdesavtal, dataåtkomst och vissa revisionsrättigheter.

Andra krav kan utvärderas utifrån kvalitet och mognad. Det kan exempelvis gälla:

  • leverantörens säkerhetsorganisation,
  • kvaliteten på kontinuitetsplaneringen,
  • graden av automatiserad loggning,
  • portabilitet och migreringsverktyg,
  • rapportering och uppföljning,
  • leverantörens förmåga att stödja kundens kontroller.

Utvärderingen bör väga in både sannolikheten för en brist och konsekvensen för försäkringsföretaget. Ett lågt pris bör inte kunna kompensera för en regulatorisk risk som företaget inte har möjlighet att acceptera.

Säkerställ att RFP-svaren blir bindande

En vanlig brist är att RFP innehåller omfattande krav medan leverantörens slutliga standardavtal bara reglerar en mindre del av dem.

Det bör därför framgå redan i RFP att:

  • leverantörens svar ska vara bindande,
  • samtliga avvikelser ska redovisas tillsammans med anbudet,
  • kravspecifikationen ska bifogas avtalet,
  • säkerhets-, dataskydds-, kontinuitets- och exitbilagor ska ingå i avtalet,
  • avtalets prioritetsordning ska vara tydlig,
  • leverantörens standardvillkor inte ska ha företräde framför särskilt överenskomna krav,
  • viktiga krav ska verifieras under införandet,
  • godkänd acceptanstest ska krävas före produktionssättning.

Det bör också finnas en tydlig koppling mellan krav, avtalsvillkor och den löpande leverantörsuppföljningen. Ett krav som inte följs upp riskerar att förlora sin praktiska betydelse.

Vanliga misstag vid RFP för IT-system i försäkringsbolag

Regulatorisk klassificering görs för sent

När klassificeringen görs efter leverantörsvalet kan det visa sig att den valda leverantören inte accepterar nödvändiga avtalskrav eller inte kan lämna efterfrågad information.

RFP frågar bara om leverantören följer DORA

Ett ja-svar säger mycket lite. RFP behöver fråga hur leverantören stödjer kundens efterlevnad och vilken information, kontroll och avtalsmässig rätt som erbjuds.

Säkerhets- och avtalskraven skickas efter leverantörsvalet

Om kraven kommer först under slutförhandlingen blir försäkringsföretagets förhandlingsposition svagare. Kraven bör ingå i RFP och accepteras eller kommenteras i anbudet.

Certifieringar betraktas som fullständig bevisning

ISO-certifieringar och oberoende granskningsrapporter är värdefulla, men de visar inte automatiskt att tjänsten uppfyller alla verksamhets- och avtalskrav.

Underleverantörskedjan granskas inte

Riskerna finns ofta längre ned i leveranskedjan. Försäkringsföretaget behöver känna till vilka leverantörer som är kritiska och var data och tjänster faktiskt hanteras.

Exitkraven är för generella

Formuleringar om att kunden ”äger sin data” är inte tillräckliga. Det behövs praktiska krav på format, tidsfrister, migreringsstöd, kostnader, dokumentation och radering.

Leverantörens svar förs inte in i avtalet

Löften i presentationer, demonstrationer och RFP-svar bör dokumenteras i bindande avtalsbilagor. Annars kan det bli svårt att kräva att de uppfylls.

Vanliga frågor

Måste IT-leverantören vara DORA-certifierad?

Nej. Det finns inte någon generell DORA-certifiering som innebär att leverantören automatiskt uppfyller försäkringsföretagets krav. Försäkringsföretaget behöver själv bedöma tjänsten, leverantören, riskerna och avtalsvillkoren.

Är alla SaaS-tjänster utlagd verksamhet?

Nej. En SaaS-tjänst kan omfattas av DORA utan att utgöra ett uppdragsavtal eller utlagd verksamhet enligt försäkringsrörelselagen. Bedömningarna behöver göras separat.

Räcker det att leverantören är certifierad enligt ISO 27001?

Nej. Certifieringen är ett viktigt underlag, men försäkringsföretaget behöver även bedöma den specifika tjänsten, leveransomfattningen, underleverantörerna, avtalsvillkoren och de risker som är relevanta för verksamheten.

Måste all data lagras inom Sverige eller EU?

Det finns inte ett generellt krav på att all data alltid måste lagras i Sverige eller EU. Försäkringsföretaget behöver däremot veta var data lagras och behandlas, säkerställa lagligt stöd för eventuella tredjelandsöverföringar och bedöma riskerna med supportåtkomst, underleverantörer och utländsk lagstiftning.

Ska alla regulatoriska krav vara skallkrav?

Inte nödvändigtvis. Krav som är en förutsättning för regelefterlevnad och som inte kan hanteras genom alternativa kontroller bör normalt vara obligatoriska. Andra krav kan utvärderas utifrån kvalitet, mognad, risk och kostnad.

Sammanfattning

En väl genomförd RFP för IT-system och IT-tjänster i ett försäkringsbolag börjar med en regulatorisk klassificering. Försäkringsföretaget behöver förstå om tjänsten omfattas av DORA, om den utgör utlagd verksamhet, vilka personuppgifter som behandlas, om AI används och vilka verksamhetsspecifika regler som systemet ska stödja.

Därefter behöver regelverken översättas till konkreta och verifierbara krav på bland annat:

  • informationssäkerhet,
  • incidenthantering,
  • kontinuitet,
  • dataskydd,
  • underleverantörer,
  • revision och myndighetsåtkomst,
  • förändringshantering,
  • AI-styrning,
  • dataportabilitet,
  • exit och leverantörsbyte.

Kraven behöver ställas redan i RFP, utvärderas tillsammans med anbudet och därefter föras in i det bindande avtalet. På så sätt blir regelefterlevnad en integrerad del av leverantörsvalet i stället för en fråga som behöver lösas efter att beslutet redan har fattats.

Behöver ni stöd i er RFP?

IJMO Consulting hjälper försäkringsbolag och andra finansiella företag att klassificera IT-tjänster, ta fram RFP-underlag, genomföra leverantörsgranskningar, utvärdera anbud och säkerställa att regulatoriska krav blir en del av avtalet och den fortsatta leverantörsstyrningen.

Klicka här för att läsa mer om våra tjänster

Kostnadsfri checklista för försäkringsbolag som upphandlar IT-system, SaaS och IT-tjänster. Omfattar DORA, GDPR, informationssäkerhet, AI, underleverantörer, kontinuitet och exit.


Om författaren

Mathias Olsson är grundare av IJMO Consulting och senior inköpskonsult med erfarenhet av IT-inköp, SaaS, ERP, strategisk sourcing, avtalsförhandling och leverantörsstyrning. Han har arbetat i ledande inköps- och sourcingroller inom bland annat försäkring, IT, telekom och transport. Hans artiklar bygger på praktisk erfarenhet från upphandlingar, avtalsförhandlingar och förändringsprojekt.

Läs mer om Mathias Olsson →

Publicerad: 28 mars 2026

Senast uppdaterad: 30 augusti 2026