Hmmm … https://www.security.nl/posting/873744/Centric+meldt+diefstal+van+privacygevoelige+gegevens+klant+op+testserver

Hmmm test systemen met live data. What could go wrong. Now we know.

Onbegrijpelijk.. er is zelf officiële test data gratis beschikbaar waarmee overheden kunnen test.. zie https://www.cip-overheid.nl/producten-en-diensten/Testdorp

haha, testen met echte data.. da's als oefenen met live ammo...

Oefendata (of gepseudonimseerde) data levert helaas niet altijd het gewenste resultaat bij het testen.
Werkelijke klantdata zal altijd onvoorspelbaarder en weerbarstiger zijn dat oefendata. En dus fouten in de software vinden die die oefendata niet zien.

En, is er een mogelijk verband van hun overlijden met de gelekte test?
Dat zou onderzocht kunnen worden, analoog, voor de veiligheid.

Goed anonimiseren in een testomgeving zonder database connecties stuk te maken is inderdaad erg lastig, en als dit niet goed doordacht gebeurt levert het veel fase positives op met test werk. Vooral met veel gekoppelde applicaties .

Maar we zien dat het ondanks de uitdagingen een must is, want plenty it leveranciers zitten hier ook in te wroeten.

Dit was ook direct mijn gedachte toen ik dit las.....

Benieuwd hoe dit zit met AVG en doelbinding?? Is er toestemming gegeven om persoonsgegevens te gebruiken om ICT-systemen te testen... Ik verwacht van niet.

Ik ben geen jurist, maar schadeclaim lijkt me kansrijk

Als je de PDF van Amersfoort bekijkt waar het artikel naar linkt kan je lezen dat de testomgeving voornamelijk fictieve persoonsgegevens bevat maar ook bestaande omdat die nodig zouden zijn voor realistische tests. Er zijn van 24 mensen gegevens gelekt, dus die zullen zijn toegevoegd voor die realistische tests, misschien wel aan de dataset waar jij naar verwijst.

Dus wat maakt dat een test niet realistisch zou zijn als gegevens fictief of geanonimiseerd zijn? Toen ik in het verleden als ontwikkelaar werkte heb ik meerdere keren bij gebruikerstests mensen meegemaakt die erg slecht in staat bleken om voor hun bekende situaties nog te overzien als er met fictieve namen en andere identificerende gegevens werd gewerkt. Die kenden concrete gevallen die problematisch waren in het oude systeem op hun duimpje, wat de reden was om die gevallen in de testdata te verwerken, maar als je de identificerende gegevens veranderde waren ze los. Dan konden ze niet meer goed bij al die kennis erover die ze wel degelijk hadden, en dus niet goed testen en oordelen. De concrete identificerende gegevens waren voor hun kennelijk de ingang tot hun eigen kennis. Ik vermoed dat dat erop neerkomt dat die mensen vergaand concreet en nagenoeg niet abstract denken: alles moet aan echte, voor hun herkenbare situaties gekoppeld zijn. En dat zijn wel degenen die het systeem gaan gebruiken en die moeten beoordelen of het voor hun goed werkt.

Als je ze beperkt vindt overkomen: ja, die beperking hebben ze, en ik zelf zou weer bij lange na niet zo foutloos als zij kunnen werken in hun soort werk, want ik denk juist wel in abstracties en voor mij zijn die concrete gevallen voorbeelden van wat voor kan komen. Ik zou makkelijk gevallen door elkaar gaan halen, op een manier die in het bouwen van software niet erg is omdat al die varianten in de programmacode samenkomen, ze moeten tenslotte worden ondersteund, maar in klantcontacten en de bijbehorende administratie zou ik makkelijk fouten maken. Iedereen heeft talenten en beperkingen, en we mogen blij zijn dat we niet allemaal precies dezelfde hebben maar juist enorme divers zijn, daarom kunnen we als samenleving zoveel.

Ik weet niet of wat ik beschreef is wat hier bedoeld wordt, maar het lijkt me zeker een mogelijkheid. En ik weet er geen oplossing voor; wat ik hierboven beschrijf en het gebruik van fictieve of geanonimiseerde testdata zijn twee volkomen legitieme belangen die recht tegenover elkaar staan en waarvan ik niet inzie hoe ze met elkaar te verenigen zijn.

Echte bsns in een test omgeving...

Te stom voor woorden..mogen de getroffenen nu hun bsn wijzigen? Ooh nee dat kan weer niet

