image

Juridische vraag: De nieuwe AVG stelt strenge eisen aan ICT-systemen. Hoe zit het met software die reeds in gebruik was voor de inwerkingtreding?

woensdag 4 oktober 2017, 13:29 door Arnoud Engelfriet, 14 reacties

Ict-jurist Arnoud Engelfriet geeft elke week antwoord op een interessante vraag over beveiliging, recht en privacy. Heb jij een vraag? Stuur hem naar juridischevraag@security.nl.

Vraag: 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?

Antwoord: 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 2018). 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 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 (14)
04-10-2017, 15:10 door Anoniem
Mag ik een nuance aanbrengen? De AVG is in mei 2016 aangenomen, en is als Europese wetgeving in principe direct van kracht. De termijn tussen mei 2016 en mei 2018 is (was ...) juist bedoeld om de tijd te hebben om maatregelen te treffen. De (terecht) genoemde afweging had je al veel eerder moeten maken. De organisaties die nu pas gaan nadenken en "iets" gaan doen hebben echt niet opgelet.
04-10-2017, 18:11 door Anoniem
En niet alle kwetsbaarheden dienen in de softwaresystemen opgelost te worden. Maatregelen kunnen ook in de processen/organisatie 'opgelost' worden.
05-10-2017, 08:04 door Anoniem
'Privacy by design' is feitelijk een procesbenadering om te zorgen dat een systeem aan de eisen op het gebied van 'privacy' voldoen. Uiteindelijk doel is een systeem dat een passend niveau van beveiliging biedt. Dat staat al jaren in de Wbp dus in dit opzicht verandert er in beginsel niets. Veranderingen zitten meer in zaken als aanscherping van het recht op inzage en het recht om je persoonsgegevens (digitaal) mee te kunnen nemen (data portabiliteit).
05-10-2017, 12:01 door Anoniem
Volgens mij zit de grootste uitdaging voor de systemen vanuit de nieuwe wetgeving (AVG/GDPR) is het recht om gegevens te verwijderen. Ik ken nog geen systemen die het mogelijk maken om met een druk op de knop alle aan een person gerelateerde gegevens uit een systeem/database te verwijderen (of zelfs te anonymiseren).

Ook de bekende discussie over back-ups spelt daarbij een rol. Je kan geen persoonsgegevens in een back-up verwijderen. Hoe ga je er dan mee om dat je bij het terugzetten van een back-up alsnog de juiste gegevens weer verwijdert of afschermt? Ik heb nog geen systemen gezien die daarbij kunnen helpen (ik sta open voor tips! ... ;-)).

Het gaat erg ver voor een organisatie die bijna alleen maar persoonsgegevens verwerkt (financiele instelling) om alle software leveranciers te vragen nieuwe versies van applicaties op te leveren voor mei 2018. Ook zie ik verdacht weinig 'GDPR' verschijnen in de roadmaps van leveranciers van standaardapplicaties...
06-10-2017, 07:39 door karma4
Door Anoniem: 'Privacy by design' is feitelijk een procesbenadering om te zorgen dat een systeem aan de eisen op het gebied van 'privacy' voldoen. Uiteindelijk doel is een systeem dat een passend niveau van beveiliging biedt. Dat staat al jaren in de Wbp dus in dit opzicht verandert er in beginsel niets. Veranderingen zitten meer in zaken als aanscherping van het recht op inzage en het recht om je persoonsgegevens (digitaal) mee te kunnen nemen (data portabiliteit).
Heel netjes en abstract verwoord.
Het betekent ook dat je dogma's moet durven loslaten Hoe iets aangepakt moet worden. Kijk dan eens naar een dwh data valt ofwel Lindsted Kimball Inmon voor olap. Zeg maar de spreadsheet en draaitabel van Excel op server based dure systemen. Security en privacy ontbreekt by design. Wat ontbreekt en door de consultants en volgelingen geroepen wordt dat het zo hoort is heel lastig zo niet onmogelijk te veranderen.
06-10-2017, 08:05 door karma4
Door Anoniem: Volgens mij zit de grootste uitdaging voor de systemen vanuit de nieuwe wetgeving (AVG/GDPR) is het recht om gegevens te verwijderen.
...
Ook de bekende discussie over back-ups spelt daarbij een rol. Je kan geen persoonsgegevens in een back-up verwijderen. Hoe ga je er dan mee om dat je bij het terugzetten van een back-up alsnog de juiste gegevens weer verwijdert of afschermt? Ik heb nog geen systemen gezien die daarbij kunnen ......
Het gaat erg ver voor een organisatie die bijna alleen maar persoonsgegevens verwerkt (financiele instelling) om alle software leveranciers te vragen nieuwe versies van applicatie ....
Je geeft zelf al aan dat gegevens op een backup niet toegangkelijk zijn onder normale condities.
Dan is je vraag om het daarvandaan te verwijderen niet echt relevant meer.
Gegevens laten verwijderen is geen absoluut recht. Genoeg redenen dat het bewaard moet blijven.
Financiële instellingen zijn verplicht veel details jarenlang te bewaren. Betaalgegevens verzekeringsgegevens en meer lijken zeker persoonsgegevens (herleidbaar etc.).

