Wat zijn de juridische risico’s als jouw ongeteste software persoonsgegevens verwerkt?

Ongeteste software die persoonsgegevens verwerkt, brengt serieuze juridische risico’s met zich mee. Onder de Algemene Verordening Gegevensbescherming (AVG) zijn organisaties verplicht passende technische maatregelen te treffen om persoonsgegevens te beschermen, en onvoldoende testen geldt als een schending van die verplichting. De gevolgen kunnen oplopen van boetes tot reputatieschade en aansprakelijkheidsclaims. In dit artikel beantwoorden we de meest gestelde vragen over AVG, softwaretesten en privacy, zodat jij weet waar jouw organisatie aan toe is. Heb je vragen over jouw specifieke situatie? We helpen je graag verder via onze contactpagina.

Welke AVG-verplichtingen gelden voor software die persoonsgegevens verwerkt?

Software die persoonsgegevens verwerkt, moet voldoen aan de beginselen van de AVG, waaronder dataminimalisatie, integriteit, vertrouwelijkheid en doelbinding. Artikel 25 van de AVG verplicht organisaties tot privacy by design en privacy by default, wat betekent dat gegevensbescherming al bij de ontwikkeling van software moet worden ingebouwd, niet achteraf.

Concreet betekent dit dat een organisatie technische en organisatorische maatregelen moet documenteren en aantonen. Voor software houdt dat onder andere in: toegangsbeveiliging, versleuteling van persoonsgegevens, beperking van dataverzameling tot het strikt noodzakelijke en een aantoonbaar testproces. Het is niet voldoende om te zeggen dat de software veilig is. Je moet kunnen bewijzen dat je dit serieus hebt onderzocht.

Daarnaast geldt de verantwoordingsplicht uit artikel 5 lid 2 AVG. Organisaties moeten kunnen aantonen dat zij de AVG naleven. Een gedocumenteerde teststrategie voor software die persoonsgegevens verwerkt, is daarmee geen luxe, maar een juridische noodzaak.

Wat kan er misgaan als software met persoonsgegevens niet getest is?

Ongeteste software die persoonsgegevens verwerkt, kan leiden tot datalekken, onbedoelde blootstelling van gevoelige informatie, onjuiste verwerking van gegevens en ongeautoriseerde toegang. Elk van deze situaties vormt een potentiële schending van de AVG en kan leiden tot een meldplicht bij de Autoriteit Persoonsgegevens.

De risico’s van ongeteste software zijn concreet en veelzijdig:

• Logicafouten in de verwerkingslogica kunnen ertoe leiden dat persoonsgegevens van de verkeerde persoon worden getoond of opgeslagen.
• Beveiligingslekken zoals SQL-injectie of onbeveiligde API-endpoints maken het voor kwaadwillenden mogelijk om toegang te krijgen tot databases met persoonsgegevens.
• Onbedoelde dataretentie treedt op wanneer software gegevens langer bewaart dan toegestaan door de AVG, doordat bewaarregels niet zijn getest.
• Onjuiste toegangscontrole kan ervoor zorgen dat medewerkers meer gegevens inzien dan noodzakelijk voor hun functie.

Al deze situaties zijn niet hypothetisch. Ze komen in de praktijk voor bij organisaties die softwaretesten voor privacy als bijzaak beschouwen. De schade is dan niet alleen financieel, maar ook het vertrouwen van klanten en medewerkers kan ernstig worden aangetast.

Welke sancties riskeert een organisatie bij een datalek door softwarefouten?

Bij een datalek veroorzaakt door softwarefouten riskeert een organisatie een boete van de Autoriteit Persoonsgegevens van maximaal 20 miljoen euro of 4% van de wereldwijde jaarlijkse omzet, afhankelijk van welk bedrag hoger is. Naast de bestuurlijke boete zijn er ook civielrechtelijke aansprakelijkheidsrisico’s en reputatieschade.

De hoogte van een eventuele boete hangt af van meerdere factoren, waaronder de ernst van de overtreding, het aantal betrokken personen, de aard van de verwerkte gegevens en de mate waarin de organisatie aantoonbaar maatregelen had getroffen. Organisaties die kunnen laten zien dat zij een serieus testproces hebben gevolgd, staan er bij een incident aanzienlijk beter voor dan organisaties die dit hebben nagelaten.