De overheid met data is een drama - het landt per definitie waar je het niet hebben wilt.
De overheid met IT is een drama. Ze snappen het niet. Ze kunnen het niet. En ze leren niet.

Nu die 2 gecombineerd: joh, maakt niet uit. Het zijn maar burgers. Je leest er wat over in de krant en volgende week: business as usual. Want zo werkt dat bij de overheid. De gevolgen zijn uitsluitend voor de slachtoffers, nooit voor de prutsers.

Je weet dat het een nietszeggend nummertje is dat juist voor de koppeling naar andere systemen leidend is.
De hele angst rond BSN's leidt tot ernstige privacy inbreuken omdat systemen niet goed functioneren.
Het was een van de achterliggende werkelijke problemen in de toeslagenaffaire met zeer veel niet herleidbare personen.

Ik val in de herhaling als ik beweer dat er nooit wat zal veranderen als er geen koppen rollen.

Waarom wordt er dan ook met echte data gewerkt in een... testomgeving.

Toestemming is niet de enige AVG grondslag. Er is ook "gerechtvaardigd belang" en "overeenkomst". De gemeente zal een overeenkomst met deze leverancier hebben (hence leverancier) en hopelijk is er ook een verwerkersovereenkomst waarin leverancier belooft 'passende technische en organisatorische maatregelen' te treffen. De leverancier zal claimen dat het gebruik van deze data noodzakelijk is om het systeem goed te kunnen testen en zo de overeenkomst met de gemeente na te kunnen komen. Als dat allemaal zo is blijft alleen over dat de 'passende technische en organisatorische maatregelen' toch niet passend zijn gebleken.

Een schadeclaim kun je vergeten. Probleem is dat je om schade te kunnen claimen, deze schade financieel moet zijn en te bewijzen. Dus als jij geen bonnetje kunt overleggen waarop staat dat dit datalek jou 100,- heeft gekost, maak je geen enkele kans. Wat mij betref een grote omissie in de AVG, zo is er geen goede incentive om dataminimalisatie serieus te nemen.

Omdat je soms geen keus hebt om de goede werking van een stuk software te testen.
Het alternatief is om de software onvoldoende getest in productie te nemen.
En ook dan kan er data lekken. Alleen als het dan gebeurt, is het veel meer dan de test-set die nu gelekt is.

Een schadeclaim kun je vergeten. Probleem is dat je om schade te kunnen claimen, deze schade financieel moet zijn en te bewijzen. Dus als jij geen bonnetje kunt overleggen waarop staat dat dit datalek jou 100,- heeft gekost, maak je geen enkele kans. Wat mij betref een grote omissie in de AVG, zo is er geen goede incentive om dataminimalisatie serieus te nemen.[/quote]
Vanuit een AVG/Wet oogpunt wel. Maar er zijn vaak in de contracten wel degelijk clausules opgenomen over schadevergoeding bij datalek/incident. Als Amersfoort hier nu werk van maakt kan het best zijn dat ze vanuit contractuele verplichtingen schade moeten vergoeden (Centric). Afhankelijk van hoe het gedefinieerd is binnen het contract kan het de daadwerkelijke schade zijn die vergoed moet worden; of een (percentage) van de contractwaarde of zelfs een vastgesteld bedrag.

Ik ben wél jurist, en een schadeclaim maakt bij onze rechters geen schijn van kans, tenzij er aantoonbaar zéér concreet materiële schade is geleden.

In het verleden is wel voorgesteld om bij elk datalek de geraakte personen standaard een schadevergoeding te geven. Daar is nooit meer wat over gehoord. Het gaat al te snel om teveel slachtoffers en teveel incidenten.

Om te beginnen houdt dit dus in dat de Functionele Specificaties niet op orde zijn. Hetgeen dan tevens inhoudt dat de Test Specificaties óók niet op orde zijn.
En het geheel houdt dus in dat de gehele teststraat iets gaat opleveren dat in de praktijk problemen gaat opleveren.

En de oplossing is dan ook betrekkelijk simpel : de opdrachtgever/projecteigenaar mag haar/zijn carriere elders voortzetten, en er worden een Requirements Manager en een Testmanager aangesteld c.q. ingehuurd.

Nee, zo werkt het dus niet onder de AVG.
Om te beginnen al niet omdat het doelbindingsbeginsel wordt geschonden.
Overigens bestaat over over deze specifieke casus al de nodige jurisprudentie.

Opvallend de overeenkomsten met een Hongaars incident in 2018 (ECLI:EU:C:2022:805).