​Aansprakelijkheid in IT-contracten: hoe houd je de risico’s én de klant binnen boord?

Dat is begrijpelijk. Een leverancier wil voorkomen dat een opdracht van € 50.000 leidt tot een schadeclaim van enkele miljoenen. Terwijl de klant wil voorkomen dat hij met aanzienlijke schade blijft zitten als bedrijfskritische software uitvalt of een implementatie mislukt. Dit maakt de aansprakelijkheidsregeling misschien wel het belangrijkste onderdeel van een IT-contract. Niet omdat partijen verwachten dat er iets misgaat, maar omdat zij vooraf moeten bepalen wie welk risico draagt als dat toch gebeurt.

In dit artikel in onze reeks over IT-contracten bespreek ik de aansprakelijkheid in IT. Je leest welke aansprakelijkheidsbeperkingen in de praktijk vaak voorkomen, waarom zij bestaan en waar de grenzen van een redelijke risicoverdeling liggen. Daarbij besteed ik ook aandacht aan ict-contracten, vrijwaringen en de grootste risico’s voor een it-leverancier.

Waarom aansprakelijkheid in IT bijzonder is

In weinig sectoren staat de mogelijke schade zo uit verhouding tot de contractwaarde als in de IT-sector. Een softwarelicentie van € 20.000 kan een bedrijfsproces ondersteunen waarmee een klant jaarlijks tientallen miljoenen euro’s omzet. Een storing van enkele uren kan leiden tot omzetverlies, stilgevallen productie, contractuele boetes, reputatieschade en claims van afnemers.

Tegelijkertijd heeft de leverancier slechts beperkte invloed op een groot deel van die schade. Factoren zoals de inrichting van de organisatie van de klant, de aanwezigheid van back-ups, de gekozen beveiligingsmaatregelen, de wijze waarop de software wordt gebruikt en de afhankelijkheid van andere systemen bepalen immers mede de omvang ervan. Daar komt nog bij dat leveranciers steeds vaker werken met software van derden, cloudplatforms en opensourcecomponenten. Ook cybercriminaliteit en geopolitieke ontwikkelingen vergroten de onzekerheid. Een ict-leverancier of ict-dienstverlener kan daardoor onmogelijk ieder risico volledig beheersen.

Een onbeperkte aansprakelijkheid is onder die omstandigheden in de praktijk vaak moeilijk verdedigbaar. Dit zou betekenen dat een relatief beperkte vergoeding tegenover een vrijwel onbeperkt financieel risico staat. Dat risico is bovendien vaak niet of slechts gedeeltelijk verzekerbaar. Dit verklaart waarom beperkingen van aansprakelijkheid in de IT eerder regel dan uitzondering zijn. De risico’s liggen daarbij niet alleen in de uitvoering van de dienst, maar ook in dataverlies, beveiligingsincidenten en afhankelijkheid van een andere leverancier of opdrachtnemer.

Wat zegt de wet over aansprakelijkheid in IT?

​Op grond van de wet moet een partij de schade vergoeden die ontstaat door een tekortkoming die haar kan worden toegerekend (artikel 6:74 BW). Aansprakelijkheid kan onder omstandigheden ook voortvloeien uit een onrechtmatige daad (artikel 6:162 BW).

Partijen mogen de aansprakelijkheid in hun overeenkomst beperken. Het Nederlandse contractenrecht biedt partijen daarbij veel vrijheid. Zeker professionele partijen kunnen in hun overeenkomst grotendeels bepalen wat de omvang van de aansprakelijkheid is, welke soorten schade voor vergoeding in aanmerking komen en onder welke voorwaarden een partij aanspraak kan maken op schadevergoeding.

