MONOLITH LAW OFFICE+81-3-6262-3248Weekdagen 10:00-18:00 JST [English Only]

MONOLITH LAW MAGAZINE

IT

Schade door cyberaanvallen. Wat is de schadevergoedingsverantwoordelijkheid van de systeemleverancier? Uitleg aan de hand van voorbeelden uit contractdocumenten

IT

Schade door cyberaanvallen. Wat is de schadevergoedingsverantwoordelijkheid van de systeemleverancier? Uitleg aan de hand van voorbeelden uit contractdocumenten

De afgelopen jaren is het aantal cyberaanvallen op bedrijven gestaag toegenomen.

Volgens een onderzoek van de Japanse Netwerkbeveiligingsvereniging (JNSA), een specifieke non-profitorganisatie, was het percentage van ongeoorloofde toegang in gevallen van persoonlijke informatie lekken in 2013 slechts 4,7% van het totaal, maar dit is gestegen tot 20,3% in 2018 (2018 Onderzoeksrapport over informatiebeveiligingsincidenten[ja]).

In dit artikel leggen we uit wat de verantwoordelijkheden zijn van systeemleveranciers bij een cyberaanval, gebaseerd op eerdere rechtszaken. We zullen ook uitleggen welke rollen en verantwoordelijkheden leveranciers en gebruikers samen moeten vastleggen in een contract om zich voor te bereiden op cyberaanvallen, gebaseerd op een modelcontract.

Is een systeemleverancier aansprakelijk voor schadevergoeding bij een cyberaanval?

Is een systeemleverancier aansprakelijk voor schadevergoeding bij een cyberaanval?

Wanneer een bedrijf aan de gebruikerskant schade ondervindt van een cyberaanval, is de eerste partij die verantwoordelijk moet worden gehouden de dader van de cyberaanval. Echter, als er een mogelijkheid is dat de aanval vergemakkelijkt werd door nalatigheid in systeemontwikkeling en -beheer, kan er ook een claim voor schadevergoeding van de gebruikerskant naar de systeemleverancier worden erkend.

De basis voor een claim voor schadevergoeding tegen de systeemleverancier kan onder andere zijn:

  • Contractuele non-conformiteit
  • Schending van de zorgplicht

Echter, het kan ook voorkomen dat de schade toeneemt door nalatigheid aan de kant van de gebruiker. In dat geval kan ook de verantwoordelijkheid van de gebruiker worden erkend. In daadwerkelijke rechtszaken is er rekening gehouden met compensatie voor nalatigheid, en zijn er gevallen geweest waarin de schadevergoeding aan de systeemleverancier werd beperkt.

Gerelateerd artikel: Wat zijn de drie categorieën van cybercriminaliteit? Een advocaat legt de schadebeheersingsmaatregelen voor elk patroon uit[ja]

Aansprakelijkheid voor schadevergoeding van systeemleveranciers en voorbeelden van contractuele bepalingen

Er zijn drie representatieve voorbeelden van IT-systeemcontracten tussen systeemleveranciers en bedrijven die gebruikers zijn:

  1. Softwareontwikkelingscontract
  2. Systeemonderhouds- en bedrijfscontract
  3. Cloudservicegebruiksovereenkomst

De aansprakelijkheid voor schadevergoeding wordt bepaald door het oorspronkelijke contract, dus hieronder wordt dit uitgelegd voor elk type contract.

Software Ontwikkelingscontract

Een software ontwikkelingscontract is een overeenkomst die wordt gesloten wanneer een bedrijf aan de gebruikerskant een softwareleverancier opdracht geeft om zijn eigen systeem te ontwikkelen.

Als het bedrijf aan de gebruikerskant een cyberaanval ondergaat en de kwetsbaarheid van de software de oorzaak is van de uitbreiding van de schade, kan de verantwoordelijkheid van de gebruiker naar de leverancier worden nagestreefd.

