image

Kan ik als ontwikkelaar de AVG-risico’s van mijn software bij de klant leggen?

woensdag 20 september 2023, 11:51 door Arnoud Engelfriet, 5 reacties

Heb jij een interessante vraag op het snijvlak van privacy, cybersecurity en recht? Stuur je vraag naar juridischevraag@security.nl. Elke week geeft ict-jurist Arnoud Engelfriet in deze rubriek antwoord.

Juridische vraag: Ik ben een eenmansbedrijf dat software maakt voor kassasystemen. Ik heb een klant die vasthoudt aan een legacy systeem van mij, waar persoonsgegevens in zitten. Ik kan echt niet meer 100% instaan dat dit veilig is gezien de leeftijd van het systeem, maar deze klant wil het persé aanhouden en alle risico’s dragen. Kan ik op een of andere manier alle AVG-risico’s bij de klant leggen, of kan dit niet en zit er niets anders op dan het systeem echt af te sluiten?

Antwoord: De eerste wedervraag die hierbij moet worden beantwoord, is of deze software wordt ingezet als on-premise software (dus op kassasystemen bij de klant) dan wel als SaaS-dienst (via terminals bij de klant).

Bij een on-site applicatie kun je de verantwoordelijkheid een heel eind verleggen. Dat kan alleen niet simpelweg met je algemene voorwaarden zoals veel ontwikkelaars denken. Je hebt als ontwikkelaar namelijk een zorgplicht, die meebrengt dat je niet willens en wetens een applicatie levert die evident in strijd met de AVG functioneert. Natuurlijk kan de klant van alles afstellen, maar als het systeem fundamenteel onveilig is dan is het moeilijk te rechtvaardigen dat je dit blijft leveren.

De enige manier waarop dit mogelijk nog kan, is met een expliciete verklaring waarin je uitlegt welke AVG-risico's er aan zitten, waarom jij die niet kan of wil herstellen en dat je klant bereid is alle gevolgen daarvan te dragen. Je laat de klant die dan tekenen. Als die ermee akkoord gaat natuurlijk: als hij zó expliciet in het gezicht krijgt dat er fundamentele problemen (met hoge boetes als ultieme consequentie) aan zitten, is de kans groot dat hij zich bedenkt en toch over wil stappen.

Bij SaaS ben jij als dienstverlener verwerker van die persoonsgegevens, en de AVG bepaalt apart dat ook jij aansprakelijk bent naar betrokkenen toe en dat jij apart beboet kan worden door de AP als het systeem niet adequaat is. Dat kun je niet verleggen met een contract. Dus dan is het ook vanuit je eigen perspectief belangrijk dat je die software of uitfaseert of alsnog AVG compliant maakt.

Het beste dat je bij SaaS kunt doen is afspreken dat de klant je vrijwaart van eventuele boetes en claims. Dat betekent dan nog steeds dat jij ze moet betalen, maar je mag je dan omdraaien en ze verhalen op je klant die zo nodig dit systeem moest gebruiken. Punt is natuurlijk wel dat als de klant in de tussentijd gestopt is of failliet verklaard, er niets te halen is. Bovendien zit je ook hier met je zorgplicht: als het systeem fundamenteel zo onveilig is, en jij gebruikt dit als verwerker, waarom zou je klant en niet jij er dan voor op moeten draaien.

Arnoud Engelfriet is Ict-jurist, gespecialiseerd in internetrecht waar hij zich al sinds 1993 mee bezighoudt. Hij werkt als partner bij juridisch adviesbureau ICTRecht. Zijn site Ius mentis is één van de meest uitgebreide sites van Nederland over internetrecht, techniek en intellectueel eigendom. Hij schreef twee boeken, De wet op internet en Security: Deskundig en praktisch juridisch advies.

Reacties (5)
20-09-2023, 12:39 door Anoniem
Los van de juridische kant van de zaak: stel dat jij goed bent ingedekt omdat die klant schriftelijk volledige aansprakelijkheid op zich neemt, en het gaat vervolgens dankzij die verouderde software zo mis bij die klant als het maar mis kan gaan.

Hoe voel jij je daarbij? Laat het je koud of raakt het je? Haal je je schouders op en ga jij door alsof er niets gebeurd is of gaat het aan jou knagen dat je iets hebt gedaan waar je het niet mee eens bent en waar je je toch nog verantwoordelijk voor voelt?

Als jouw antwoord op die vraag duidelijk maakt dat dit iets is waar jij echt niet achter staat dan moet je het ook echt niet doen.
20-09-2023, 13:17 door Anoniem
Door Anoniem: Los van de juridische kant van de zaak: stel dat jij goed bent ingedekt omdat die klant schriftelijk volledige aansprakelijkheid op zich neemt, en het gaat vervolgens dankzij die verouderde software zo mis bij die klant als het maar mis kan gaan.

Hoe voel jij je daarbij? Laat het je koud of raakt het je? Haal je je schouders op en ga jij door alsof er niets gebeurd is of gaat het aan jou knagen dat je iets hebt gedaan waar je het niet mee eens bent en waar je je toch nog verantwoordelijk voor voelt?