Die contractsvrijheid kent echter grenzen. Een aansprakelijkheidsbeding kan onder omstandigheden buiten toepassing blijven of worden vernietigd. Dat speelt bijvoorbeeld als toepassing van het beding naar maatstaven van redelijkheid en billijkheid onaanvaardbaar is (artikel 6:248 lid 2 BW) of als een exoneratie (gehele of gedeeltelijke uitsluiting van aansprakelijkheid) in de algemene voorwaarden onredelijk bezwarend is (artikel 6:233 BW). In de verhouding tussen professionele partijen gebeurt dat niet snel, maar het onderstreept wel dat een aansprakelijkheidsregeling meer vraagt dan het overnemen van een standaardclausule.

Waar gaan leveranciers in de praktijk vaak de mist in?

In de praktijk zie ik dat aansprakelijkheidsregelingen vaak minder doordacht zijn dan op het eerste gezicht lijkt. ​Partijen nemen regelmatig standaardbepalingen uit eerdere contracten of algemene voorwaarden over zonder te beoordelen of deze nog aansluiten bij de dienstverlening of de risico’s van het project. Veel voorkomende voorbeelden zijn:

1. een aansprakelijkheidsplafond zonder uitsluiting van indirecte schade;
2. algemene voorwaarden die afwijken van het hoofdcontract zonder duidelijke voorrangsregeling;
3. onbeperkte vrijwaringsverplichtingen die de aansprakelijkheidsbeperking feitelijk uithollen;
4. definities van directe en indirecte schade die ruimte laten voor discussie; of
5. simpelweg de situatie dat algemene voorwaarden niet correct toepasselijk zijn en in de overeenkomst geen beperking is opgenomen.

​Een leverancier doet er bovendien goed aan te controleren of de contractuele verplichtingen aansluiten bij de feitelijke dienstverlening. Een ruime toezegging over beschikbaarheid, beveiliging of nakoming kan in de praktijk grote gevolgen hebben als daarvoor geen passende beperking of procedure is opgenomen. Hierover lees je meer in ‘SLA en uptime, beloof wat je kunt waarmaken’.

Het aansprakelijkheidsplafond in IT

​Bij aansprakelijkheid in IT speelt het aansprakelijkheidsplafond een belangrijke rol. Vrijwel iedere IT-overeenkomst beperkt de aansprakelijkheid van de leverancier tot een maximumbedrag. Dit maximumbedrag wordt ook wel het aansprakelijkheidsplafond genoemd. De gedachte daarachter is eenvoudig. Partijen bepalen vooraf welk financieel risico de leverancier maximaal accepteert. Daarmee ontstaat voorspelbaarheid voor beide partijen. In de praktijk komen verschillende varianten voor, zoals een beperking tot:

1. de totale contractsom;
2. de vergoeding die gedurende de laatste twaalf maanden is betaald;
3. een vast bedrag;
4. de uitkering onder de beroeps- of cyberverzekering.

Geen van deze systemen is per definitie beter dan de andere. De vraag is vooral of het gekozen plafond past bij de aard van de opdracht en de risico’s die de leverancier bereid is te nemen. Een implementatieproject van € 800.000 rechtvaardigt doorgaans een ander aansprakelijkheidsniveau dan een SaaS-abonnement van € 5.000 per jaar.

Het aansprakelijkheidsplafond moet bovendien commercieel verdedigbaar blijven. Een leverancier die een bedrijfskritisch ERP-systeem levert en zijn aansprakelijkheid beperkt tot één maand abonnementskosten, zal in de praktijk vaak op stevige weerstand stuiten. Niet omdat een beperking onredelijk is, maar omdat de verhouding tussen risico en vergoeding uit balans raakt.

De hoogte van het plafond vertelt niet het hele verhaal

Tijdens onderhandelingen besteden partijen vaak veel aandacht aan het maximale aansprakelijkheidsbedrag. Toch zegt dat bedrag op zichzelf relatief weinig. Een aansprakelijkheidsplafond van € 500.000 kan in de praktijk aanzienlijk ruimer uitpakken dan een plafond van € 1.000.000, als tegelijkertijd een groot aantal schadeposten is uitgesloten. Andersom kan een relatief bescheiden maximumbedrag juist een aanzienlijke aansprakelijkheid meebrengen wanneer nauwelijks beperkingen zijn opgenomen.

