Er is geen ontkomen aan, de implementatie van de GDPR/AVG nadert met rasse schreden (25 mei 2018) en uit onderzoek blijkt dat bijna 40% van de onderzochte organisaties niet weet of ze aan de AVG moet voldoen, waarbij bijna 30% van de organisaties denkt dat ze niet eens ‘compliant’ hoeft te zijn. De AVG bevat veel verplichtingen voor verwerkingsverantwoordelijken en verwerkers, met belangrijke consequenties voor software ontwikkelaars. Het nieuwe kabinet Rutte III heeft daar in het regeerakkoord het een en ander aan toegevoegd.

AVG

Een belangrijk onderdeel van de AVG zijn de principes van ‘privacy by design’ en ‘privacy by default’ zoals opgenomen in artikel 25 met de titel “Gegevensbescherming door ontwerp en door standaardinstellingen”. Privacy by design komt erop neer dat al bij de ontwikkeling van produkten en diensten rekening moet worden gehouden met aspecten van privacy zodat er op het juiste moment – in de beginfase van de ontwikkeling –  aandacht is voor de verplichte technische en organisatorische privacy verhogende maatregelen. Hierbij is ook van belang dat rekening wordt gehouden met dataminimalisatie: alleen die gegevens die noodzakelijk zijn voor het doel van de verwerking dienen te worden verwerkt; geen andere gegevens. Onder andere de Autoriteit Persoonsgegevens noemt dit privacy enhancing technologies (PET). Zij noemt in dit verband als voorbeeld RFID-technologie (Radio Frequency Identification) waarmee met behulp van RFID-tags veel data kan worden gegenereerd en verwerkt.

Voorbeeld: een bedrijf dat postpakketjes bezorgt, houdt m.b.v. van RFID-tags en technologie de track en trace bij van de te bezorgen pakketjes met daarbij de naam en toenaam van de individuele bezorger en de NAW gegevens van de ontvanger, met als doel de voortgang bij te houden van de bezorging. Je kan je zo voorstellen dat uit dit systeem veel data kan worden gehaald, bijvoorbeeld dat bepaalde geadresseerden vaak kleren laten bezorgen waardoor het interessant is om de gegevens van die geadresseerden ter beschikking te stellen aan kledingleveranciers. Of dat kan worden geanalyseerd dat bepaalde bezorgers een slechte track-record hebben v.w.b. levertijden. Situaties waarbij je je dient af te vragen of dat onder de AVG wel zomaar mogelijk is. Bij de ontwikkeling van dit track & trace systeem dien je als ontwikkelaar/verantwoordelijke hiermee al rekening te houden en goed na te denken over doelomschrijving. Als in dit voorbeeld dus alleen het bijhouden van de voortgang van de pakketbezorging het doel is, dien je m.i. in het design ervoor te zorgen dat er geen andere gegevens in het systeem kunnen worden ingevoerd, zoals gegevens over welk soort product wordt bezorgd of de naam van de bezorger. Je kan hierbij ook denken aan (gedeeltelijke) anonimisering.

Privacy by default kan worden gezien als een nadere uitwerking van of als een onderdeel van Privacy by design. Hierbij dient een verantwoordelijke ervoor te zorgen dat standaardinstellingen altijd zo privacy-vriendelijk mogelijk zijn en dat persoonsgegevens nooit standaard zichtbaar zijn. Ik kan me zo voorstellen dat in het voorbeeld de naam van geadresseerde dan alleen zichtbaar is voor de bezorger: hij of zij dient immers ervoor te zorgen dat het pakketje bij de juiste persoon terecht komt op het juiste adres.  Voor andere werknemers van de pakketbezorger die gebruik dienen te maken van het RFID systeem zou dan de naam van geadresseerde geanonimiseerd kunnen worden, voor hen is alleen het adres relevant en niet de naam.