De verantwoordelijkheid die de systeemleverancier draagt, varieert afhankelijk van het type software ontwikkelingscontract en kan worden onderverdeeld in de volgende twee categorieën:

  • Aannemingsovereenkomst: Verantwoordelijkheid voor contractuele non-conformiteit
  • Quasi-mandaatcontract: Schending van de zorgplicht

Aannemingsovereenkomst

Een aannemingsovereenkomst is een contract waarbij de voltooiing van het systeem wordt beloofd en er een vergoeding wordt betaald voor het eindproduct.

Als het geleverde eindproduct “niet voldoet aan het doel van het contract”, ontstaat er een bepaalde periode na de levering een verantwoordelijkheid voor contractuele non-conformiteit (Artikel 559, 562 van het Japanse Burgerlijk Wetboek) voor de aannemer.

Met andere woorden, er is een risico dat de gebruiker schadevergoeding eist op grond van contractuele non-conformiteit als het eindproduct gemakkelijk systeemstoringen kan veroorzaken door een cyberaanval.

Of deze claim wordt erkend, hangt af van het beveiligingsniveau van de software dat vooraf tussen de partijen is afgesproken.

【Voorbeeld van contractuele non-conformiteit】

Artikel X Na voltooiing van de inspectie volgens het vorige artikel, als er een discrepantie (inclusief bugs, hierna “contractuele non-conformiteit” genoemd in dit artikel) wordt ontdekt in de geleverde goederen, kan de opdrachtgever de opdrachtnemer verzoeken om de prestatie van de correctie van de contractuele non-conformiteit (hierna “aanvulling” genoemd in dit artikel). De opdrachtnemer zal deze aanvulling uitvoeren. Echter, tenzij het een onevenredige last oplegt aan de opdrachtgever, kan de opdrachtnemer de aanvulling uitvoeren op een andere manier dan de opdrachtgever heeft gevraagd.

2. Niettegenstaande het voorgaande, als het mogelijk is om het doel van het individuele contract te bereiken ondanks de contractuele non-conformiteit en als de aanvulling een buitensporige kost met zich meebrengt, zal de opdrachtnemer niet verplicht zijn om de aanvulling uit te voeren zoals bepaald in het vorige lid.

3. Als de opdrachtgever schade lijdt als gevolg van de contractuele non-conformiteit (beperkt tot die veroorzaakt door redenen die aan de opdrachtnemer kunnen worden toegeschreven), kan de opdrachtgever schadevergoeding eisen van de opdrachtnemer.

Citaat: Informatiesysteem Model Transactie Contract (Tweede Editie)[ja]

Quasi-mandaatcontract

Een quasi-mandaatcontract is niet onderworpen aan de verantwoordelijkheid voor contractuele non-conformiteit omdat het geen verplichting heeft om het eindproduct te voltooien. In plaats daarvan draagt het de “verplichting om de zaken van het mandaat te behandelen met de zorg van een goede manager” (zorgplicht).

Als een systeemstoring optreedt als gevolg van een cyberaanval, kan het feit dat een dergelijk systeem is ontwikkeld, zelfs als het beveiligingsniveau niet is vastgesteld op het moment van het contract, worden beschouwd als een “schending van de zorgplicht” (Artikel 656, 644 van het Japanse Burgerlijk Wetboek), en er is een mogelijkheid dat er een verzoek om schadevergoeding wordt gedaan.

【Voorbeeld van zorgplicht】

Artikel X De opdrachtnemer zal, na het sluiten van het individuele contract zoals bepaald in Artikel X, diensten verlenen om de opdrachtgever te ondersteunen bij het opstellen van een vereistendefinitiedocument op basis van het informatiesysteemconcept, systeemplanningsdocumenten, enz. die door de opdrachtgever zijn opgesteld als onderdeel van deze werkzaamheden (hierna “vereistendefinitie ondersteunende werkzaamheden” genoemd).

