Mijn klanten eisen dat mijn ontwikkeltraject AVG proof software geeft, kan dat wel?

Een lezer vroeg me:

Als softwareontwikkelaar krijg ik steeds vaker vragen of mijn software wel AVG proof is. Ik begrijp die vraag en wil mensen ook best tegemoet komen, maar het voelt wel als een hellend vlak omdat ik dan ineens aansprakelijkheden op me neem. Stel ik bouw een exportfunctie van persoonsgegevens niet in, moet ik dan de boete betalen als mijn klant daarop aangesproken wordt?

Heel formeel sprekend heeft een softwareontwikkelbedrijf géén plicht om te zorgen dat hun software aan de AVG voldoet. De AVG stelt regels voor de verwerking van persoonsgegevens, en dat gaat pas spelen bij het in productie nemen van die software. Er is dus niets mis met software waarbij persoonsgegevens niet kunnen worden geëxporteerd, het enige is dat een afnemer die niet in kan zetten in situaties waarin de AVG op hem van toepassing is.

Praktisch gezien ontkom je er niet aan om rekening te houden met de AVG, precies om die reden. Een softwarebedrijf met Nederlandse klanten kan het niet maken om zo’n exportfunctie weg te laten, want zijn klanten voldoen dan gewoon niet aan de wet en hebben dus een groot probleem als ze deze software in gebruik zouden nemen.

De discussie zal dus meer gevoerd worden op hoe ver je moet gaan als developer, en ook waar de kosten komen te liggen. Want dat er een exportfunctie moet zijn is één ding, welke gegevens er wel en niet onder vallen is een heel ander. Daar zijn ook de juristen het nog niet helemaal over eens, bijvoorbeeld. En er zijn nog veel meer dingen: hoe vraag je precies toestemming en hoe makkelijk moet deze in te trekken zijn?

Ik denk dat je er op dit moment dan ook niet aan ontkomt om hier in detail over te spreken met je klant. Dit kan mijn software, dit wil jij erbij, ik weet van de AVG en wat zie jij? (/juf Ank). En dat dan vastleggen in functionele specificaties of test cases, en in het contract opnemen dat jouw verantwoordelijkheid is dat het zal werken zoals vastgelegd.

In de toekomst zie ik meer mogelijkheden. De AVG kent de optie om technologieën voor gegevensbescherming of -verwerking te certificeren. Je zou dan als developer zo’n certificaat kunnen halen, en daarmee je klanten gerust stellen dat ze jou prima kunnen kopen. Eventuele aansprakelijkheid zou dan zeer mee moeten vallen (je bent immers gecertificeerd) en zou wellicht ook nog te verhalen zijn op de certificaatverstrekker. Maar dit zal nog wel een jaar of vijf duren, minstens.

Arnoud