Een aansprakelijkheidsregeling moet daarom altijd als geheel worden beoordeeld. Het samenspel tussen het aansprakelijkheidsplafond, de uitgesloten schadeposten, de vrijwaringsbepalingen, de vervaltermijnen en de uitzonderingen bepaalt uiteindelijk hoe groot het risico daadwerkelijk is. Ook de omvang van de opdracht, de deskundigheid van de leverancier en de afhankelijkheid van de klant van de dienst zijn daarbij van belang.

Directe en indirecte schade: eenvoudiger gezegd dan gedaan

Vrijwel iedere aansprakelijkheidsregeling maakt onderscheid tussen directe en indirecte schade. Opvallend genoeg kent het Burgerlijk Wetboek deze begrippen niet. Dat betekent dat contractspartijen zelf moeten bepalen wat zij onder directe en indirecte schade verstaan. Een goede definitie van deze begrippen in de overeenkomst is daarom van groot belang. Partijen omschrijven directe schade meestal als schade die rechtstreeks voortvloeit uit de tekortkoming zelf. Denk hierbij bijvoorbeeld aan:

1. de kosten om software te herstellen;
2. de kosten om een foutieve implementatie opnieuw uit te voeren;
3. redelijke kosten om verdere schade te beperken;
4. kosten om de oorzaak van de schade vast te stellen.

In IT-contracten wordt onder indirecte schade vaak verstaan: schade die ontstaat als verder gevolg van de tekortkoming. Daarbij valt te denken aan:

1. omzetverlies;
2. gederfde winst;
3. gemiste besparingen;
4. reputatieschade;
5. verlies van klanten;
6. bedrijfsstagnatie;
7. claims van afnemers.

In de praktijk blijkt het onderscheid echter lang niet altijd scherp. Het staat partijen bovendien vrij om te bepalen dat posten als omzetverlies in hun verhouding wel directe schade zijn. Denk daarom, zowel in je standaardcontracten als wanneer je contracteert op basis van een contract van de klant, vooraf goed na over welke schadeposten je bereid bent te vergoeden en welke risicoverdeling in de gegeven omstandigheden redelijk is.

Voorbeelden

Neem een webwinkel die gedurende één dag niet bereikbaar is door een programmeerfout. Zou je de kosten van het herstellen van de software als directe schade aanmerken? Vrijwel zeker. Maar hoe kwalificeer je de misgelopen omzet? En de extra marketingkosten die nodig zijn om klanten terug te winnen? Of de boete die een belangrijke opdrachtgever oplegt omdat bestellingen niet tijdig zijn verwerkt?

Een ander voorbeeld zijn de kosten die een klant moet maken om een andere IT-leverancier in te schakelen nadat een implementatie is mislukt. Zijn dat herstelkosten die onder de directe schade vallen? Of zijn het kosten die voortvloeien uit de mislukte implementatie en dus als gevolgschade moeten worden aangemerkt?

Ook dataverlies leidt regelmatig tot discussie. De kosten van het terugplaatsen van een back-up kunnen een ander juridisch karakter hebben dan de schade die ontstaat doordat gegevens definitief verloren zijn gegaan.

Daarom verdient het aanbeveling om niet uitsluitend te spreken over ‘indirecte schade’, maar de uitgesloten schadeposten expliciet te benoemen. Doe je dat niet, dan zal in een geschil een rechter moeten beoordelen wat partijen redelijkerwijs over en weer hebben mogen verwachten met betrekking tot die begrippen. Hoe dit uitpakt is onzeker en hangt af van allerlei omstandigheden van het geval.

De uitsluiting van gevolgschade