Als jouw antwoord op die vraag duidelijk maakt dat dit iets is waar jij echt niet achter staat dan moet je het ook echt niet doen.
Terechte vraag, maar waar de vraagsteller hier in vastloopt is de split dat hij zich verantwoordelijk voelt voor een oude situatie met oude software, maar - naar ik vermoed - de afnemer van het product niet bereid is om te investeren in de nieuwe software versie en mogelijk bijhorende aangepaste hardware eisen.

Waarom wil de klant niet over naar het nieuwere systeem? Zijn dat aangepaste licentie kosten die een stuk duurder zijn? is het een migratie traject om de data te converteren? is het een verplichting om ook andere hardware neer te zetten? Of werken er bepaalde zaken niet meer waar de klant wel gebruik van maakt en is er sprake van functioneel verlies?

Het gaat er uiteindelijk om een incentive te realiseren waarbij die kosten gereduceerd worden tot een acceptabel niveau. Daarin kan ook de onderhoudskosten van het oude systeem in meegenomen worden en wie daar vervolgens voor opdraait. Als eenmanszaak is het onderhouden van meerdere systemen iig op de lange termijn niet houdbaar, en er zal ook geen buffer aanwezig zijn om de migratie en implementatie kosten volledig te kunnen opvangen.

De vraag is dus vooral op welke wijze dit in de gebruiksovereenkomst van jouw pakket is vastgelegd. Dat kan geen blanco cheque zijn waarmee je de klant ongecontroleerd op kosten kan jagen, maar een klant heeft zelf naar ik aanneem een bepaalde verplichting om de spullen te onderhouden. Als voortschrijdend inzicht leert dat het gebruik van de software naar de huidige maatstaven en stand der techniek niet meer kan, dan zou ik toch willen stellen dat zachte heelmeesters stinkende wonden maken.

Ik zou idd zeggen: geef een duidelijke toelichting wat er (zonder technische details, je wil waarschijnlijk niet dat die details naar buiten komen als je de spullenboel nog moet draaien) mis is, dat het daarom echt niet verantwoord is om door te blijven gaan op de gebruikte software en/of dienst. Biedt een beschikbaar perspectief aan en geef eventueel aan waar en in welke mate je eventueel (financieel) tegemoet kan/wil komen aan de klant om hem te helpen naar die oplossing. Maar wel onder een realistische deadline: per x-x-xx is de huidige implementatie niet langer te ondersteunen en worden alle betrokken systemen in beheer van de dienstverlener uitgezet.

Legacy rommel moet gewoon een keer binnen redelijkheid en billijkheid de nek omgedraaid kunnen worden.
20-09-2023, 13:18 door Anoniem
Dus legacy software en opslag van persoonsgegevens.

Ongeacht of je al de AVG-risico's kunt afschuiven op de klant, als het fout gaat dan heb je hoe dan ook een rechtzaak aan je broek.


Als professioneel bedrijf moet je op een bepaald moment tegen je klant durven zeggen:

Die software is zwaar verouderd. Hij voldoent niet meer aan de actuele wetgeving en veilogheidseisen. En kan niet meer onderhouden worden. Ik kan hier de juridisch en fianancieel de verantwoordelijkheid niet voor dragen mocht er iets fout gaan.
Maar ik heb een alternatief voor je. Stap daar op over.
Hoe dan ookstop ik met ondersteuning te geven op de oude software per 1-1-??

Stapt de klant niet over, dan zeg je het contract op.

Mocht er dan later toch wat fout gaa, kun je naar de beeindiging van het contract wijzen en de corerspondentie daarvoor.


Dit klinkt hard en klantonvriendelijk, maar is uiteindelijk voor beide partijen beter.

Zachte heelmeesters maken stinkende wonden.
21-09-2023, 06:33 door Anoniem
Door Anoniem: Terechte vraag, maar waar de vraagsteller hier in vastloopt is de split dat hij zich verantwoordelijk voelt voor een oude situatie met oude software, maar - naar ik vermoed - de afnemer van het product niet bereid is om te
investeren in de nieuwe software versie en mogelijk bijhorende aangepaste hardware eisen.
Daar reageerde ik ook op. Ik heb niet de indruk dat de vraagsteller overslaat om aan de belangen van en mogelijkheden voor die klant te denken, dat is precies waarom die moeite met de situatie heeft. Zeker als je zoiets in je eentje doet is het heel makkelijk om afgeleid te raken van waar je zelf eigenlijk wel en niet achter kan staan. Mijn reactie was erop gericht om daar even bij stil te staan. Jij gaat daar overheen met niet stilstaan erbij maar meteen doordenderen met overwegingen die je juist veel beter kan maken als je wél eerst hebt stilgestaan bij waar je eigen grenzen eigenlijk liggen.
29-09-2023, 08:52 door Pieter Stoffelen
Je kunt bij een legacy systeem ook nog best zaken verbeteren. Ik noem maar wat, bijvoorbeeld een SQL job toevoegen om logging of oude gebruikers die je niet meer mag bewaren te verwijderen. Transparent Data Encryption op de database toepassen zodat die bij diefstal versleuteld is, OS upgrade naar een versie wel onderhouden kan worden, SSL certificaat upgrade naar bij de tijdse encryptie. Ik denk dat je zo nog een heel eind komt op AVG gebied.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.