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

| AE 10656 | Ondernemingsvrijheid, Privacy | 17 reacties

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

Je hebt nog 32 dagen om de AVG te implementeren #32totavg

| AE 10478 | Privacy | 30 reacties

Vandaag zijn er nog precies 32 dagen te gaan tot 25 mei 2018, de datum waarop de Algemene Verordening Gegevensbescherming (AVG, ook wel General Data Protection Regulation oftewel GDPR) van kracht wordt. Er is nog steeds veel onzekerheid over de AVG, die van alles zou verbieden of onwerkbaar maken. De AVG noem ik altijd vooral een compliance-wet: de nadruk ligt op formele procedures, documentatie en stappen die moeten worden genomen om aan de wet te voldoen. En minstens zo belangrijk: om aan te kunnen tonen dat je aan de wet voldoet, want de AVG bepaalt expliciet dat de bewijslast bij jou ligt dat je alles op orde hebt. Een hele kluif, maar zeker niet onoverkomelijk of fundamenteel onwerkbaar.

Een van de grootste mythes rond de AVG is dat deze nieuwe wet vooral voor juristen van belang is. Dat is niet zo. De AVG is zó breed van toepassing en stelt zó veel regels dat het iedereen aangaat. Van groot bedrijf tot kleine vereniging en van eenmansdokterspraktijk tot goed doel met duizenden donateurs. Voldoen aan de AVG is geen kwestie van nieuwe juridische documenten en een mooie toestemmingsverklaring laten tekenen door uw klanten.

Een belangrijk instrument daarbij is het verwerkingsregister, de centrale plaats waarin iedere verwerking van persoonsgegevens moet zijn gedocumenteerd. Het formeel vastleggen van verwerkingen is een van de weinige echt nieuwe eisen uit de AVG. Doel hiervan is vooral organisaties te dwingen goed na te denken over wat zij doen met persoonsgegevens en waarom. Het register is daarvan de verslaglegging. Tevens biedt registreren van een verwerking de mogelijkheid te checken of deze inhoudelijk voldoet, omdat je in het register ook zaken als grondslag en bewaartermijn uitwerkt en verwijst naar gepast beveiligingsbeleid. Dan moet je daar wel over nagedacht hebben, natuurlijk.

Kort en goed neem je in het register per verwerking het volgende op:

  • Naam en contactgegevens van de verantwoordelijke entiteit; dit is niet alleen de bedrijfsnaam maar ook de concrete afdeling en de verantwoordelijke manager of business owner.
  • De doeleinden, zoals “Salarisadministratie” of “Beveiliging van pand en goederen middels camera’s met geluidssensoren” met een omschrijving van de grondslag (toestemming, overeenkomst, et cetera).
  • De grondslag voor deze verwerking, zoals toestemming of een eigen belang, inclusief onderbouwing daarvan.
  • Een omschrijving van betrokkenen, zoals personeel, klanten, bezoekers of passanten.
  • Een omschrijving van ontvangers, zoals de afdeling die het uitvoert, het beveiligingsbedrijf dat de camerabeelden uitkijkt en de politie in geval van strafbare feiten. Ontvangers in landen buiten de EU moeten apart worden genoemd (inclusief land).
  • De bewaartermijnen, inclusief motivatie waarom deze termijnen en niet korter.
  • Een beschrijving van de beveiligingsmaatregelen voor deze verwerking, u mag hierbij verwijzen naar het algemene beveiligingsbeleid.
  • Een inschatting van het risico voor betrokkenen; als u meent dat dit hoger is dan normaal dan moet je een privacy impact assessment (PIA) uitvoeren (zie hoofdstuk 5).

Vaak wordt gezegd dat de AVG van alles en nog wat gaat verbieden. Niets is minder waar. De regels worden veel strenger, maar zijn vooral gericht op verantwoording afleggen. Toestemming vragen kan prima, maar kunt u bewijzen welke toestemming is gegeven, zijn mensen adequaat voorgelicht en kennen zij hun rechten? Gegevens tien jaar bewaren: oké, maar onderbouw eens waarom dat nodig is en niet een jaartje minder? Wij noemen de AVG daarom vooral een compliance-wet. Er moet veel geregeld en gedocumenteerd worden. Wat precies en hoe, dat leest u in ons Praktijkboek AVG Compliance.

Arnoud

GPL compliance engineering guide uitgebracht

| AE 1289 | Intellectuele rechten | 4 reacties

lolcat-im-in-ur-cvs.jpgVorige week verscheen versie 1 van de GPL Compliance Engineering Guide, geschreven door Armijn Hemel die u waarschijnlijk wel kent van het GPL-Violations project. Dit is een handleiding over hoe GPL-schendingen op te sporen. Een mooie aanvulling dus op de gids van SFLC waarin algemene stappen staan over hoe je je als bedrijf aan de GPL moet houden.

Wie zin heeft om eens wat apparaatjes open te schroeven en te kijken welke GPL software hij kan vinden, moet zeker eens met deze gids aan de gang gaan. Van nmap commando's tot soldeerinstructies om een apparaat aan je PC te kunnen hangen zodat je het kunt inspecteren.

Veel schendingen blijken in de CE industrie voor te komen. Niet zo gek gezien de zeer lage marges en hoge volumes: het gaat om snelheid en kostenbesparingen bij veel dozenschuivers, en de kosten van het volledig compliant zijn met open source licenties wegen daar niet altijd tegenop. Met gidsen als deze kunnen mensen gemakkelijker violations aantonen, en bedrijven die dit doen onder druk zetten zodat iedereen, ook de low-margin CE industrie, zich netjes aan de licenties houdt.

Via The Inquirer.

Arnoud