Een van de meest voorkomende bedingen in IT-contracten is de uitsluiting van gevolgschade. Ook dit begrip lijkt eenvoudiger dan het is. In juridische zin bestaat namelijk geen eenduidige definitie van gevolgschade. De ene auteur gebruikt het begrip als synoniem voor indirecte schade, terwijl anderen daar een beperktere betekenis aan geven. Wie uitsluitend schrijft dat "gevolgschade is uitgesloten", creëert daarom juist ruimte voor discussie. Een zorgvuldige aansprakelijkheidsregeling noemt daarom de uitgesloten schadeposten afzonderlijk. Dat voorkomt interpretatieproblemen wanneer zich daadwerkelijk een geschil voordoet. In sommige gevallen kiezen partijen er bewust voor bepaalde begrippen minder nauwkeurig te omschrijven. Dat kan tijdens de onderhandelingen voordelen bieden, maar vergroot tegelijkertijd de kans op interpretatiegeschillen wanneer zich daadwerkelijk een probleem voordoet.

Wat regelen de NLdigital Voorwaarden?

Wie regelmatig afspraken over aansprakelijkheid in IT opstelt of beoordeelt, zal de aansprakelijkheidsregeling uit de NLdigital voorwaarden herkennen. Deze branchevoorwaarden vormen voor veel Nederlandse IT-leveranciers het uitgangspunt bij contractonderhandelingen over ict-contracten.

​Hoe beperken de NLdigital Voorwaarden de aansprakelijkheid?

De regeling is interessant omdat zij verschillende aansprakelijkheidsmechanismen combineert. Allereerst wordt de aansprakelijkheid voor directe schade beperkt tot de contractwaarde. Bij duurovereenkomsten geldt daarbij als uitgangspunt de vergoeding over één jaar. Daarnaast geldt een absoluut maximum van € 500.000. Voor schade door overlijden, lichamelijk letsel of zaakschade geldt een afzonderlijk maximum van € 1.750.000. Vervolgens sluiten de voorwaarden een groot aantal schadeposten expliciet uit. Daarbij gaat het onder meer om indirecte schade, gevolgschade, gederfde winst, gemiste besparingen, verminderde goodwill, bedrijfsstagnatie, aanspraken van afnemers en schade die samenhangt met door de klant voorgeschreven software of toeleveranciers.

Ook procedureel bevatten de voorwaarden belangrijke beperkingen. Zo ontstaat aansprakelijkheid in beginsel pas nadat de leverancier de gelegenheid heeft gekregen een tekortkoming te herstellen door middel van een ingebrekestelling. Daarnaast vervalt een aanspraak op schadevergoeding als de klant niet binnen 24 maanden nadat de vordering is ontstaan een rechtsvordering instelt. Tot slot vervallen de aansprakelijkheidsbeperkingen wanneer sprake is van opzet of bewuste roekeloosheid van de bedrijfsleiding van de leverancier. Daarmee sluiten de voorwaarden aan bij wat in commerciële contracten algemeen als aanvaardbaar wordt beschouwd.

​Hoe werkt deze aansprakelijkheidsregeling in de praktijk?

Opvallend is dat de NLdigital Voorwaarden niet kiezen voor één algemene exoneratie, maar voor een stelsel van opeenvolgende beperkingen. Juist die combinatie maakt de regeling in de praktijk effectief. Wie uitsluitend een aansprakelijkheidsplafond overneemt, mist een belangrijk deel van de bescherming die de branchevoorwaarden beogen te bieden.

Tegelijkertijd zijn de NLdigital Voorwaarden geen vanzelfsprekend eindpunt van iedere onderhandeling. Bij omvangrijke implementatie- of maatwerkprojecten blijkt regelmatig dat opdrachtgevers de standaardregeling te ver vinden gaan. Dat is begrijpelijk: naarmate een klant afhankelijker wordt van de software, neemt ook de behoefte toe aan ruimere aansprakelijkheidsafspraken.

De vrijwaring: de vergeten aansprakelijkheidsbepaling

Tijdens contractonderhandelingen gaat veel aandacht uit naar het aansprakelijkheidsplafond. Opvallend genoeg krijgt de vrijwaringsbepaling vaak veel minder aandacht. Dat is opmerkelijk, want juist een vrijwaring kan de leverancier alsnog blootstellen aan vrijwel onbeperkte aansprakelijkheid.