Een backup herstellen tot de situatie vlak voor het event geldig was is een gangbare oplossing. Je hebt een quisced moment van alle data (volledige backup). Daarna ga je met journals/logfiles alle veranderingen doorvoeren. Dat betreft insets updates en deletes (roll forward). Het hangt een beetje van de dbms leverancier af wat de terminologie is.

Documenten en meer kunnen via blobs (binary long objects) daarin gewoon mee. Via webdav zie je vaak de koppeling naar een dbms. De meeste grote organisaties werken met systemen die zo opgezet zijn voor de kritische delen.
Het is wat anders dan de eenvoud van losse bestandjes.

Het echt grote probleem lijkt me al die zelf door gebruikers gemaakte applicaties. Gewoonlijk ontstaan omdat de ict geen thuis geeft. Dan heb je de situatie dat je niet weet welke data door wie waarvoor en wanneer gebruikt wordt.
Dat oplossen lijkt me echt een probleem waardoor gdpr wel een niet in te vullen iets blijkt.
06-10-2017, 08:20 door Anoniem
Door karma4:
Je geeft zelf al aan dat gegevens op een backup niet toegangkelijk zijn onder normale condities.
Dan is je vraag om het daarvandaan te verwijderen niet echt relevant meer.
...
Een backup herstellen tot de situatie vlak voor het event geldig was is een gangbare oplossing.

Als je mijn reactie goed leest gaat het dan ook niet over het deleten van persoonsgegevens van een back-up, maar hoe ga je om bij het terugzetten.

Stel je voor: je back-upt maar 1 keer per dag. Aan het eind van de dag heb je een crash/calamiteit, waardoor je de back-up van gisteren moet terugzetten. Je zult dan alle verzoeken tot verwijdering die op de verloren gegane dag zijn gedaan, opnieuw moeten doorvoeren. Dat vereist bijv. een apart register. Het wordt lastiger als het verwijderen automatisch is gedaan. Dan zul je systemen logfiles moeten bijhouden van het verwijderen die dan weer apart worden bewaard.

Ik zie nog geen standaard applicaties binnen de financiele dienstverlening die dit soort functionaliteiten al hebben ingebouwd.

Je hebt zeker een punt met door gebruikers gemaakte applicaties. Of andere 'shadow IT'. Daar voer je vanzelfsprekend vanuit IT geen centrale regie over, en zal dus lastig aan te pakken zijn.
06-10-2017, 13:42 door eL-Prova - Bijgewerkt: 06-10-2017, 13:43
@Anoniem en @Karma,