17 reacties

  1. Er komt dus een certificaat voor of software aan de avg voldoet. Zijn er ook certificaten of software aan de overige wetgeving voldoet? Want hier zie ik anders nog ruimte voor verbetering.

    Hopelijk wordt software met certificaat te verzekeren voor als er boetes volgen.

  2. Om data te kunnen exporteren is toch geen ingebouwde export-functionaliteit nodig? Dat is simpelweg een kostenafweging van de klant en de ontwikkelaar over hoe vaak dit voor zal gaan komen. Je kunt op zich prima wat databases bij elkaar rapen en de gegevens van een persoon – in overleg met de klant – exporteren. Dat kun je dan op een gegeven moment natuurlijk, met wat finetuning omzetten naar een standaard functionaliteit.

    Als deze exportfunctionaliteit verplicht zou zijn, dan zou ook een ‘recht op vergeten’-knop verplicht moeten zijn. En het lijkt me dat je daar per geval toch best zorgvuldig naar moet kijken.

    1. Probleem hierbij is natuurlijk dat de klant dan hoge kosten op kan lopen, doordat deze zelf moet gaan spitten. Als die dan een zaak ervan kan maken dat dat de schuld van de software-ontwikkelaar zit, ben je weer aangekomen bij de daadwerkelijke ‘export’-functie en niet enkel ‘database-graven’.

    2. Daarnaast moet je er ook rekening mee houden dat het toevoegen van een exportfunctie extra risico’s met zich meebrengt qua datalekken die tegenwoordig tot fikse boetes kunnen leiden. Dus de verwachting dat software standaard wel een exportfunctie zal bevatten, die tevens hack-proof is, tegen dezelfde prijs als een paar jaar geleden, is niet helemaal realistisch.

        1. Ik vermoed dat Matthijs bedoeld dat er daarmee gegevens buiten je applicatie komen die óók beveiligd moeten zijn.

          Dus als een ijverige medewerker de export knop gebruikt om gegevens even naar een Google Docs bestand te kopiëren dan heb je een probleem. Ondanks dat die medewerker bevoegd is om die knop te gebruiken, bijv bij een aanvraag van een klant.

        2. Dat is inderdaad dan een implementatiefout (naast de opmerking van NP, die zeker ook waar is). Het toevoegen van features verhoogt de complexiteit en daarmee de kans op (implementatie-)fouten. Een exportfunctie is een soort gecontroleerde datalekfuntie, iets wat je dus zeer zorgvuldig moet aanpakken.

          Afhankelijk van de software en welke data op welke manier wordt verwerkt kan dat een geavanceerd probleem zijn. Terwijl de verwachting nu al bestaat (blijkbaar) dat het geen geavanceerd probleem is (want standaardfunctionaliteit, want het is de wet, dus easy peasy). Ik ben een beetje cynisch misschien, want ik wordt geregeld geconfronteerd met de kloof tussen hoe eenvoudig dingen ogen en de complexiteit van de daadwerkelijke implementatie.

  3. Ik vind het geen gekke eis. Software die je niet in staat stelt om aan de AVG te voldoen kan je feitelijk helemaal niet meer gebruiken.

    Onze klanten eisen hetzelfde van onze. In ons geval gaat het ook nog eens om SaaS, dus niet alleen onze software moet voldoen, maar wij moeten voldoen aan de AVG.

    Dat heeft een aantal nogal ingrijpende wijzigingen tot gevolg gehad. Wij zijn lang geleden al over gegaan tot het encrypten van de data at rest voor onze klanten. Als beheerders kunnen we natuurlijk wel altijd bij die encryptie sleutel, onze software rekent immers op de server met die data.

    Wij konden echter wel bij de database backup en individuele geëncrypte dossiers terugzetten voor onze klanten als ze die per ongeluk gewist hadden. Dat betekent echter dat de collegas die toegang tot de sleutels hadden met aangepaste software en deze backup database bij de data van klanten zouden kunnen. Enige drempel was nog dat we bewust daar geen functionaliteit voor hebben ingebouwd en het dus omslachtig is. Net zo omslachtig als de software ongemerkt door de klant aanpassen en alles unencrypted dumpen. Beide lijken mij eerder fraude of contractbreuk dan AVG issues, maar toch…

    Nu maken we dus geen database backups meer, de virtuele machine wordt door onze hosting partij volledig gebackupped inclusief de database. Deze partij heeft geen toegang tot de virtuelemachine, noch de encryptie sleutels en wij hebben geen toegang tot de backups meer. Wij kunnen de hoster vragen om een backup terug te zetten en we kunnen periodiek de backup testen door een backup VM op te laten starten en mbv eigen dossiers die wij in ons live systeem hebben aangemaakt.

    Individuele dossiers die men per ongeluk heeft gewist zijn nu dus echt weg. Wij gaan niet de data van al onze klanten terugrollen vanwege een enkel dossier, dat is in de aangepaste voorwaarden ook duidelijk afgestemd met de klanten. In verband met de verwijderingsverzoeken is de bewaartermijn van backups gereduceerd van een jaar naar een maand, als een klant gegevens verwijderd zijn ze nu dus binnen een, naar onze mening redelijke, korte termijn ook weg uit de backups.

    Bijkomend voordeel voor ons is dat wij geen verwijderingsverzoeken kunnen uitvoeren, de enige partij die dit kan is onze klant, degene die de data in het systeem heeft gezet.

    Al met al heeft de AVG dus vooral gemak voor onze klanten gekost, men moet voorzichtiger zijn met het verwijderen van dossiers omdat weg nu ook echt onmiddelijk weg is. Voor ons scheelt het heel veel extra werk nav de AVG wat geen enkel extra omzet zou opleveren. Maar of de privacy er nu beter op is geworden? In onze contracten stond al jaren dat wij de gegevens niet delen en er zelf ook niets mee doen. Ik zie hier dus alleen een grote verliezer (onze klant) een kleine verliezer (wij) en een partij waarvoor er werkelijk niets is veranderd (degene waarvan onze klanten persoonsgegevens verwerken)

    Was dat dan echt allemaal nodig op deze manier? Naar mijn mening niet en is de overheid weer eens doorgeslagen in de regeldrift.

    1. Het enigste wat ik me af vraag is wat voor database techniek je gebruikt dat het altijd goed gaat (je vertrouwd er immers op) om van een draaiende omgeving een backup te maken. Hier heb ik helaas dermate veel problemen meer ondervonden dat wij juist altijd voor dumps van de database gaan. Deze maken wij dan ook standaard van alles wat we beheren en waar backups worden afgenomen. Dat we dan in theorie bij de data kunnen nemen we voor lief (immers dataverlies is ook een probleem onder de AVG). Ik neem aan dat jullie ook maatregelen hebben genomen dat jullie medewerkers niet meer bij de draaiende databases kunnen, anders kunnen ze daar zelf data uithalen en met de sleutel/kennis die jullie hebben decrypten.

      1. Ik wist het antwoord op jouw vraag niet.

        Navraag leert dat er nog steeds een database dump wordt gemaakt, maar op een plek waar wij standaard niet bij kunnen en deze wordt dagelijks meegenomen in de backup van de machine. Credentials om bij deze dump te komen liggen achter slot en grendel (letterlijk!).

        Je kan nooit 100% afdekken dat je er niet bij kunt. Waar leg je de grens dan neer? Dat wordt de komende tijd een interesante vraag.

  4. Kun je het niet weer gewoon terugleggen bij de klant?

    Je kunt een paar suggesties doen om ’te voldoen aan de AVG’ of ’te voldoen aan specifieke elementen van de AVG’: Een Exportfunctie (kost xxx euro). Alternatief: handmatig de data opzoeken (bijvoorbeeld alle gegevens van een klant + al zijn bestellingen is vaak prima te vinden met normale functionaliteit). Een verwijder-alle-klantdata-functie (kost yyy euro). Alternatief: Handmatig verwijderen.

    Met klanten die de boete bij jou willen leggen moet je even het volgende scenario doorlopen: Stel, de software bevat een functie om de gewenste klantdata te exporteren. Maar het bedrijf weigert gewoon het data-inzage-verzoek. Dan kunnen zij dus die boete laten binnenkomen omdat ze die bij de software-ontwikkelaar gaan neerleggen? Dat kan natuurlijk niet.

  5. Er is hier natuurlijk wel een fundamenteel verschil. Als ik een product lever waarmee mijn klanten iets kunnen bijhouden dan vermoed ik dat ik sneller moet zorgen dat het gebruik van dit product aan de AVG voldoet dan als ik maatwerk lever. Ook bij een product geldt echter dat ik niet kan voorzien als bijvoorbeeld spreadsheetverkoper dat de klant er medische gegevens in opslaat.

    Voor maatwerk geldt dat het tot stand komt door voornamelijk functionele requirements. Ik vind het dan eigenlijk aan de klant om er voor zorg te dragen dat AVG-eisen in die functionele requirements staan. Maatwerk is uurtje-factuurtje. Bovendien zijn er allerlei afwegingen binnen de AVG die ik als ontwikkelaar eigenlijk niet kan maken en dat lijkt me ook niet mijn taak. Ik kan als ontwikkelaar bijvoorbeeld slecht bepalen welke rechtsvaardigingsgronden er zijn om een zekere set aan persoonsgegevens voor tijd X te bewaren. Ik zou er wel over in dialoog treden met mijn klant maar ik wil dat eigenlijk uit mijn verkoopproces houden. Mogelijk leidt dit tot aanpassing van onze algemene voorwaarden alhoewel ik er niet voor ben om lafjes al mijn verantwoordelijkheden van me af te werpen. Ik moet echter ook voorkomen dat ik ineens allerlei sales verlies omdat ik in mijn offertes wel rekening ga houden met aan de AVG gerelateerd door de klant ongevraagd meerwerk en daardoor duurder wordt dan concurrenten. Komt nog bij dat ik nogal een pietje precies ben als het gaat om dit soort dingen en voor je het weet ben ik presales met mijn klanten aan het bekvechten over wat de wet van hem eist. Brrr.

  6. Een paar open deuren:

    • Er bestaan geen write-only databases voor zover ik weet 😉

    • De ontwikkelkosten van de meeste softwareprojecten liggen bij de klant, tenzij anders is afgesproken.

    Uiteindelijk komt de discussie waarschijnlijk neer op “wat mag je standaard verwachten”. Nu is een exportfunctie nog niet iets dat je standaard mag verwachten als je dit niet expliciet in je opdracht opneemt, maar over een paar jaar misschien wel (ik zeg misschien want ik ben daar verre van zeker van). Wellicht zal er ook marktwerking zijn waarbij ontwikkelpartijen bij een pitch kunnen scoren met ingebouwde exportfunctie.

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.