Een voorbeeld is een vrijwaring voor inbreuk op intellectuele eigendomsrechten. Een dergelijke bepaling verplicht de leverancier om de klant te beschermen tegen aanspraken van derden. Dat is op zichzelf niet ongebruikelijk. De vraag is echter of partijen ook de omvang van die vrijwaring begrenzen en daarop dezelfde aansprakelijkheidsregeling toepassen.

Hetzelfde geldt voor vrijwaringen rondom persoonsgegevens, cybersecurity of claims van toezichthouders. Wie uitsluitend kijkt naar het aansprakelijkheidsplafond, maar de vrijwaringsbepalingen ongemoeid laat, kan onaangenaam verrast worden.

Vrijwaringsbepalingen worden met regelmaat ook als tactiek toegepast. Er wordt dan bijvoorbeeld wel ingestemd met een ruime aansprakelijkheidsuitsluiting, maar op een andere plek in de overeenkomst wordt een zeer ruime vrijwaring opgenomen. Het is niet vanzelfsprekend dat de uitsluiting van de aansprakelijkheid ook geldt voor de vrijwaringsverplichtingen. Als dit niet expliciet is opgenomen en de vrijwaringsclausule is heel ruim omschreven, is de kans groot dat dit niet het geval is.

Procedurele beperkingen verdienen minstens zoveel aandacht

Niet alleen de omvang van de aansprakelijkheid is van belang. Ook de voorwaarden waaronder een schadeclaim kan worden ingesteld, bepalen in belangrijke mate het uiteindelijke risico.

Daarom bevatten veel IT-overeenkomsten procedurele waarborgen. Denk aan de verplichting om een leverancier eerst schriftelijk in gebreke te stellen, een klacht binnen een bepaalde termijn te melden of een vervaltermijn waarbinnen een rechtsvordering moet worden ingesteld. Zulke bepalingen geven de leverancier de gelegenheid een tekortkoming eerst zelf te herstellen en voorkomen dat jaren na afronding van een project alsnog omvangrijke schadeclaims worden ingesteld. Het is verstandig om ook hierover iets in de overeenkomst op te nemen.

Aansprakelijkheid staat nooit op zichzelf

Een goede aansprakelijkheidsregeling bestaat daarom uit meer dan één artikel in de overeenkomst. De werkelijke risicoverdeling wordt mede bepaald door bepalingen over de scope van de opdracht, de acceptatieprocedures, de service levels, hersteltermijnen, de informatie- en medewerkingsplicht van de klant, beveiligingsverplichtingen, back-ups en wijzigingsprocedures. Juist die bepalingen bepalen vaak of een leverancier überhaupt aansprakelijk wordt.

Een zorgvuldig ingerichte acceptatieprocedure of een duidelijke afbakening van verantwoordelijkheden voorkomt in veel gevallen meer discussie dan een verlaging van het aansprakelijkheidsplafond.

Privacy en cybersecurity vragen om extra aandacht

Bij aansprakelijkheid in IT verdienen afspraken over persoonsgegevens en cybersecurity bijzondere aandacht. Een datalek of beveiligingsincident kan leiden tot uiteenlopende schadeposten, zoals herstelkosten, aansprakelijkstellingen door betrokkenen en afhankelijk van de omstandigheden ook bestuurlijke handhaving en boetes.

Daarom is het verstandig om aansprakelijkheidsafspraken af te stemmen op de verwerkersovereenkomst en andere security-afspraken. Ook verdient het aanbeveling duidelijk vast te leggen welke verantwoordelijkheden bij de leverancier liggen en welke verplichtingen juist bij de klant horen. Daarmee wordt voorkomen dat verschillende contractdocumenten elkaar onbedoeld tegenspreken.

Een aansprakelijkheidsregeling is ook een onderhandelingsinstrument

