De GDPR definieert dat persoonsgegevens juist moeten zijn.

De juistheid van de verwerkte persoonsgegevens is immers een van de basisbeginselen van de GDPR verordening, naast o.a. een rechtmatige verwerking, doelbinding van de verwerkte persoonsgegevens.

Het is daarom enorm belangrijk dat de persoonsgegevens die de verwerkingsverantwoordelijke verwerkt juist zijn, en vooral ook juist blijven gedurende de levenscyclus van deze persoonsgegevens.

Helaas blijkt dit in de praktijk niet altijd het geval te zijn, en dit om verschillende redenen.

GDPR en de juistheid van persoonsgegevens

Dat persoonsgegevens die door een verwerkingsverantwoordelijke worden verwerkt juist dienen te zijn is normaal.

Immers de verwerkingsverantwoordelijke moet zich kunnen verantwoorden voor de verwerkingen die hij uitvoert, en hiertoe behoort ook de juistheid van de persoonsgegevens.

Maar hoe komt het dat verwerkte persoonsgegevens onjuist kunnen zijn?

Geregistreerde persoonsgegevens kunnen gedurende hun levenscyclus fouten gaan vertonen door verschillende omstandigheden, waaronder:

• Geïsoleerde ontwikkelingsteams kopiëren en modifiëren dezelfde persoonsgegevens;
• Geïsoleerde ontwikkelingsteams hebben geen gemeenschappelijke (data) governance;
• …

Geïsoleerde ontwikkelingsteams

Organisaties die werken met autonome, geïsoleerde ontwikkelingsteams en niet beschikken over een software development governance, of de vastgelegde eisen van de bestaande governance niet naleven, lopen een groot risico dat er bij de ontwikkeling van software geen standardisatie noch uniformiteit is.

Het gebrek aan standardisatie en uniformiteit veruitwendigt zich o.a. in inconsistente naam conventies, een gebrek aan controles bij het wegschrijven van (via end-users of geconnecteerde applicaties) ontvangen gegevens, etc.

Bijvoorbeeld verwacht men een string te ontvangen van enkel alfanumerieke tekens met een maximale lengte van 100. Echter er is geen functie die voorziet in een preg_match() of een strlen(), zodat strings die toch niet alfanumerieke gegevens bevatten en langer zijn dan 100 tekens toch worden verwerkt; weliswaar afgekapt in de tabel worden geregistreerd.

In dit voorbeeld zal dit tot gevolg hebben dat wanneer die gegevens nadien worden opgehaald men onjuiste of onvolledige gegevens te zien zal krijgen.

Ontbreken van data governance

Een ander element dat kan leiden tot onjuistheden in persoonsgegevens is het ontbreken van data governance.

Wanneer men ontwikkelingsteams zonder controle persoonsgegevens laat kopiëren en eventueel synchroniseren in tabellen die zijzelf beheren, en toelaat dat daarop (softwarematig) modificaties worden op uitgevoerd, dan zal dit na verloop van tijd mogelijk leiden tot data inconsistenties.

Immers in dit geval heb je dezelfde soort persoonsgegevens in meerdere locaties, nl. tabellen met dezelfde of een deel van dezelfde gegevens in een of meerdere databases.

De vraag die dan o.a. gesteld kan worden is in welke tabel of database bevinden zich de juiste persoonsgegevens, en in welke tabel of database moet men de initieel verwerkte persoonsgegevens gaan zoeken?

Entity relationship diagrams en data normalisatie

Om te vermijden dat dezelfde (persoons)gegevens zich op meerdere ongecontroleerde locaties bevinden zou men een genormaliseerde database moeten gebruiken.

De meest gebruikte techniek om te komen tot data normalisatie is gebruik te maken van entity relationship diagrammen (ERD).

Door gebruik te maken van ERD kan men data redundanties en data afhankelijkheden gemakkelijker opmerken, en dus vermijden dat men meerdere keren hetzelfde data item registreert.

Aangezien men eenzelfde data item niet meerdere keren registreert, zal men ook minder fouten hebben in de geregistreerde data.

Minder onjuistheden in de data betekent dat er minder risico zal zijn dat er verwerkingen zullen gebeuren met onjuiste (persoons)gegevens.

Iedere (latere) verwerking zal dan immers gebeuren op een uniek data item, en bijvoorbeeld niet meer op meerdere gelijke data items in meerdere locaties.

Frondend en backend databases

Wat indien een database toch genormaliseerd is, maar men bijvoorbeeld om veiligheidsredenen een architectuur heeft van frontend en backend databases?

Sommige organisaties maken gebruik van een systeem van frontend en backend databases.

Hierbij is de backend database de database waar de medewerkers, bijvoorbeeld de loket bedienden, de gegevens van de klanden in registreren, terwijl de frontend database of databases dienen om gegevens uit te halen voor de frontend applicaties die door de klanten kunnen worden gebruikt; in het kader van self service voor de klanten.

Dergelijke frontend databases zijn in de praktijk doorgaans datamarts, die een beperkt aantal gegevens van de backend database bevatten. De beperking kan zich uiten in de tijd, bijvoorbeeld enkel de gegevens van de laatste 2 jaren, of in scope.

Op geregelde tijdstippen worden frontend en backend databases dan gesynchroniseerd. Hierbij kunnen soms miljoenen records worden bijgewerkt, zowel van de backend database naar de frontend databases als vice-versa.

Bij een dergelijke continue of dagelijkse synchronisatie kan het voorkomen dat sommige records niet of niet volledig werden gesynchroniseerd, met als gevolg dat het kan voorkomen dat sommige (persoons)gegevens tijdelijk onjuist zullen zijn.

Een mogelijke remedie richting de betrokkene wiens persoonsgegevens worden verwerkt is dit te vermelden in de gebruikersovereenkomst en iedere geregistreerde betrokkene deze overeenkomst formeel te laten aanvaarden. Helaas gebeurt dit spijtig genoeg ook niet altijd.

Bloep, 19 november 2025.