Vad innebär ansvarsbegränsning i avtal om programvara?

Vad ansvarsbegränsning innebär i ett programvaruavtal

Ansvarsbegränsning innebär att parterna avtalar om att begränsa det ekonomiska ansvaret för vissa händelser eller skador. Villkoret är vanligt i kommersiella avtal och särskilt i komplexa affärsrelationer som leverans-, IT- och konsultavtal. I mjukvarulicenser vill leverantören oftast begränsa ansvaret för indirekta skador. Klausulen blir aktuell när risken för skador, förseningar eller fel är påtaglig, exempelvis i tekniska tjänster där driftstopp kan ge stora kostnader.

Klausulen handlar om riskfördelning och förutsägbarhet, inte om att en part helt slipper ansvar. Eftersom skador är svåra att överblicka på förhand ger en välformulerad bestämmelse förutsägbarhet och gör att företag kan anpassa ansvaret till ersättningen. Leverantörer i stora projekt vill begränsa exponeringen; beställare vill säkerställa skydd vid fel.

En ansvarsbegränsning består normalt av tre byggstenar: en definition av vilka skador som omfattas, ett ansvarstak för ersättningen och undantag där begränsningen inte gäller. Ansvarsbegränsning, ansvarstak och liability cap är olika namn på samma villkor. När ansvaret utesluts helt i stället för att begränsas talar man om friskrivning.

Begränsningen är inte absolut. Ett ansvarsbegränsningsvillkor måste hålla vid prövning och kan inte utan vidare åberopas i alla situationer. Det måste läsas tillsammans med tvingande lagregler, avtalets undantag och jämkningsregeln i 36 § avtalslagen.

Varför programvara ofta kräver särskilda ansvarsvillkor

I ett SaaS-avtal har leverantören en mer omfattande roll än i många traditionella konsult- eller licensavtal. Leverantören utvecklar, driftar, underhåller, uppdaterar och säkrar tjänsten över tid. Ansvaret omfattar därför tillgänglighet och drift; säkerhet och incidenthantering; underleverantörer och molninfrastruktur; immateriella rättigheter; dataskydd och personuppgiftsbiträdesfrågor; ändringar i tjänsten; support och service levels; tekniska integrationer samt dokumentation och complianceunderlag.

Leverantörens riskexponering är både operativ och skalbar. Samma tjänst säljs till många kunder, vilket ger effektivitet och lägre pris per kund, men riskerna skalar också. Ett fel kan drabba många kunder samtidigt; en säkerhetsincident kan kräva omfattande åtgärder; ett immaterialrättsligt krav kan träffa hela produkten; en prisändring hos en kritisk molnleverantör påverkar marginalen i alla kundavtal.

Om varje större kund dessutom får individuellt förhandlade åtaganden blir den samlade riskbilden lätt oproportionerlig. Exempel: obegränsat ansvar för dataskydd, obegränsat ansvar för säkerhetsincidenter, bred IP-indemnity utan tydliga undantag, ansvar upp till flera års avgifter eller ersättning för indirekta skador och produktionsbortfall.

Kundens risk är normalt mer avgränsad: den egna användningen av tjänsten, den egna organisationen, den egna datan och de egna interna processerna. Den är inte oviktig, men av en annan typ.

Ett licensavtal för mjukvara och ett SaaS-avtal skiljer sig åt. I licensavtalet kretsar ansvaret kring fel i den levererade produkten, medan SaaS-avtalet också omfattar drift, uppdateringar och säkerhet över tid.

Direkta och indirekta skador – vad begränsas egentligen?

Förhandlingen kretsar i praktiken kring två frågor: ska ersättningsansvaret begränsas för indirekta eller medelbara skador, och ska det begränsas till ett visst belopp? Leverantören vill oftast utesluta indirekta skador, eftersom de är svåra att förutse och kan leda till omfattande ersättningsskyldighet.

En vanlig konstruktion är att leverantören svarar för direkta eller omedelbara skador men inte för indirekta. Ansvarsbegränsningen avgör alltså inte bara hur mycket som betalas, utan också vilka skadetyper som alls räknas med.

