Als IT-er heb je een zorgplicht en daar moet je wel wat voor doen

Ik roep het al een tijd maar zo’n vonnis is toch altijd wel weer leuk: ja, je hebt écht een zorgplicht en dat betekent ook doorvragen en vasthoudend doen als de klant er niet aan wil. Doe je dat niet, en gaat er wat mis, dan hang jij voor de kosten die het bedrijf heeft geleden. Je komt niet weg met “ik heb het voorgesteld maar ze vonden het te duur / ze wilden er niet aan”. Onverstandig handelen op verzoek van de klant maakt je schadeplichtig. En nee, je algemene voorwaarden gaan je niet redden.

Het gaat om een uitspraak uit 2018 die nu pas is gepubliceerd. Een IT-dienstverlener en automatiseerder had aan een administratiekantoor aangeboden om de IT-infrastructuur opnieuw in te richten. Er werd een nieuw netwerk aangelegd en allerlei onderhoud uitgevoerd. Wat me daarbij opvalt, is dat er geen uitgebreide afspraken gemaakt maar op basis van goed vertrouwen tegen een vast tarief (380 euro per maand, ja maand) werd gewerkt.

In 2017 werd het kantoor slachtoffer van ransomware. Zij heeft ervoor gekozen te betalen en zo haar bestanden terug te krijgen, kennelijk de enige manier want er was iets met de backups en daar kom ik zo op. Een cybersecuritybedrijf kwam tot de bevinding dat er een backoffice-account was met een zwak wachtwoord én dat poort 443 open stond zodat je vanaf internet een remote desktop kon starten. In juridische taal: slordigheden.

Ook signaleerde het securitybedrijf dat er geen maatregelen omtrent wachtwoorden waren genomen, dat er niet met VPNs werd gewerkt én er dus geen fatsoenlijke backupvoorziening was. Met name dat laatste: “[Deze aanval] had voorkomen kunnen worden met een op de juiste manier ingeregelde backup.”

Wat was nu het probleem daarmee? Nou ja, er was bij het offertetraject gesproken over een “totaalpakket” aan IT-dienstverlening. Het kantoor stelde nu dat beveiliging daar natuurlijk ook bij hoort, wat in 2017 best wel redelijk was als uitgangspunt. En aangezien die duidelijk was verzaakt, moest het IT-bedrijf de kosten van herstel (de bitcoins) en bereddering (de factuur van het securitybedrijf) komen vergoeden.

Maar het IT-bedrijf wierp daartegen op dat de klant steeds al zijn voorstellen op dat gebied had afgewezen. Zo vond men een firewall te duur, en waren alle backupoplossingen te ingewikkeld – inclusief de oplossing van een externe USB schijf die je dan in het weekend mee naar huis nam. Ook had het personeel kennelijk moeite met stevige wachtwoorden, zodat in arren moede dan maar simpele wachtwoorden werden toegestaan.

Ik zie alle IT-ers nu enigszins schamper lachen; herkenbaar die situatie. En de juristen? Sommigen zijn nog poort 443 aan het googelen maar de rest denkt nu “ja maar je zorgplicht”.

Want ja, je hebt een zorgplicht als IT-leverancier (art. 7:401 BW). Dat wil zeggen dat je moet handelen zoals een ‘goed’ vakgenoot zou doen. Dat is een open norm, en het hangt dus volledig af van de situatie wat dat precies inhoudt. Maar wat het niet inhoudt, is dat als de klant zegt “eh firewall is te duur en wachtwoorden graag alleen letters” dat je dan zegt “oké gaan we doen, wat jij wil”. Het is en blijft jouw verantwoordelijkheid dat er een fatsoenlijke oplossing komt. Kan dat niet, dan moet je de opdracht teruggeven.

Iets specifieker, als de klant je opdraagt het op een ongepaste of onveilige manier te doen, dan zegt art. 7:402 BW:

De opdrachtnemer die op redelijke grond niet bereid is de opdracht volgens de hem gegeven aanwijzingen uit te voeren, kan, zo de opdrachtgever hem niettemin aan die aanwijzingen houdt, de overeenkomst opzeggen wegens gewichtige redenen.

Natuurlijk, klanten kunnen onverstandig en koppig zijn (zowel alle juristen als alle IT-ers glimlachen nu van herkenbaarheid) maar aangezien jij de professional op dit gebied bent, moet jij die klant bij z’n nekvel pakken en zeggen, zo kan het niet wat u wil. We kunnen het zus doen of zo. Je zet dan bijvoorbeeld alle desktop-firewalls dicht of configureert de router zodat er niet op afstand gewerkt kan worden. Wil men dat toch, ja dan is dat meerwerk want dat moet wel veilig.