Het recht op vergeten te worden als burger / gebruiker moet worden gewaarborgd. We kunnen dus ook niet verwachten dat software leveranciers hier al rekening mee hebben gehouden.
Het behouden van data / gebruikers dient te worden onderbouwd met de wettelijke noodzaak.

Binnen gemeente land betekent dat voor het uitvoeren van wettelijke taak zij de gegevens mogen gebruiken. Een vergunning kan voor bepaalde tijd worden afgegeven voor het wordt gearchivieerd. In die context mogen de gegevens bewaard blijven. Echter mocht het gaan om iets wat verlopen en verjaard is, moet het verwijderd worden, zelfs als de gebruiker/burger er niet om heeft gevraagd.

Het scenario waarin een backup moet worden teruggezet zal misschien goed zijn te zijn verwerkt in interne procedures.

@Arnound, helder artikel en verwoord. Wel ben ik benieuwd of de AVG zichzelf eigenlijk dan niet ontkracht met jou benadering
Zolang je maar kunt aantonen dat je erover nagedacht hebt en dat deze oplossing uiteindelijk goed genoeg is.
Of stel je hiermee dat de rechter hierin maar moet gaan afwegen of die het met jou eens is?
06-10-2017, 14:48 door Arnoud Engelfriet
Door eL-Prova:
@Arnound, helder artikel en verwoord. Wel ben ik benieuwd of de AVG zichzelf eigenlijk dan niet ontkracht met jou benadering
Zolang je maar kunt aantonen dat je erover nagedacht hebt en dat deze oplossing uiteindelijk goed genoeg is.
Of stel je hiermee dat de rechter hierin maar moet gaan afwegen of die het met jou eens is?
Uiteraard moet je die belangenafweging bij de rechter kunnen verdedigen, en het moet inhoudelijk dus wel echt een goed verhaal zijn. Maar als je dat verhaal rondkrijgt, dan kan er veel.
06-10-2017, 17:07 door Anoniem
Door Anoniem: Mag ik een nuance aanbrengen? De AVG is in mei 2016 aangenomen, en is als Europese wetgeving in principe direct van kracht. De termijn tussen mei 2016 en mei 2018 is (was ...) juist bedoeld om de tijd te hebben om maatregelen te treffen. De (terecht) genoemde afweging had je al veel eerder moeten maken. De organisaties die nu pas gaan nadenken en "iets" gaan doen hebben echt niet opgelet.

Dat is niet helemaar waar!

De AVG is er voor een bepaald type bedrijf. stel ik was een heel klein webshopje en ben nu opeens door sterke groei concurent van bol.com, dan is het dus NIET zo dat dat bedrijf niet op aan het letten was destijds.

Al deel ik je mening wel, deze vraag is wel erg laat :P
06-10-2017, 19:51 door karma4 - Bijgewerkt: 06-10-2017, 20:04
Door eL-Prova:Het behouden van data / gebruikers dient te worden onderbouwd met de wettelijke noodzaak.
Er zijn wettelijke richtlijnen waarbij de gegevens bewaard moeten worden.
- https://autoriteitpersoonsgegevens.nl/nl/over-privacy/persoonsgegevens/bewaren-van-persoonsgegevens
"Organisaties mogen persoonsgegevens in een archief bewaren als dit bestemd is voor historische, statistische of wetenschappelijke doeleinden.
Tenzij de Archiefwet of een andere wet van toepassing is, geldt voor persoonsgegevens in een archief geen bewaartermijn."
Waar moet je dan aan denken:
- https://www.belastingdienst.nl/wps/wcm/connect/bldcontentnl/belastingdienst/zakelijk/ondernemen/administratie/administratie_opzetten/hoe_lang_moet_u_uw_administratie_bewaren 5 jaar vrijwillig voor de burger voor een mogelijke naheffing dat kan ook 12 jaar zijn. 7 jaar voor bedrijven en voor bepaalde bedrijven is dat 10 jaar.
- https://www.rijksoverheid.nl/onderwerpen/patientenrecht-en-clientenrecht/vraag-en-antwoord/mag-ik-mijn-medisch-dossier-inzien-laten-aanpassen-of-vernietigen bewaartermijn 15 jaar wettelijk verplicht.
Speelt er een juridische iets dan wordt die termijn nog eens verlengd met alle procesvoortgang.