Indirekt skada är bland annat utebliven vinst till följd av att avtal med tredje man fallit bort eller inte uppfyllts riktigt, eller förlust som beror på att köparen inte kunnat använda den inköpta produkten på avsett sätt. Dit hör typiskt också utgifter för att utreda ett avtalsbrott, extra transport- och lagringskostnader, utgifter för att rätta ett fel och extra utgifter för att skaffa en ersättande prestation.

I finsk köplag (355/1987) ges exempel på indirekt skada i stället för en uttrycklig definition. Finsk rättspraxis (HD:2014:61) har bedömt att ett dröjsmålsvite som köparen tvingas betala till en tredje avtalspart är indirekt förlust i förhållandet mellan säljaren och köparen.

Gränsdragningen är inte självklar och bör skrivas in i avtalet: vad som är direkt respektive indirekt skada, vilka kostnadsposter som hör till respektive kategori och vilken av dem som omfattas av begränsningen.

Direkta vs indirekta skador i programvaruavtal

Ansvarstak, undantag och försäkring

Ett ansvarstak kan vara ett fast ersättningsbelopp eller bindas till avtalsvärdet, exempelvis årliga avgifter. Taket sätter den yttre gränsen för leverantörens totala ersättningsskyldighet. Frågan om indirekta skador avgör vilka skadetyper som alls räknas in under taket.

Parametrarna bör förhandlas samtidigt: ett högt tak utan undantag för indirekta skador ger en helt annan riskbild än ett lägre tak med snävt definierade skadetyper. Taket kombineras ofta med undantag.

Vanliga områden att gå igenom är uppsåt och grov vårdslöshet, immaterialrättsliga intrång, dataskyddsincidenter och säkerhetsbrister. Undantagen innebär att ansvaret inte begränsas alls – eller begränsas på annat sätt – för just dessa fall. De får därför stor betydelse för den samlade riskexponeringen.

Tvingande regler och allmänna kontraktsrättsliga principer sätter ytterligare gränser. Enligt 36 § avtalslagen kan ett ansvarsbegränsningsvillkor jämkas efter en helhetsvärdering.

NJA 2017 s. 113 gällde en villaköpare som stämde ett besiktningsföretag sedan besiktningsmannen förbisett fel för cirka 1,8 mkr i en villa värd cirka 9 mkr; avtalet begränsade ansvaret till 15 prisbasbelopp. Högsta domstolen prövade begränsningen enligt 36 § i en helhetsvärdering och fann inte tillräckliga skäl för jämkning. Tröskeln för att åsidosätta en ansvarsbegränsning i ett kommersiellt tjänsteavtal är hög, men bedömningen görs samlat och inte mekaniskt.

Eftersom ett ansvarstak lämnar ett glapp mellan faktisk skada och utfallande ersättning, kan försäkring användas som komplement – både leverantörens egen ansvarsförsäkring och kundens möjlighet att teckna skydd för risker som faller utanför avtalets begränsning.

Särskilda risker i SaaS, moln och leverantörskedjor

SaaS-avtal bör inte bygga på en mekanisk idé om att allt ska vara ömsesidigt. Riskfördelningen bör i stället spegla vem som kontrollerar risken, vem som kan förebygga den och vem som rimligen kan bära den. Leverantören styr utveckling, drift, uppdateringar, säkerhet och underleverantörer, medan kundens risk är knuten till den egna användningen. En spegelvänd klausul blir därför lätt missvisande.

Underleverantörer och molninfrastruktur hör till de områden där ansvaret måste hanteras uttryckligen, tillsammans med tillgänglighet, säkerhetsincidenter, dataskydd och immateriella rättigheter. En vanlig felkonstruktion är att varje enskild kund får ett eget, vidare åtagande än standardavtalet. Varje avvikelse kan kännas hanterbar när affären ska stängas, men samlade kan de skapa en riskbild som bolaget inte kan försvara.

Programvara bygger dessutom ofta på öppen källkod, vilket för ansvarsfrågan genom hela leverantörskedjan. Relevanta krav rör säker leveranskedja, hantering av sårbarheter och transparens. De bör läsas mot NIS 2, Cyber Resilience Act (CRA) och den kommande molncertifieringen EUCS.

Personuppgiftsbiträdesavtal och dataskydd hör till de områden som måste hanteras uttryckligen. En klausul som låter leverantörens standardvillkor gälla vid personuppgiftsbehandling kan föra svensk data under amerikansk lag enligt US CLOUD Act, i strid med GDPR och Schrems II-domen.