Zoals de rechter het formuleert:

Gelet op de afspraak dat hij een totaalpakket inclusief beveiliging zou leveren, in combinatie met zijn professionele deskundigheid, kon hij niet volstaan met een enkele waarschuwing en berusten in de keuzes van O’Cliance.

Dit wil natuurlijk niet zeggen dat je tot in lengte van dagen moet blijven ploeteren tegen de wens van de klant in, zonder extra kosten te mogen rekenen omdat je nu eenmaal een vast maandtarief had afgerekend. Je kúnt op zeker punt best zeggen, goed, dit is het en vanaf hier is het jouw risico. Maar dat kan pas als je uitgebreid hebt voorgelicht en gewaarschuwd, wat niet hetzelfde is als “dit lijkt me niet veilig maar oké”. En ook niet als “artikel 14.3 van mijn algemene voorwaarden zegt dat de gevolgen van klantkeuzes voor zijn rekening komen”, zoals sommige IT-ers nog wel lijken te denken.

Op één punt had de IT-er het wel goed gedaan en dat waren die zwakke wachtwoorden. Hij had eerst keurig ingewikkelde wachtwoorden ingesteld, maar de klant had daar moeilijk over gedaan. En pas na diverse rondes discussie én een uitdrukkelijke waarschuwing gaf hij zich gewonnen:

Met betrekking tot deze wachtwoorden staat bovendien vast dat [gedaagde] aanvankelijk complexe wachtwoorden had ingesteld, maar dat hij deze op uitdrukkelijk verzoek van [het administratiekantoor] heeft vereenvoudigd. Op de zitting heeft [betrokkene] hierover verklaard dat hij herhaaldelijk met [gedaagde] over de wachtwoorden heeft gesproken en dat hij zich ervan bewust was dat het gebruik van simpele wachtwoorden risico’s met zich bracht.

Daarom komt een derde van de schade voor eigen risico van de klant. En die schade? Ja, een slordige 15 duizend euro: gederfde omzet door bedrijfsstilstand, de kosten van het onderzoek én de drie bitcoins die nodig waren om de data terug te krijgen. Wellicht dat algemene voorwaarden deze vordering iets hadden kunnen dempen, maar schending van je zorgplicht is een vrij fundamenteel ding dus denk niet dat je wegkomt met enkel dat zinnetje “gederfde omzet komt niet voor vergoeding in aanmerking” of iets dergelijks.

De belangrijkste les voor mij: zorg dat je blijft communiceren met je klant en dat je daarin de risico’s ook écht duidelijk maakt. In taal die de klant snapt, met waarschuwingen die er niet om liegen en blijf aandringen op een bevestiging van de vorm “ik snap de risico’s en ik wil het tóch zo”. Dat doe je in de conversatie, niet verstopt in je voorwaarden en niet met een bulletpoint in je offerte. En die conversatie die log je en je komt erop terug als de situatie rijp lijkt voor verbetering. Dat is hoe een goed IT-er zorgt voor zijn klanten.

Arnoud