2. De opdrachtnemer zal, op basis van zijn gespecialiseerde kennis en ervaring op het gebied van informatieverwerkingstechnologie, onderzoek, analyse, organisatie, voorstellen en advies geven, enz., om ervoor te zorgen dat het werk van de opdrachtgever soepel en adequaat wordt uitgevoerd met de zorg van een goede manager.

Citaat: Informatiesysteem Model Transactie Contract (Tweede Editie)[ja]

Systeem Onderhoud & Beheer Contract

Een Systeem Onderhoud & Beheer Contract is een overeenkomst waarbij een bedrijf de taken met betrekking tot het onderhoud en beheer van bestaande software uitbesteedt aan een softwareleverancier. Het is gebruikelijk om bij het sluiten van een onderhouds- en beheercontract het vereiste beveiligingsniveau op te nemen in de contractdocumenten, zoals de specificaties van de werkzaamheden.

Als er schade ontstaat door een cyberaanval en het beveiligingsniveau van het systeem lager is dan het niveau dat overeengekomen was bij het sluiten van het contract, kan de verantwoordelijkheid voor contractbreuk worden nagestreefd op basis van de clausule van contractuele niet-nakoming.

Echter, als het beveiligingsniveau niet vooraf is vastgesteld, kan het onderhouden en beheren van een systeem dat kwetsbaar is voor cyberaanvallen worden beschouwd als een schending van de zorgplicht, wat kan leiden tot het nastreven van verantwoordelijkheid.

Cloud Service Gebruiksovereenkomst

Een Cloud Service Gebruiksovereenkomst is een contract dat wordt afgesloten wanneer men gebruik maakt van de diensten die een leverancier aanbiedt op de cloud. Omdat het waarschijnlijk is dat de leverancier dezelfde dienst aan veel gebruikers aanbiedt, zal men vaak een contract aangaan volgens de gebruiksvoorwaarden die door de leverancier zijn vastgesteld.

Over het algemeen wordt in dit contract vooraf bepaald wie verantwoordelijk is in het geval dat de dienst niet kan worden geleverd als gevolg van een cyberaanval.

In een Cloud Service Gebruiksovereenkomst worden doorgaans de volgende zaken vastgelegd bij het aangaan van het contract:

  • SLA (Service Level Agreement): garanties en operationele regels met betrekking tot kwaliteit
  • Aansprakelijkheidsbeperkingsclausule: de reikwijdte van de aansprakelijkheid van de leverancier in geval van schade

Een SLA is een document waarin de eisen van de gebruiker en de operationele regels van de aanbieder worden vastgelegd. Als de dienst die in de SLA is vastgelegd niet kan worden geleverd, kan men een schadevergoeding eisen wegens gedeeltelijke wanprestatie. Daarnaast kan er in het contract een ‘aansprakelijkheidsbeperkingsclausule’ zijn opgenomen, waarin de voorwaarden voor een vordering wegens wanprestatie door de leverancier vooraf worden beperkt en het bedrag van de schadevergoeding, zelfs als de aansprakelijkheid wordt erkend, wordt beperkt.

Echter, aangezien de aansprakelijkheidsbeperkingsclausule vaak gunstig is voor de leverancier, kan deze in geval van een geschil worden beperkt door de Japanse rechtspraak.

【Voorbeeld van een aansprakelijkheidsbeperkingsclausule】

Artikel X: Partij A en Partij B kunnen, indien zij schade lijden als gevolg van een oorzaak die aan de andere partij kan worden toegeschreven in verband met de uitvoering van deze overeenkomst en de individuele overeenkomst, schadevergoeding eisen van de andere partij, maar alleen voor (XXX schade). Echter, deze eis kan niet worden gedaan na het verstrijken van X maanden vanaf de datum van voltooiing van de inspectie van de geleverde goederen of de bevestiging van de voltooiing van de werkzaamheden onder de betreffende individuele overeenkomst.