För svenska SaaS- och IT-bolag är branschvillkor som TechSveriges villkor en vanlig utgångspunkt när ansvarstak och riskfördelning ska diskuteras med större kunder.

Ett närliggande exempel på riskfördelningsfrågor i kedjan är jurisdiktion och datasuveränitet. En definition av "privat moln" som enbart bygger på nätverk och serverkapacitet säger inget om vem som äger infrastrukturen eller vilken jurisdiktion driftpersonalen lyder under.

När sektorskrav styr utformningen av avtalet

DORA (Digital Operational Resilience Act) trädde i kraft den 17 januari 2025 och ställer krav på både finansiella företag och deras ICT-tjänsteleverantörer. Varje IT-avtal i finanssektorn måste innehålla specifika klausuler, och leverantörerna måste kunna bevisa sin säkerhetsnivå.

DORA definierar ICT-tjänsteleverantörer brett: molntjänstleverantörer, mjukvaruleverantörer för kärnbankssystem, trading-plattformar och betalningssystem, dataleverantörer och analysverktyg, IT-konsulter som hanterar kritiska system, outsourcade IT-driftleverantörer samt backup- och katastrofåterställningstjänster.

Grundkraven gäller alla ICT-leverantörer till finanssektorn, oavsett storlek eller tjänstens kritikalitet: avtal med obligatoriska klausuler om servicenivåavtal, revisionsrätt och incidentrapportering, registrering i finansföretagets leverantörsregister, exitstrategier samt löpande riskbedömning och övervakning.

För leverantörer som stödjer kritiska eller viktiga funktioner tillkommer djupare exit- och utbytbarhetsanalys, mer omfattande riskbedömning och testning, tätare uppföljning och dokumentation samt specifika krav på möjlighet att genomföra revisioner.

EU:s finanstillsynsmyndigheter EBA, ESMA och EIOPA kan utse enskilda leverantörer till kritiska ICT-tredjepartsleverantörer på EU-nivå. Det gäller främst stora systemleverantörer som betjänar många finansiella företag.

Utpekade kritiska ICT-tredjepartsleverantörer får en huvudansvarig tillsynsmyndighet (Lead Overseer), måste registrera sig hos tillsynsmyndigheter, genomgår regelbundna säkerhetsrevisioner och rapporterar direkt till myndigheter.

För avtalsutformningen innebär det att ansvarsbegränsningen måste samspela med sektorskraven: klausuler om revision, incidentrapportering och exit kan inte begränsas bort. Leverantörens möjlighet att visa sin säkerhetsnivå blir en del av det underlag kunden behöver.

Kritiska krav enligt DORA för ICT-leverantörer i finanssektorn

Praktisk checklista för att granska en ansvarsbegränsning

– Identifiera vilka typer av skador eller kostnader som ska omfattas och ta ställning till om begränsningen ska gälla både direkta och indirekta skador. Definiera skadetyperna uttryckligen i avtalet.

– Bestäm ett tak för skadeståndsansvaret, exempelvis kopplat till avtalsvärdet eller till årliga avgifter. Bestäm samtidigt om indirekta skador ska uteslutas helt.

– Tänk igenom effekten av undantag, exempelvis för uppsåt och grov vårdslöshet. Överväg separata lösningar för särskilda riskområden som immaterialrätt, dataskydd och säkerhetsincidenter.

– Gå igenom personuppgiftsbiträdesavtal och dataskyddsfrågor för sig. Vid molntjänster bör villkoren för personuppgiftsbehandling prövas mot GDPR och Schrems II-domen.

– Säkerställ att klausulen inte strider mot tvingande lagregler och pröva den mot 36 § avtalslagen i en helhetsvärdering. Kontrollera samtidigt om sektorskrav – exempelvis DORA för finanssektorn – kräver klausuler om servicenivå, revision, incidentrapportering och exit.

– Överväg om särskilda försäkringar kan komplettera ansvarsbegränsningen. Dokumentera hur risken fördelats mellan parterna.

Praktisk checklista för granskning av ansvarsbegränsning

Läs mer: Villkor för ansvarsbegränsning – en börda eller ett smart drag? (fondia.com).