20 reacties

  1. En ook niet als “artikel 14.3 van mijn algemene voorwaarden zegt dat de gevolgen van klantkeuzes voor zijn rekening komen”, zoals sommige IT-ers nog wel lijken te denken.

    Hoe zou dit zitten als de klant schriftelijk aangeeft dat hij bepaalde dingen niet wil en dat hij die risico’s die daaruit voorkomen accepteert? Bijvoorbeeld als de IT’er zegt dat backups echt nodig zijn, klant zegt nee, IT’er zegt dat dit echt nodig is om allerlei risico’s af te dekken en dat als de klant het niet wil, dat hij zelf verantwoordelijk is voor die risico’s en de klant zegt vervolgens dat hij dat begrijpt maar het alsnog niet wil.

  2. Maar uiteindelijk was de point of entry het zwakke wachtwoord, precies het punt waarvoor dus wel goed gewaarschuwd was. Met alleen een openstaande poort kan men niet direct ransomware installeren. De verdere consequenties van de ransomware zijn dan toch het gevolg van het zwakke wachtwoord en dus voor de klant? De toewijzing van twee derde van de schade voor de IT-leverancier vind ik dan niet goed onderbouwd.

    1. Precies, daar zat ik ook al mee. Poort 443 is gewoon de HTTPS poort, het is niet alsof ze 3389 (RDP) direct naar het internet open hebben (en dan nog, genoeg Linux ITers die poort 22 (SSH) naar de wereld open zetten) – zonder verdere informatie zie ik geen problemen met hoe deze ITer gewerkt heeft. Of je nou VPN of Remote Desktop Services op poort 443 draait maakt niet zoveel uit als de inbrekers via een zwak wachtwoord binnen zijn gekomen.

      Het enige dat ik op deze ITer kan aanmerken is het ontbreken van de backup. Dat is dus blijkbaar 2/3e van de blaam, en een zwak wachtwoord is 1/3e.

      1. Het ontbreken van een (goede) backup is anders cruciaal. Bij een administratiekantoor is dat het verschil tussen 1 dag verlies aan werk of misschien wel een jaar. Maar dat er een zwak wachtwoord op RDP zit is fout, alleen wanneer er een VPN tunnel voor had gezeten, een stuk minder erg. Dan had de aanvaller ook deze VPN tunnel moeten compromitteren en was e.e.a. toch een stuk lastiger geweest. Wanneer een medewerker een drive-by download had opgepikt of een besmet document, dan had dit niets uitgemaakt, maar was de backup nog steeds de beste oplossing. En een goede backup moet echt offline zijn, want een backup op een NAS die in het netwerk hangt kan ook onbruikbaar worden gemaakt.

        1. Een VPN helpt alleen als je daar een ander wachtwoord voor hebt dan het wachtwoord op RDP. Aangezien de klant niet een veilig wachtwoord wilde gebruiken vraag ik me sterk af of dat op de VPN dan wel gebeurd was.

          Eens dat backup wel belangrijk is en het nalatig is die niet te hebben. Daarom ook mijn opmerking dat je dat zeker wel kunt aanmerken.

          (ik zie dat mijn 2/3 en 1/3 in ? veranderd zijn in mijn vorige comment. Arnoud, je blog laat z’n leeftijd zien – dat is een compliment voor de inhoud, maar niet voor de code..)

      2. (ik zie dat mijn 2/3 en 1/3 in ? veranderd zijn in mijn vorige comment, en ik kan het niet wijzigen. Arnoud, je blog laat z’n leeftijd zien – dat is een compliment voor de inhoud, maar niet voor de code..)

  3. Uit mijn mailbox, letterlijk naar een (ooit grote) klant van mij (zzp – zzp):

    Verder moet je nu echt werk maken van het versleutelen van de wachtwoorden in de database. Niet lullig bedoeld, maar het is niet verantwoord dat de wachtwoorden leesbaar staan opgeslagen in de database. Let op dat het je zwaar aangerekend zou kunnen worden als je ooit gehackt wordt of met een data-lek te maken krijgt. Begrijp me niet verkeerd, maar ik ben daar niet verantwoordelijk voor. Je zou dit punt zelf gaan (laten) oppakken nadat voorheen onze samenwerking tot een einde kwam… Wacht hier niet te lang mee!

    3 jaar geen contact meer mee gehad, maar heeft waarschijnlijk nog steeds niet de zaken op orde. Weigert de investering. Als ik deze blog lees, is misschien deze mail nog steeds niet voldoende afdekking tegen zijn keuzes. Maar ik kan echt niet gratis zijn problemen gaan oplossen.

    1. Er is een component in Windows Server (in ieder geval 2008(R2), weet niet of dit nog in latere versies aanwezig is) die RD Gateway heet (Remote Desktop Gateway). Hiermee kun je RDP over de https poort 443 laten lopen.

  4. Even vraagje, hangt dit nou expliciet af van het aanbieden van een “totaalpakket”? Als je wel beheer doet maar over de inhoud geen specifieke afspraken hebt gemaakt en nooit spreekt van een “totaalpakket”, kan je dan net zo aansprakelijk gesteld worden?

    1. Je kunt aansprakelijk gesteld worden als je (buiten overmacht) tekort bent geschoten in je zorgplicht. De vraag is dan dus altijd, hoe ver reikte doe. En daarvoor is van belang wat je had afgesproken. Als ik zeg “ik kom langs om die nieuwe servicepack van Windows 10 te installeren op jouw laptop” dan ben ik natuurlijk niet aansprakelijk voor zwakke wachtwoorden op je router. Maar als de afspraken onduidelijk zijn (“ik kom u totaal ontzorgen” of “ik doe divers IT werk op afroep en we kijken per geval hoe veel werk het is”) dan gaat de rechter interpreteren wat er wel of niet onder te rekenen is. Meestal door dan een vakgenoot als getuige-deskundige op te roepen: deze meneer biedt “beheer” aan, zou volgens u het maandelijks controleren van wachtwoorden en het bijwerken van security-updates daar ook onder vallen?

  5. En hoe is dat eigenlijk met de AVG compliance, zit daar een soortgelijke zorgplicht op? Er zal nog weinig jurisprudentie over bestaan maar volgens mij (leek) kan je die lijn in principe dan doortrekken.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.