2. Het totale cumulatieve bedrag van de schadevergoeding in verband met de uitvoering van deze overeenkomst en de individuele overeenkomst, ongeacht de oorzaak van de vordering, inclusief wanprestatie (inclusief contractuele non-conformiteit), ongerechtvaardigde verrijking, onrechtmatige daad of andere oorzaken, is beperkt tot het bedrag van XXX zoals bepaald in de individuele overeenkomst die de oorzaak van de aansprakelijkheid is geworden.

3. Het voorgaande artikel is niet van toepassing in geval van opzet of grove nalatigheid van de schadevergoedingsplichtige.

Citaat: Informatiesysteem Model Transactie Contract (Tweede Editie)[ja]

Criteria voor het bepalen van de schadevergoedingsverantwoordelijkheid van systeemleveranciers

Criteria voor het bepalen van de schadevergoedingsverantwoordelijkheid van systeemleveranciers

Wanneer een gebruikersbedrijf schade lijdt door een cyberaanval, in welke specifieke gevallen kan dan de verantwoordelijkheid van de systeemontwikkelaar in vraag worden gesteld?

Hieronder leggen we uit op basis van rechtszaken waarin de verantwoordelijkheid van de systeemleverancier daadwerkelijk in vraag werd gesteld.

Hebben ze maatregelen genomen volgens de technologische normen van de tijd van ontwikkeling?

In daadwerkelijke rechtszaken waarin de verantwoordelijkheid wordt betwist, wordt er veel belang gehecht aan of de systeemleverancier beveiligingsmaatregelen heeft genomen volgens de normen die op het moment van ontwikkeling werden voorgeschreven door overheidsinstanties en brancheorganisaties.

Er zijn rechtszaken waarin de systeemleverancier werd bevolen schadevergoeding te betalen voor schade veroorzaakt door een cyberaanval, zoals hieronder.

【Rechtszaak】Tokyo District Court, 23 januari 2014 (Heisei 26)
Gebruiker: X-bedrijf, een detailhandelaar in interieurproducten die ook aan telemarketing doet
Leverancier: Y-bedrijf, dat de opdracht had gekregen voor het ontwerpen en onderhouden van een webbestelsysteem

Een incident waarbij de creditcardinformatie van 7.000 klanten werd gelekt door een cyberaanval

■Uitspraak
De systeemleverancier werd bevolen om ongeveer 20 miljoen yen aan schadevergoeding te betalen
Een bedrag dat de ontwikkelingskosten met ongeveer 2 miljoen yen overtrof, werd erkend
X-bedrijf werd ook schuldig bevonden, met 30% schuldvergelijking

■Reden
・De systeemleverancier heeft nagelaten de beveiligingsmaatregelen te implementeren volgens de technologische normen van die tijd.
・Ondanks het feit dat het gebruikersbedrijf uitleg had gekregen over de risico’s van de systeemleverancier, maar toch naliet maatregelen te nemen, werd er 30% schuldvergelijking toegepast.

In 2014 was de “SQL-injectieaanval” de belangrijkste methode van cyberaanvallen, en het Ministerie van Economie, Handel en Industrie had een document getiteld “Oproep tot grondige veiligheidsmaatregelen voor persoonlijke gegevens op basis van de Wet Bescherming Persoonsgegevens[ja]” gepubliceerd om te wijzen op cyber-risico’s en op te roepen tot systeemversterking.

De uitspraak erkende de verantwoordelijkheid van de systeemleverancier die geen maatregelen had genomen en beval schadevergoeding, maar erkende ook dat het gebruikersbedrijf schuldig was en stond 30% schuldvergelijking toe.

Is er een fout aan de kant van het gebruikersbedrijf?

Bedrijven die systeemontwikkeling bestellen hebben ook verplichtingen, en als ze tekortschieten, kunnen ze volledig verantwoordelijk worden gehouden.