Hoe dan ook, als verantwoordelijke dien je bij het (laten) ontwikkelen van software je dus terdege bewust te zijn van eventuele privacy aspecten en die tijdig bij het ontwerpen en maken van de software mee te nemen. Het helpt hierbij niet dat de tekst van artikel 25 AVG nou niet echt uitblinkt in het geven van duidelijke instructies op dit vlak. Want wanneer weet je als verantwoordelijke nu wanneer je software ‘privacy-proof’ is in de zin van dit artikel? Als je kijkt naar het eerste voorontwerp van de Uitvoeringswet AVG (UAVG) en de toelichting daarop zoals die ter consultatie lag (zie: https://www.internetconsultatie.nl/uitvoeringswetavg/details ), wordt in dit verband (zie onder paragraaf 5.2.1) al gerept van een ‘zorgplicht van de verwerkingsverantwoordelijke’ die ‘in verschillende contexten geconcretiseerd zal moeten worden’. Hierbij worden certificeringsmechanismen genoemd als mogelijkheid om aan te tonen dat hieraan is voldaan. Er bestaan al diverse private initiatieven in dit verband (zie bijvoorbeeld https://www.european-privacy-seal.eu), maar vanuit de Autoriteit Persoonsgegevens zijn er hier vooralsnog geen concrete aanknopingspunten voor. Het aansluiten bij de bekende NEN en ISO normen (bijvoorbeeld NEN 7510 en ISO 27001/2 en 27018) is weliswaar mogelijk, maar ook die normen zijn nog weinig concreet op dit vlak.

Wel stuurt de Autoriteit Persoonsgegevens aan op een onderzoeksrecht/bevoegdheid om software zelfstandig te onderzoeken op dit aspect. De Autoriteit Persoonsgegevens heeft namelijk een advies uitgebracht over de UAVG waarin ze dit o.a. adviseert (https://autoriteitpersoonsgegevens.nl/nl/nieuws/ap-adviseert-over-uitvoeringswet-avg, zie onder punt 13b).  Los van de overige bezwaren die je hiertegen kan hebben, vraag ik me hier vooral af: onderzoeken …. tegen welke normen dan? In het kader van rechtszekerheid zou dit op zijn minst vooraf duidelijk dienen te zijn.

Een interessant  voorbeeld van hoe de Autoriteit Persoonsgegevens overigens omgaat met haar bevoegdheid  is het recente onderzoek dat zij deed naar Windows 10 (https://autoriteitpersoonsgegevens.nl/nl/nieuws/ap-microsoft-verwerkt-gegevens-windowsgebruikers-strijd-met-wet): in het ruim 160 pagina’s tellende rapport concludeert de Autoriteit Persoonsgegevens dat Microsoft haar gebruikers niet goed informeert over de wijze waarop zij gegevens verzamelt en voor welk doel, waarbij de gebruikers ook geen rechtsgeldige toestemming hebben gegeven voor de verwerking van hun gegevens. Het rapport gaat helaas niet in op privacy-by- design aspecten, maar geeft wel een inkijkje hoe de Autoriteit Persoonsgegevens haar handhavingsrol ziet: erg streng blijkbaar, zeker als je bedenkt dat de Franse collega’s van de Autoriteit Persoonsgegevens Microsoft in een soortgelijke kwestie juist heeft vrijgepleit (zie https://www.cnil.fr/en/windows-10-official-closure-formal-notice-procedure-served-microsoft-corporation). Als dit een voorbode is over hoe streng de Autoriteit Persoonsgegevens om zal gaan met het door haar beoogde zelfstandige recht om software te onderzoeken, wordt dit een harde kluif voor softwareontwikkelaars/verantwoordelijken.

Regeerakkoord

Nu de nieuwe regering Rutte III is aangetreden en het regeringsakkoord bekend is, is het interessant om te zien welke plannen de nieuwe regering heeft met software-ontwikkeling. De regering heeft ongeveer 47000 woorden gebruikt in het regeerakkoord, van dat aantal komt in de tekst het woord ‘software’ 6 keer voor. Dat is in totaal nog geen 0,013 procent; als dit percentage representatief is voor de ambities van het kabinet op dit punt, dan zou je je wellicht zorgen moeten maken. Maar dat valt te bezien: onder het hoofdstuk 1 ‘Investeren voor iedereen’, in paragraaf 1.1 Justitie en veiligheid, onder het kopje veiligheid, 5^de bulletpoint, is opgenomen:

 Er wordt een ambitieuze cybersecurity-agenda opgesteld met onder meer standaarden voor Internet-of- things-apparaten, het stimuleren van bedrijven om veiliger software te maken via software- aansprakelijkheid, het versterken van het Nationaal Cyber Security Centrum (CCSC) als aanspreekpunt van Computer emergency response teams (CERT) van alle sectoren, het stimuleren van cybersecurity- onderzoek en het verbeteren van voorlichtingscampagnes op het gebied van cyberhygiëne.

Met name het zinsdeel: ‘ … het stimuleren van bedrijven om veiliger software te maken via software- aansprakelijkheid …’ is interessant: hoe zou dit dan moeten en wat wordt hiermee bedoeld? Wanneer is software dan ‘veiliger’? Als je kijkt naar de hieronder genoemde aansprakelijkheidsregimes voor software, vraag ik me af hoe de regering dit dan daarin wil passen en wat zij dan beoogt met software – aansprakelijkheid:

• Toerekenbare tekortkoming (wanprestatie): softwareleveranciers beperken aansprakelijkheid in de contracten meestal tot de waarde van het contract waarbij indirecte- en gevolgschade is uitgesloten. Een beroep op schade omdat de software niet veilig zou zijn, dient dan te worden beoordeeld aan de hand van de afspraken in het contract, met name of er bepaalde toezeggingen of garanties daaromtrent zijn opgenomen die toerekenbaar geschonden zouden zijn. In het verlengde hiervan geldt dat op basis van het bekende Beeldbrigade arrest onder omstandigheden een beroep kan worden gedaan op de bepalingen van de kooptitel van het burgerlijk wetboek, waaronder een wettelijk beroep op conformiteit. Volgens die wettelijke regel mag een koper van software verwachten dat de verkoper hem of haar een product levert dat voldoende veilig is voor het normale gebruik van dat product. In dit verband is een aantal maanden geleden door de Cyber Security Raad (CSR) een handleiding gepubliceerd voor bedrijven op het gebied van cybersecurity (https://www.cybersecurityraad.nl/binaries/20170405_CSR_Handreiking2017_CompleetDEFweb_tcm56-253718.pdf . De CSR heeft daarin een algemeen overzicht opgenomen van de belangrijkste zorgplichten en de wijze waarop bedrijven – producenten, leveranciers en gebruikers van ICT –concreet invulling kunnen geven aan veiligheid. De CSR concludeert daarbij dat de wet voldoende aanknopingspunten biedt voor juridische actie als een leverancier software met gebrekkige security levert; een wetswijziging is daarom niet nodig.
• Productaansprakelijkheid op grond van artikel 6:185 e.v. BW. Dit artikel gaat ervan uit dat een product, gebrekkig dient te zijn om aansprakelijkheid aan te nemen. Dit artikel kent zijn beperkingen voor software: allereerst dient de (klassieke) vraag te worden beantwoord of software überhaupt als een product/roerende zaak dient te worden beschouwd; een roerende zaak is een voor menselijke beheersing vatbaar object en juristen verschillen al jaren van mening over de vraag of dit dan ook voor software geldt of niet. Aannemende dat software een product is in deze zin, zal moeten worden bezien in hoeverre de software dan gebrekkig is aan de hand van drie criteria: presentatie van het product, het redelijkerwijs te verwachten gebruik daarvan en het tijdstip waarop het in het verkeer werd gebracht. Mocht op basis daarvan gebrekkigheid worden aangenomen, dan geldt dat schade door dood of lichamelijk letsel of zaakschade geleden in de privésfeer met een franchise van 500 euro, wordt vergoed. Hierdoor is schade in de bedrijfssfeer uitgesloten, dus veel soelaas biedt dit uiteindelijk niet in B2B relaties.
• Aansprakelijkheid op grond van onrechtmatige daad. In dit geval zal moeten worden aangetoond dat schade is toe te rekenen aan de vermeende onveiligheid, waarbij duidelijk moet worden gemaakt welke normschending dan heeft plaatsgevonden. Ik denk dat hier dan eveneens kan worden aangesloten bij het voornoemde rapport van CSR.

Ik zie in ieder geval even niet zo snel hoe de regering uitgaande van deze regimes veiligheid van software verder kan stimuleren. Zou dat door de introductie van wetgeving moeten gebeuren waarbij veiligheidseisen aan software worden gesteld:

• die dan met terugwerkende kracht in huidige bestaande contractuele relaties met software leveranciers zullen moeten doorwerken? Zeker met grote mondiale spelers als Oracle, Microsoft, SAP, Salesforce, etc. lijkt me dit een zeer lastig traject dat veel weerstand zal oproepen.
• waarbij het begrip veiligheid zodanig wordt omschreven dat het voldoende rechtszekerheid biedt voor alle partijen? Dat lijkt me niet eenvoudig omdat wat nu als een veilige technologie wordt beschouwd, later niet meer veilig kan zijn door de voortschrijdende technologische ontwikkelingen.
• dat alleen in B2B verhoudingen geldt, of ook in consumentenverhoudingen?
• waarbij ook zorgverplichtingen worden opgelegd aan afnemers en een gezamenlijke verantwoordelijkheid wordt opgelegd om vooraf duidelijke afspraken hierover te maken?
• en zo kan je nog een dierentuin aan beren op de weg zien.

Mij lijkt het veel effectiever om- alle goede bedoelingen van de wetgever ten spijt – het aan de markt en toezichthouders over te laten om dit punt verder op te pakken. De bestaande wettelijke mogelijkheden bieden daarvoor genoeg mogelijkheden waarbij de handleiding van de CSR richting kan geven.

Software: privacy en security

Kortom, als software leverancier dien je bij de ontwikkeling en levering van software goed na te denken over privacy en security aspecten en daar – vooraf – duidelijke afspraken en normen over vast te leggen met de klant. Dit is extra van belang nu de spelregels van de wedstrijd ‘handhaving vs. voldoen’ nog niet zijn uitgekristalliseerd. De wetgever en Autoriteit Persoonsgegevens lopen zich in ieder geval al wel warm voor die wedstrijd en als software leverancier kan je daar dan maar beter aan meedoen; duidelijke afspraken maken en vastleggen is een goed begin daarvan.