Een klantenportaal, een planningstool, een systeem voor offertes of personeelsdossiers: vrijwel elke bedrijfsapplicatie verwerkt persoonsgegevens. Namen, e-mailadressen, telefoonnummers, soms zelfs gevoelige informatie. Daarmee valt die software onder de Algemene verordening gegevensbescherming (AVG). Veel ondernemers zien privacy als iets juridisch: een privacyverklaring op de website en een paar overeenkomsten in een map. Maar de AVG vraagt ook iets van de software zelf.
In artikel 25 van de AVG staat het principe "gegevensbescherming door ontwerp en door standaardinstellingen", beter bekend als privacy by design en privacy by default. In dit artikel lees je wat dat in de praktijk betekent voor maatwerksoftware, welke keuzes je al tijdens de bouw maakt, en waarom het achteraf inbouwen van privacy vaak duurder uitvalt.
Wat betekent privacy by design eigenlijk?
Privacy by design betekent dat je bescherming van persoonsgegevens vanaf het eerste ontwerp meeneemt, in plaats van het er achteraf aan vast te plakken. Privacy by default betekent dat de standaardinstellingen van je applicatie zo privacyvriendelijk mogelijk zijn: er wordt niet meer verzameld, getoond of bewaard dan nodig is, tenzij iemand daar bewust voor kiest.
Dat klinkt abstract, maar het vertaalt zich naar heel concrete ontwerpbeslissingen. Welke velden heeft een formulier? Wie mag welke gegevens zien? Hoe lang blijft een record bestaan? Wat gebeurt er als een klant vraagt om verwijdering? Hoe eerder je die vragen beantwoordt, hoe makkelijker en goedkoper het is om ze goed op te lossen.
Zes principes die je in je software terugziet
1. Dataminimalisatie: verzamel alleen wat nodig is
De makkelijkste gegevens om te beschermen zijn gegevens die je niet hebt. Vraag bij elk veld in je applicatie: waarvoor hebben we dit nodig? Een geboortedatum "omdat het handig kan zijn" is geen goede reden. Minder data betekent minder risico bij een lek, minder werk bij inzageverzoeken en een overzichtelijker systeem.
2. Toegang op basis van rollen
Niet iedere medewerker hoeft alles te zien. Een planner heeft andere informatie nodig dan iemand van de financiële administratie. Met een goed doordacht rollen- en rechtensysteem bepaal je per rol welke gegevens zichtbaar en bewerkbaar zijn. Combineer dat met sterke authenticatie; in Multifactor-authenticatie voor het MKB lees je waarom dat zo'n groot verschil maakt.
3. Bewaartermijnen die automatisch worden nageleefd
De AVG schrijft voor dat je persoonsgegevens niet langer bewaart dan nodig. In veel systemen blijft data echter eindeloos staan, simpelweg omdat niemand het opruimt. In maatwerksoftware kun je bewaartermijnen vastleggen en automatisch laten uitvoeren: oude sollicitaties worden na een bepaalde periode verwijderd, inactieve accounts worden geanonimiseerd. Zo wordt het beleid geen papieren afspraak, maar iets wat de software zelf bewaakt.
4. Rechten van betrokkenen ondersteunen
Personen van wie je gegevens verwerkt, hebben onder meer recht op inzage, correctie, verwijdering en dataportabiliteit. Als je software daar niet op is ingericht, betekent elk verzoek handwerk: zoeken in tabellen, exportjes maken en hopen dat je niets vergeet. Een applicatie die is ontworpen met deze rechten in gedachten, kan bijvoorbeeld met een paar klikken alle gegevens van één persoon exporteren of verwijderen, inclusief gekoppelde records.
5. Beveiliging als vast onderdeel
Artikel 32 van de AVG vraagt om "passende technische en organisatorische maatregelen". Voor software betekent dat onder andere: versleutelde verbindingen, veilig opgeslagen wachtwoorden, versleuteling van gevoelige gegevens, regelmatige updates van frameworks en libraries, en het testen op bekende kwetsbaarheden. Denk ook aan logging: wie heeft wanneer welke gegevens bekeken of gewijzigd? Een audit trail helpt je bij een incident om snel te achterhalen wat er is gebeurd.
6. Pseudonimisering waar het kan
Niet elk onderdeel van je applicatie heeft herleidbare gegevens nodig. Voor rapportages, statistieken of test- en ontwikkelomgevingen kun je vaak werken met gepseudonimiseerde of geanonimiseerde data. Vooral dat laatste wordt nog vaak vergeten: een kopie van de productiedatabase op de laptop van een ontwikkelaar is een onnodig risico.
Waarom achteraf inbouwen duurder is
Privacy toevoegen aan een bestaande applicatie is vaak een flinke klus. Als gegevens van één klant verspreid staan over tientallen tabellen zonder duidelijke relaties, wordt een verwijderverzoek ingewikkeld. Als iedere gebruiker altijd alles heeft kunnen zien, moet je een rechtenstructuur invoeren in een systeem dat daar nooit op is gebouwd. En als er geen logging is, kun je bij een datalek moeilijk vaststellen welke gegevens zijn getroffen.
Dat laatste is extra relevant, omdat je een datalek in veel gevallen binnen 72 uur na ontdekking moet melden bij de Autoriteit Persoonsgegevens. Hoe beter je software inzicht geeft in wat er is gebeurd, hoe beter je die verplichting kunt nakomen. Een goed ingericht herstelplan hoort daar ook bij; lees daarover meer in Back-ups zijn niet genoeg.
Vergeet de organisatorische kant niet
Software is maar één deel van het verhaal. Een paar zaken die je naast de techniek goed moet regelen:
- Verwerkersovereenkomsten: laat je software bouwen, hosten of beheren door een externe partij die toegang heeft tot persoonsgegevens, dan sluit je met die partij een verwerkersovereenkomst.
- Register van verwerkingen: leg vast welke persoonsgegevens je verwerkt, met welk doel en hoe lang je ze bewaart. Dat overzicht helpt ook bij het ontwerp van je software.
- Externe diensten en koppelingen: elke koppeling met een extern systeem, zoals een mailingtool of analysedienst, is een plek waar gegevens naartoe stromen. Weet welke data je deelt en waar die terechtkomt.
- Bewustzijn bij medewerkers: de beste technische maatregelen helpen weinig als gegevens via een spreadsheet in iemands mailbox belanden.
Wil je weten hoe het eigendom en de afspraken rondom je software zijn geregeld? Lees dan ook Je hebt een app laten bouwen. Maar van wie is die eigenlijk?
Tot slot
Privacy by design is geen extra laag die je er aan het eind op legt, maar een manier van bouwen. Door vanaf het begin na te denken over welke gegevens je verwerkt, wie erbij kan en hoe lang je ze bewaart, voorkom je later dure aanpassingen en sta je sterker als er een vraag of incident komt. Bovendien levert het vaak een overzichtelijkere en beter onderhoudbare applicatie op.
Let wel: dit artikel is geen juridisch advies. Voor de precieze verplichtingen die voor jouw organisatie gelden, kun je het beste een privacyjurist of je functionaris gegevensbescherming raadplegen.
Bij CodeBros nemen we privacy en security vanaf het eerste ontwerp mee in de maatwerksoftware die we bouwen, en helpen we bestaande applicaties stap voor stap te verbeteren via applicatiebeheer en doorontwikkeling. Benieuwd hoe jouw applicatie ervoor staat? Neem vrijblijvend contact met ons op, dan kijken we samen waar de kansen en risico's liggen.