Hieronder volgt een voorbeeld van een rechtszaak waarin de volledige verantwoordelijkheid van het gebruikersbedrijf werd erkend en schadevergoeding werd bevolen, hoewel dit geen voorbeeld is van een cyberaanval.

【Rechtszaak】Asahikawa District Court, 31 augustus 2017 (Heisei 29)

Gebruiker: Universitair ziekenhuis
Leverancier: Systeembedrijf dat de opdracht had gekregen om een elektronisch medisch dossier systeem te ontwikkelen voor het universitair ziekenhuis

Kort na het begin van het project waren er talloze aanvullende verzoeken van de artsen ter plaatse.
De verzoeken stopten niet en de ontwikkeling liep vertraging op, en het universitair ziekenhuis gaf een kennisgeving van contractbeëindiging vanwege de vertraging.

■Uitspraak (beroep)
Bevel tot betaling van ongeveer 1,4 miljard yen aan het universitair ziekenhuis
De eerste aanleg uitspraak die beide partijen beval om schadevergoeding te betalen werd vernietigd

■Reden
・Het probleem was dat het ziekenhuis geen aandacht schonk aan de waarschuwing van de leverancier dat als ze zouden voldoen aan de aanvullende verzoeken, ze de deadline niet zouden halen.

Deze rechtszaak betrof een geschil waarbij zowel het gebruikersbedrijf als de leverancier elkaar aanklaagden voor schadevergoeding nadat het gebruikersbedrijf een kennisgeving van contractbeëindiging had gegeven vanwege de vertraging in de systeemontwikkeling.

In de uitspraak werd geoordeeld dat de oorzaak van de ontwikkelingsvertraging was dat het gebruikersbedrijf geen aandacht schonk aan de waarschuwingen van de systeemleverancier, en de volledige verantwoordelijkheid werd bij het gebruikersbedrijf gelegd, en de vordering van het gebruikersbedrijf werd afgewezen. Aan de kant van de leverancier is er een “projectmanagementverplichting” om het project op schema te houden. Aan de andere kant heeft het gebruikersbedrijf ook een “verplichting tot medewerking”, en als het deze verplichting verzaakt, kan het volledig verantwoordelijk worden gehouden, en in daadwerkelijke rechtszaken wordt de schadevergoedingsverantwoordelijkheid bepaald op basis van dit percentage.

Drie punten voor veilige systeemontwikkeling

Drie punten voor veilige systeemontwikkeling

Om je voor te bereiden op cyber risico’s, is het belangrijk dat zowel de gebruikerskant als de leverancierskant samenwerken aan preventieve maatregelen.

In het volgende zullen we de maatregelen bespreken die leveranciers en gebruikers kunnen nemen vanuit hun respectievelijke standpunten.

Begrijp de cyber risico’s die door overheidsinstanties worden aangegeven

System vendors moeten de richtlijnen controleren die zijn uitgegeven door gespecialiseerde organisaties zoals het Ministerie van Economie, Handel en Industrie en de Onafhankelijke Administratieve Instelling Informatieverwerkingsbevordering Agentschap (IPA), en moeten de huidige cyber risico’s en hun preventiemethoden begrijpen voordat ze beginnen met ontwikkeling en operatie.

Natuurlijk moeten niet alleen de leveranciers, maar ook de bedrijven aan de gebruikerskant de inhoud van de richtlijnen tot op zekere hoogte begrijpen en ontwikkeling en operatie volgens de richtlijnen aanvragen, en een clausule over het beveiligingsniveau in het contract opnemen.

Referentie: Ministerie van Economie, Handel en Industrie | Cybersecurity Management Guidelines Ver 2.0[ja]

Referentie: Informatieverwerkingsbevordering Agentschap | Hoe een veilige website te maken[ja]