Een aansprakelijkheidsregeling heeft niet alleen een juridische functie. Zij speelt ook een belangrijke rol tijdens contractonderhandelingen. ​Wanneer leveranciers toelichten waarom bepaalde beperkingen noodzakelijk zijn, blijken klanten vaak eerder bereid een evenwichtige regeling te aanvaarden dan wanneer leveranciers volstaan met een verwijzing naar ‘de standaardvoorwaarden’.

Dat vraagt wel om maatwerk. Een SaaS-oplossing die een ondersteunend bedrijfsproces faciliteert, rechtvaardigt doorgaans een andere risicoverdeling dan software waarop de volledige bedrijfsvoering van de klant afhankelijk is. Naarmate de impact van de dienstverlening groter wordt, neemt ook de behoefte van de klant aan ruimere aansprakelijkheidsafspraken toe. Een goede aansprakelijkheidsregeling gaat daarom niet over het zoveel mogelijk uitsluiten van aansprakelijkheid, maar over het vooraf verdelen van risico's op een manier die voor beide partijen aanvaardbaar is.

​Denk daarom vooraf goed na over de risico’s die de organisatie wel en niet wil aanvaarden. Zorg er ook voor dat de salesmedewerkers die met klanten onderhandelen deze uitgangspunten kennen en de aansprakelijkheidsbepalingen begrijpen.

De verzekering is geen aansprakelijkheidsregeling

Veel leveranciers verwijzen tijdens onderhandelingen naar hun beroeps- of cyberverzekering. Dat geeft echter geen antwoord op de vraag welke aansprakelijkheid partijen contractueel willen aanvaarden. Een verzekering bepaalt immers niet waarvoor een leverancier aansprakelijk is. De verzekering bepaalt slechts welke schade de verzekeraar onder welke voorwaarden dekt. Bovendien kennen verzekeringen vrijwel altijd uitsluitingen, eigen risico's en maximale dekkingen. Een goede aansprakelijkheidsregeling kan daarom niet zonder meer worden afgestemd op de polisvoorwaarden. Vergeet daarbij niet dat je meer dan één klant hebt en dat de dekking van de polis vaak per verzekeringsjaar is begrensd.

Een redelijke regeling voor aansprakelijkheid in IT voorkomt juridische discussies

Een aansprakelijkheidsbepaling is uiteindelijk een samenspel tussen enerzijds de vraag hoe ver een leverancier zijn aansprakelijkheid kan beperken en anderzijds de vraag welke regeling een professionele klant bereid is te accepteren. Een aansprakelijkheidsregeling die iedere vorm van risico bij de klant neerlegt, zal tijdens onderhandelingen vaak op verzet stuiten. Omgekeerd zal een leverancier zich moeilijk kunnen verbinden aan een vrijwel onbeperkte aansprakelijkheid voor schade die hij niet volledig kan beheersen.

De praktijk laat zien dat de meest duurzame contracten worden gesloten wanneer beide partijen erkennen dat een redelijke risicoverdeling in ieders belang is. Niet alleen omdat daardoor sneller overeenstemming wordt bereikt, maar vooral omdat de regeling ook standhoudt op het moment dat zich daadwerkelijk een probleem voordoet.

Een goede regeling voor aansprakelijkheid in IT is maatwerk. De juiste balans hangt af van de aard van de dienstverlening, de risico's van het project en de belangen van beide partijen. Juist door daar vooraf zorgvuldig over na te denken, voorkom je langdurige onderhandelingen én onaangename verrassingen als er toch iets misgaat.

Ik denk graag mee over een aansprakelijkheidsregeling die juridisch stevig is én in de praktijk werkbaar blijft. Desgewenst verwerk ik die afspraken direct in een modelovereenkomst of algemene voorwaarden, zodat je ook bij toekomstige opdrachten kunt terugvallen op een solide contractbasis. Ook wanneer je onderhandelt over een IT-contract of aansprakelijkheidsbedingen van de wederpartij wilt laten beoordelen, sta ik je graag bij.