Bovendien geldt een meldplicht: datalekken met een reëel risico voor betrokkenen moeten binnen 72 uur worden gemeld bij de Autoriteit Persoonsgegevens. Wie dit verzuimt, riskeert een aanvullende boete. In sommige gevallen moeten ook de betrokkenen zelf worden geïnformeerd, wat de reputatieschade verder vergroot.

Hoe toont een organisatie aan dat software voldoende getest is?

Een organisatie toont aan dat software voldoende getest is door een gedocumenteerde teststrategie, testplannen, testresultaten en een aantoonbaar proces van risicoanalyse en herstelacties bij te houden. Deze documentatie vormt het bewijs dat de organisatie haar verantwoordingsplicht serieus neemt.

In de praktijk betekent dit minimaal het volgende:

1. Een teststrategie die specifiek ingaat op privacyrisico’s en de bescherming van persoonsgegevens.
2. Testgevallen die gericht zijn op toegangscontrole, dataretentie, versleuteling en foutafhandeling.
3. Gedocumenteerde testresultaten inclusief gevonden bevindingen en de genomen maatregelen.
4. Herhaalbare regressietests die bij elke nieuwe versie van de software worden uitgevoerd.
5. Een aantoonbaar acceptatieproces waarbij privacygerelateerde testcriteria zijn opgenomen als definitie van gereed.

Wij helpen organisaties bij het opzetten van zo’n aantoonbaar en herhaalbaar testproces. Een zorgeloze teststrategie zorgt er niet alleen voor dat software beter werkt, maar biedt ook de juridische onderbouwing die je nodig hebt bij een controle of incident.

Wanneer is een DPIA verplicht bij het ontwikkelen van nieuwe software?

Een Data Protection Impact Assessment (DPIA) is verplicht wanneer nieuwe software een hoog privacyrisico oplevert voor betrokkenen. Dit is onder meer het geval bij grootschalige verwerking van bijzondere persoonsgegevens, stelselmatige monitoring van personen of geautomatiseerde besluitvorming met rechtsgevolgen.

De Autoriteit Persoonsgegevens heeft een lijst gepubliceerd van verwerkingen waarvoor een DPIA altijd verplicht is. Buiten die lijst geldt de vuistregel: als twee of meer van de negen risicocriteria van de Europese privacytoezichthouders van toepassing zijn, is een DPIA vereist. Voorbeelden van die criteria zijn:

• Verwerking van gevoelige gegevens zoals gezondheidsgegevens of biometrische gegevens.
• Koppeling van datasets uit verschillende bronnen.
• Verwerking van gegevens van kwetsbare groepen zoals kinderen of patiënten.
• Innovatieve technologie die nog niet eerder op grote schaal is ingezet.

Een DPIA is geen eenmalige formaliteit. De uitkomsten van een DPIA moeten worden meegenomen in de teststrategie. Risico’s die in een DPIA worden geïdentificeerd, moeten aantoonbaar zijn getest en gemitigeerd voordat de software in productie gaat.

Welke teststrategie verkleint de juridische risico’s het meest effectief?

De teststrategie die de juridische risico’s rondom persoonsgegevens het meest effectief verkleint, is een aanpak waarbij privacy- en beveiligingstesten vroeg in het ontwikkelproces worden geïntegreerd. Dit principe staat bekend als Shift-Left testen en zorgt ervoor dat privacyrisico’s worden ontdekt en opgelost voordat software in productie gaat.

Een effectieve teststrategie voor software die persoonsgegevens verwerkt, combineert meerdere testdisciplines:

• Functionele tests die controleren of de verwerkingslogica overeenkomt met de AVG-vereisten, zoals correcte uitvoering van inzageverzoeken en verwijderingen.
• Beveiligingstests gericht op het identificeren van kwetsbaarheden die toegang tot persoonsgegevens mogelijk maken.
• Performancetests om te voorkomen dat de software onder hoge belasting onverwacht gedrag vertoont dat tot dataverlies of blootstelling kan leiden.
• Regressietests die bij elke wijziging in de software worden herhaald om te garanderen dat bestaande privacywaarborgen intact blijven.

Door testen structureel in te bedden in het ontwikkelproces, in plaats van het te behandelen als een eindcontrole, bouw je een aantoonbare kwaliteitsborging op die ook juridisch standhoudt. Wil je weten hoe je dit voor jouw organisatie aanpakt? Neem contact met ons op en we denken graag met je mee.