In het bijzonder, in gebieden zoals de financiële sector, kunnen wetten en richtlijnen geavanceerde beveiliging vereisen. We leggen de beveiligingsmaatregelen voor crypto-assets in detail uit hieronder.

Gerelateerd artikel: Wat zijn beveiligingsmaatregelen voor crypto-assets (virtuele valuta)? Uitleg met drie gevallen van lekkage[ja]

Beide partijen begrijpen het belang van beveiliging

In de “Cybersecurity Management Guidelines Ver 2.0” van het Ministerie van Economie, Handel en Industrie staat duidelijk dat “cybersecurity maatregelen een managementkwestie zijn”.

In plaats van de beveiliging volledig over te laten aan de leverancierskant omdat je de beveiliging niet begrijpt, moeten bedrijven het risicobeheer als onderdeel van het management beschouwen en verantwoordelijkheid nemen voor het nemen van maatregelen.

Beide partijen werken samen om cyberaanvallen aan te pakken

Wanneer je een cyberaanval ondergaat, moeten de opdrachtgever en de leverancier samenwerken om de schade tot een minimum te beperken, in plaats van de verantwoordelijkheid op elkaar af te schuiven.

Echter, in systeemontwikkeling, is de positie van de opdrachtgever vaak sterker, en er is een neiging om de systeemontwikkeling te bevorderen met de focus op kosten en levertijd. Het kan zijn dat de leverancier, ondanks dat hij niet voldoende geld of tijd krijgt, zijn voorstel voor beveiliging niet geaccepteerd krijgt.

Echter, de richtlijnen geven aan dat bedrijven aan de gebruikerskant de implementatie van beveiligingsmaatregelen niet als “kosten” moeten zien, maar als een essentiële investering voor toekomstige bedrijfsactiviteiten en groei.

In systeemontwikkeling is het belangrijk dat leveranciers en gebruikers op gelijke voet samenwerken om cyberaanvallen aan te pakken.

Samenvatting: Raadpleeg een advocaat bij het opstellen van een systeemontwikkelingsovereenkomst

Als er schade optreedt door een cyberaanval, kan de leverancier die betrokken was bij de systeemontwikkeling verantwoordelijk worden gehouden door het gebruikersbedrijf, op grond van het feit dat zij nalatig zijn geweest in het nemen van cyber-risicomaatregelen.

Echter, ook het gebruikersbedrijf dat zijn plicht tot samenwerking met de leverancier heeft verzaakt, draagt verantwoordelijkheid.

Om de schade van een cyberaanval tot een minimum te beperken, is het noodzakelijk om in de overeenkomst het systeemniveau en de respectievelijke verantwoordelijkheidsgebieden vast te leggen.

Voor het opstellen van contracten voor systeemontwikkeling en dergelijke, raadpleeg een advocaat met geavanceerde expertise die de inhoud van de richtlijnen en de huidige cyber-risico’s begrijpt.

Informatie over de maatregelen van ons kantoor

Monolith Law Office is een advocatenkantoor met hoge expertise in IT, met name internet en recht. Bij het aangaan van een systeemontwikkelingsovereenkomst is het noodzakelijk om een contract op te stellen. Ons kantoor maakt en beoordeelt contracten voor verschillende zaken, variërend van bedrijven genoteerd aan de Tokyo Stock Exchange tot startende ondernemingen. Als u problemen heeft met contracten, raadpleeg dan het onderstaande artikel.

Behandelingsgebieden van Monolith Law Office: Juridische zaken gerelateerd aan systeemontwikkeling[ja]

Managing Attorney: Toki Kawase

The Editor in Chief: Managing Attorney: Toki Kawase

An expert in IT-related legal affairs in Japan who established MONOLITH LAW OFFICE and serves as its managing attorney. Formerly an IT engineer, he has been involved in the management of IT companies. Served as legal counsel to more than 100 companies, ranging from top-tier organizations to seed-stage Startups.

Category: IT

Tag:

Terug naar boven