Door eL-Prova:Het recht op vergeten te worden als burger / gebruiker moet worden gewaarborgd. We kunnen dus ook niet verwachten dat software leveranciers hier al rekening mee hebben gehouden.
Ik ken geen software waarmee er geen invulling aan de GDPR gegeven kan worden. Als jij tegenvoorbeelden gaarne naam / aanduiding van die software.
Als dataeigenaar persoon of organisatie ben je verplicht voor een juiste invulling van de gegevensverwerking. Het willen afschuiven op een leverancier is gewoon fout. De GDPR is heel duidelijk in die aansprakelijkheid.

Het is een ergernis waar ik op reageer. Als je als "best practice" van en leverancier accepteert met setup enter-enter met admin:admin op het publieke internet dan zit het goed fout. Kijk dan eens naar:
https://www.ncsc.nl/binaries/content/documents/ncsc-nl/actueel/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties/3/ICT%2BBeveiligingsrichtlijnen%2Bvoor%2BWebapplicaties%2B%2B%2BVerdieping%2B%2B%2BLeesversie.pdf "Documenteer van de eisen die voortkomen uit het beveiligingsbeleid of deze door de leverancier ingevuld zijn in de offerte, in het contract en in de uitvoering/levering." Die is intiatiefnemend (B05),

Bij U/PW.01 "Maak gebruik van bestaande richtlijnen van leverancier" U/PW.01 "Systeemhardening is een leverancier specifiek proces, aangezien de verschillende leveranciers het systeem op verschillende manieren configureren en voorzien van verschillende diensten tijdens het standaardinstallatieproces." met "Richt ICT-componenten (aantoonbaar) volgens de instructies en procedures van de leverancier in."
Zet je de deur wijd open voor leveranciers om er een janboel van te maken en er mee weg te komen. Zeker als je B05 vergeet.

Dat laatste heb ik meermalen mogen meemaken en dat betrof geen kleine organisaties. Het (een janboel) is zo te zien eerder regel dan uitzondering. Moet het geintegreerd worden in een IAM met zware policy eisen dan is een leverancier snel gezien. Het resultaat pappen en nathouden.
07-10-2017, 09:51 door karma4
Door Anoniem: .....
Ik zie nog geen standaard applicaties binnen de financiele dienstverlening die dit soort functionaliteiten al hebben ingebouwd. ...
Ik ken de financiële wereld goed.
- Een DBMS heeft die functionaliteit in het basisontwerp en als eis sinds het begin van hun ontstaan.
- De "applicaties" beter de tools/pakketten worden rond dat soort basisfuncties opgezet. Met die stap wordt de informatievoorziening hoe je een en ander inregelt als een stuk slechter. Er wordt verwezen naar de documentatie van de DBMS leverancier waarvoor je dan de technische specialisatie aan moet kunnen (DBA systeemprogrammeur).
- Functioneel beheerders zijn het verlengstuk van de pakketleverancier voor eenvoudige acties. Tevens zijn zij intern aanspreekpunt voor vragen. Uitgangspunt: minimale technische kennis van dat pakket, als het maar logisch werkt.

Ergo:
Alle standaard applicaties voldoen aan de gewenste functionaliteiten, je moet alleen weten hoe en de mensen er voor hebben. Geef eens een naam beschrijving van pakket waarbij het volgens jou ontbreekt.

