Een lezer vroeg me:
De Algemene Verordening Gegevensbescherming (AVG of GDPR) stelt strenge eisen aan ICT-systemen, zoals privacy by design en beveiliging. Hebben wij nu een probleem met al onze legacy software?
Op 25 mei 2018 wordt de Algemene Verordening Gegevensbescherming (AVG of GDPR) van kracht. Deze gaat een grote verandering opleveren bij alle bedrijven die iets doen met persoonlijke gegevens. Eén belangrijk aspect daarbij is de inrichting van ICT-systemen die dergelijke persoonsgegevens opslaan.
Gegevensbescherming door ontwerp, in het Engels privacy by design, houdt in dat de voor verwerking gebruikte mechanismen zo zijn ontworpen dat zij zo veel mogelijk rekening houden met de privacy van betrokkenen en de vereisten uit de AVG. Een systeem dat hieraan voldoet, zou dus bijvoorbeeld knoppen ingebouwd hebben waarmee betrokkenen inzage in hun persoonsgegevens kunnen krijgen. Ook andere maatregelen, gericht op bijvoorbeeld het minimaliseren van de hoeveelheid persoonsgegevens en het zo spoedig mogelijk pseudonimiseren van persoonsgegevens, vallen onder dit beginsel.
Meer algemeen moeten passende technische en organisatorische maatregelen worden genomen om te waarborgen (én te kunnen aantonen) dat verwerkingen in overeenstemming met de AVG worden uitgevoerd. ICT-systemen moeten dus aantoonbaar uitgevoerd zijn met dergelijke waarborgen.
De AVG kent geen uitzondering voor software die reeds in gebruik was voor de inwerkingtreding (25 mei 2016). Dat betekent dat ook bij die systemen moet worden voldaan aan de eisen van passende waarborgen en privacy by design. In zoverre heb je dus een probleem met dergelijke legacy software.
Echter, de AVG eist ook weer niet dat je hele infrastructuur volledig opnieuw moet worden opgebouwd. Randvoorwaarde is namelijk dat je rekening houdt met de aard, de omvang, de context en het doel van de verwerking, alsook met de qua waarschijnlijkheid en ernst uiteenlopende risico’s voor de rechten en vrijheden van natuurlijke personen.
Je moet dus een afweging maken welke problemen of beperkingen er zitten in je huidige infrastructuur, en hoe je daar een kosteneffectieve oplossing kunt treffen waarmee mensen hun rechten kunnen halen. Dat kan zijn een vervanging, maar een extra systeem er naast zou ook een legitieme oplossing kunnen zijn. Zolang je maar kunt aantonen dat je erover nagedacht hebt en dat deze oplossing uiteindelijk goed genoeg is.
Arnoud
Dit blijft een redelijk vaag antwoord. Verre van mij om kritiek te hebben op je juridische kunde, al was het maar omdat ik geen jurist ben, uiteraard maar hier zit wel min of meer de crux van het hele probleem. Bedrijven en instellingen hebben hele concrete vragen, als ze er al toe gekomen zijn na te denken over de AVG. Kort gezegd zijn dit vragen als ‘ben ik klaar voor de wet?’, ‘heb ik het goed gedaan zo?’, ‘loop ik nu risico op boetes?’ Het wordt ongetwijfeld nog een hele toer en een mooie klus voor de juristen om dit concreet te maken allemaal.
Laat ik nu ook geen jurist zijn, maar bedrijven hebben de concrete antwoorden op concrete vragen al; vaak willen ze die alleen niet horen.
Het probleem is dat juristen een klant alleen niet kunnen helpen het oplossen hiervan. Een jurist kan geen database-analyse toepassen om zo te concluderen dat het wel goed zit. Een jurist kan niet in het verleden kijken naar de vergaderingen die de ontwerpers hebben gehad om te kijken of ze privacy ook hebben meegenomen in het ontwerp.
Dat zijn zaken die door het bedrijf zelf opgelost moeten worden. Een jurist kan alleen een handreiking geven, en misschien een aantal dingen die als laag-hangend fruit gelden.
Oh gut, maar ik heb ook nooit bedoeld dat enige jurist het anders zou moeten doen! Natuurlijk kunnen juristen maar tot zover helpen en moet je wel iets doen met hun raad. Ik denk wel dat je iets te makkelijk denkt over die database analyses. Als ik een bedrijf had en ik wilde zeker zijn van m’n zaak dan zou ik bedoelen: ‘heb ik het zo geregeld dat een rechter me niet zal veroordelen voor overtreding van de AVG?’
Daar ben ik het niet mee eens. Ik verwacht van een gespecialiseerde jurist wel dat hij na een inleiding concreet de grootste risicopunten kan identificeren, kan zeggen, eventueel na wat dieper navragen, of daar wel of niet volgens de wet mee wordt omgegaan, en CONCREET kan aangeven wat er moet veranderen.
Er zal dan inderdaad een restrisico zijn.
Om in jouw voorbeeld te blijven: de jurist kan best aan het hoofd IT vragen: Is bij het ontwerp van de database privacy meegenomen, en hoe? En ik geloof meteen dat het hoofd IT het antwoord niet uit zijn hoofd weet, maar hij zou het wel moeten kunnen vinden en die jurist een week later het antwoord geven.
Als je deze vraag hebt, benadeelt je oude software blijkbaar de privacy van je gebruikers. Dat had je natuurlijk nooit zo mogen opbouwen, maar tot nu toe was er geen wettelijke eis die je tegenhield. En nu die er wel is, ga je piepen dat je je software moet vervangen en dat dat allemaal zo lastig is?
Dat is redelijk ongenuanceerd.
Ik zou zeggen dat Transparant Data Encryption om je data at rest te beschermen iets is dat hoort bij privacy by design. Alleen is dit een feature die MS SQL server pas sinds de 2008 versie bied en Oracle als ik mij niet vergis ergens sinds 2010.
Een andere feature is row level security in Azure, dat is ook een recente ontwikkeling. Als je nu een database design maakt houdt je hier rekening mee.
Legacy systemen bestonden vaak echter al lang voor dat deze technologieën op de markt kwamen. Soms is iets eenvoudig toe te voegen en soms is dat erg lastig.
Je hield vroeger rekening met de privacy van je gebruikers, maar nu heb je meer tools die je niet zomaar kan inzetten. En er zullen genoeg bedrijven zijn waarvoor het herschrijven van de software om met de laatste ontwikkelingen te kunnen werken economisch niet haalbaar is.
Moeten we dan zeggen, jammer je had een mooi product maar sluit de tent maar vast want we hebben de wet aangepast en nu ga je failliet?
Dat bestaande software bepaalde features niet biedt is geen excuus; dan huur je maar iemand in om die features voor je te maken. Of je richt je bedrijfsproces maar zo in dat je geen bijzondere software-features nodig hebt om privacy te garanderen. Gegevens niet registreren of bewaren is nog steeds een heel effectieve manier van privacy beschermen.
Ik vraag me trouwens af: je noemt allemaal producten uit de commerciële hoek, met name Microsoft. Hoe zit het met vergelijkbare open source producten? Ik zou niet willen beweren dat die altijd beter up-to-date zijn qua features, maar traditioneel krijgt de privacy daar wel meer prioriteit. Daarnaast zou ik verwachten dat er bij open source producten betere mogelijkheden bestaan om er zelf aan te knutselen, of om het te combineren met andere (open source) producten. Dit nog afgezien van de inherente transparantie van open source software, die uiteindelijk ook een privacy-voordeel is (“weten wat er met je data gebeurt”).
Deels heb je natuurlijk volledig gelijk, echter is het wel raar dat er geen rekening mee is gehouden met het feit dat systemen die altijd voldaan hebben aan geldende wetgeving nu in eens niet meer zouden voldoen. Dat alle nieuwe software moet voldoen is uiteraard volledig logisch maar voor oudere software achteraf de spelregels veranderen is natuurlijk niet handig in alle gevallen. Het is lang niet altijd technisch mogelijk deze software “conform” te maken. En als je dan toevallig aan de andere kant weer te maken hebt met bewaarplichten kan dat lastig zijn.
Je kan inderdaad naar Open Source kijken, echter zitten daar vaak ook nadelen aan naast de bekende voordelen van Open Source an sich. Een van de nadelen is bijv. support, deze is bij veel Open Source zaken standaard niet aanwezig of zeer beperkt. En als bedrijf wil je juist dat als jij een (groot) probleem hebt in je software dat daar direct actie op komt vanuit de leverancier en niet wanneer een developer zin en tijd heeft. Zo maar een Open Source ERP pakket of CRM pakket inzetten is dus vaak lastig. Wel kan je uiteraard een commerciële oplossing kiezen gebouwd op een Open Source stack in plaats van op bijv. MS SQL server. Echter zal een commercieel product als MS SQL server in de regel geen bron of oorzaak zijn van een datalek, de lekken / oorzaken zitten in de regel in de software je installeert en gebruik maakt van zaken als MS SQL Server, IIS webserver e.d.
In eens? Je had twee jaar om je software aan te passen …
Als je denkt dat twee jaar voldoende is om software te herzien, moet je misschien contact opnemen met de belastingdienst ze horen graag van je 😉
De feitelijke vraag is hoe ver moet je gaan. Voor een project dat je in 2016 start is privacy by design heel wat anders als voor een project dat je in 2002 hebt gestart. En als er iets is dat je niet zomaar even doet is het wel het omgooien van het design van je programma.
Om het bij het encryptie voorbeel te houden, je kan op systeem-, database- of applicatieniveau encryptie doen. Dat laatste is zondermeer het veiligst en als je nu een product maakt dat privacygevoelige data opslaat is dat de meest logische keuze. Niet alleen is de data at rest beveiligd, ook als iemand zich toegang tot je database weet te verschaffen is de data nog veilig.
Het is echter iets wat zeer tijdrovend en kostbaar is om achteraf in te bouwen. Iets wat zeker niet voor iedereen haalbaar is, in 2 of in 10 jaar niet. Het economisch niet mogelijk, het geld is er niet voor.
Het systeem heeft echter wel encryptie op database niveau, wat de norm was toen het ontworpen werd en toen als veilig werd beschouwd. Het is absurd om dan nu te gaan zeggen als het altijd veilig was, er is nu iets nog veiligers, dat wat je hebt beschouwen we niet meer als veilig. Hoe ver moet je hierin gaan?
Met ineens doel ik niet op de 2 jaar tot de wet actief wordt, maar op het feit dat met terugwerkende kracht de spelregels aangepast worden voor bestaande oplossingen die altijd voldaan hebben aan de op dat moment geldende wetgeving.
Daarnaast 2 jaar is echt niets op software gebied. Een standaard migratie van bijv. courant ERP pakket A naar courant ERP pakket B gaat al makkelijk een jaar of 1-2 inzitten met vaak nog minimaal een jaar er aan vooraf aan voortraject. Laat staan migraties van Legacy software naar courante pakketten met vaak zeer ingewikkelde data conversies. Om over de kosten nog maar niet te spreken.
“Dat is redelijk ongenuanceerd.”
De werkelijkheid is vaak rauw en ongenuanceerd. Je hebt je jarenlang niet bekommerd of zelfs actief misbruik gemaakt van de privacy van je klanten/gebruikers/werknemers?
Dan volgt nu de rekening.
Dat bedoel ik dus met ongenuanceerd, je hebt een systeem gebouwd waarbij je al het mogelijke hebt gedaan om de privacy van je gebruikers te beschermen.
Er komen nieuwe middelen beschikbaar die niet zomaar gebruikt kunnen worden en een flinke investering in tijd (en geld) vergen, die economisch niet haalbaar zijn. Dan verandert men de wet en zegt hé, je gebruikt die techniek niet, je doet het niet goed.
Vervolgens komt Branko Collin langs die je begint zwart te maken dat je jezelf ‘jaren lang niet bekommert hebt om privacy van je gebruikers’. Dank u!
Privacy by design is leuk, maar veel nieuwe technieken vereisen dat je er vanaf het begin rekening mee houdt. Vraag voor de lol eens aan bedrijven hoe economisch haalbaar het is als ze hun software vanaf de grond af opnieuw op moeten bouwen? Iedere product van omvang waar enige serieuze ontwikkeling in tijd in zit zal de maker je hard uitlachen.
Met juridische kennis alleen kom je bij dit soort vraagstukken niet ver. Met een jurist met meer dan alleen juridische kennis kom je heel ver. Dit blog getuigt daar van.
Zowel de oude richtlijn als de AVG zijn geschreven voor markt en voor overheid. Beide kunnen zich bij de implementatie bedienen van risicomanagement. Die analyse zal ook over de bestaande automatisering moeten gaan.
Ik begrijp dat de art 29 werkgroep heeft aangegeven dat een GEB alleen nodig zou zijn in geval van nieuwe risico’s. Is de vraag of, als een GEB niet nodig is, je wel tot aanpassing van de software over zou moeten gaan (en wat die aanpassing dan zou moeten zijn) Andere vraag is of je vol kan houden dat er geen nieuwe risico’s zijn als je nooit een risicoinventarisatie gedaan hebt, doe je die dan pas voor de eerste keer dan is in feite elk gevonden risico nieuw
het gebruik van de software is meestal de boosdoener. Als je dat kan wijzigen, dan beperk je veel risico. zo kan een webshop er van af zien om van klanten accounts bij te houden. eenmalige inschrijvingen voor elke bestelling beperkt veel privacy issues. daarnaast zij. bestaande applicaties, en dan vooral het opslaan van de data, uit te breiden met anomymisatie zonder functionaliteit te schaden. pseudonymisatie is vaak ook genoeg. re-design van de processen is echter het meest effectief.