Ter info wat bekende groteren):
https://blogs.sap.com/2017/05/20/sap-s4hana-finance-1610-bank-configuration/
https://www.oracle.com/nl/industries/financial-services/banking/solutions.html (voorheen siebel)
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzajt/rzajtcfg400tofbssrf.htm
09-10-2017, 15:48 door Anoniem
Door Anoniem: Mag ik een nuance aanbrengen? De AVG is in mei 2016 aangenomen, en is als Europese wetgeving in principe direct van kracht. De termijn tussen mei 2016 en mei 2018 is (was ...) juist bedoeld om de tijd te hebben om maatregelen te treffen. De (terecht) genoemde afweging had je al veel eerder moeten maken. De organisaties die nu pas gaan nadenken en "iets" gaan doen hebben echt niet opgelet.

De AVG is inderdaad in 2016 aangenomen, echter de meeste privacy richtlijnen uit de AVG stonden ook al in de de WBP en deze is al uit 1994.
13-10-2017, 09:23 door Anoniem
Door karma4:
Door Anoniem: .....
Ik zie nog geen standaard applicaties binnen de financiele dienstverlening die dit soort functionaliteiten al hebben ingebouwd. ...
Ik ken de financiële wereld goed.
- Een DBMS heeft die functionaliteit in het basisontwerp en als eis sinds het begin van hun ontstaan.
- De "applicaties" beter de tools/pakketten worden rond dat soort basisfuncties opgezet. Met die stap wordt de informatievoorziening hoe je een en ander inregelt als een stuk slechter. Er wordt verwezen naar de documentatie van de DBMS leverancier waarvoor je dan de technische specialisatie aan moet kunnen (DBA systeemprogrammeur).
- Functioneel beheerders zijn het verlengstuk van de pakketleverancier voor eenvoudige acties. Tevens zijn zij intern aanspreekpunt voor vragen. Uitgangspunt: minimale technische kennis van dat pakket, als het maar logisch werkt.

Ergo:
Alle standaard applicaties voldoen aan de gewenste functionaliteiten, je moet alleen weten hoe en de mensen er voor hebben. Geef eens een naam beschrijving van pakket waarbij het volgens jou ontbreekt.

Ter info wat bekende groteren):
https://blogs.sap.com/2017/05/20/sap-s4hana-finance-1610-bank-configuration/
https://www.oracle.com/nl/industries/financial-services/banking/solutions.html (voorheen siebel)
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzajt/rzajtcfg400tofbssrf.htm

Paar opmerkingen:
De applicaties die jij noemt zou ik nu juist geen standard applicaties noemen. Dat zijn ERP-systemen. Uit je lijstje zie ik alleen Oracle bij sommige financiele instellingen terugkomen.

Met standaardapplicaties bedoel ik applicaties die zonder veel configuratie in te zetten zijn.

En wat je zelf daarvoor stelt, geeft eigenlijk al aan dat de standaard applicaties geen functionaliteiten bevatten om bijv. het 'right to be forgotten' te ondersteunen. Het is natuurlijk ondoenlijk om zelf via het (R)DBMS onder de applicatie, de juiste gegevens af te moeten schermen voor de juiste individuen in de organisatie. Je wilt daar natuurlijk gewoon kunnen steunen op de IAM mechanismen in de applicatie zelf. Dit soort dingen direct via het (R)DBMS proberen te regelen buiten de applicatie om: dat zal je auditor niet leuk vinden...

Wat je zou verwachten is dat er in de standaard applicaties functionaliteit aanwezig is om retentie van data te kunnen waarborgen (door voor alle data bijv. automatisch een termijn voor retentie toe te voegen en de data daarna te verwijderen of af te schermen) en om de 'right to be forgotten' te kunnen waarborgen. Dus simpel gezegd: een button in het betreffende klantrecord, waarop je kunt drukken om de betreffende klantgegevens te verwijderen of af te schermen.

Ik heb het nog niet gezien. En dan heb ik best veel banken van binnen gezien en ontelbare standaard applicaties voor hypotheken, sparen, corporate loans, finance, treasury, etc. langs zien komen...
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.