Een AVG-proof webapplicatie verwerkt alleen de persoonsgegevens die echt nodig zijn, beveiligt ze goed en geeft gebruikers grip op hun eigen gegevens. De Algemene verordening gegevensbescherming (AVG) verplicht je om privacy al in het ontwerp mee te nemen (privacy by design), privacyvriendelijke standaardinstellingen te kiezen (privacy by default) en afspraken vast te leggen met partijen die gegevens voor je verwerken. Wie dat vanaf het begin regelt, voorkomt dure aanpassingen achteraf.
Dit artikel geeft praktische uitleg vanuit softwareontwikkeling en is geen juridisch advies. De informatie is gecontroleerd op de website van de Autoriteit Persoonsgegevens, per oktober 2026.
Wat de Algemene verordening gegevensbescherming betekent voor je webapplicatie
De AVG geldt sinds 25 mei 2018 in de hele Europese Unie, voor iedereen die persoonsgegevens verwerkt: grote bedrijven, kleine ondernemers en de overheid. Bijna elke zakelijke webapplicatie valt eronder. Een klantportaal met namen en e-mailadressen, een planningstool met telefoonnummers van medewerkers of een contactformulier: zodra je persoonsgegevens verwerkt, gelden de regels.
Organisaties die een webapplicatie gebruiken, zijn meestal de verwerkingsverantwoordelijke: zij bepalen waarom en hoe gegevens worden verwerkt. Daarmee liggen de belangrijkste verantwoordelijkheden en verplichtingen bij jouw organisatie. Je moet niet alleen aan de regels voldoen, maar dat ook kunnen aantonen. Dat heet de verantwoordingsplicht (accountability). Software die je laat bouwen, moet je daarbij helpen in plaats van het lastiger te maken.
Persoonsgegevens verwerken volgens de beginselen van de AVG
De AVG kent zes beginselen in artikel 5, met de verantwoordingsplicht als zevende. Vertaald naar een webapplicatie:
| Beginsel | Wat het betekent in je applicatie |
|---|---|
| Rechtmatigheid en transparantie | Een grondslag voor elke verwerking en een duidelijke privacyverklaring (informatieplicht) |
| Doelbinding | Gegevens alleen gebruiken voor het doel waarvoor je ze verzamelt |
| Dataminimalisatie | Geen velden die je niet strikt noodzakelijk nodig hebt |
| Juistheid | Gebruikers kunnen hun gegevens zelf bijwerken |
| Opslagbeperking | Bewaartermijnen en automatisch verwijderen |
| Vertrouwelijkheid en integriteit | Toegangsbeheer, versleuteling en logging |
Privacy by design en privacy by default
Privacy by design (gegevensbescherming door ontwerp) staat in artikel 25 van de AVG. Volgens de Autoriteit Persoonsgegevens houdt het in dat je al bij het ontwerpen van producten en diensten zorgt dat je persoonsgegevens goed beschermt, en dat je gegevens niet langer bewaart dan nodig is voor het doel.
Privacy by default betekent dat de standaardinstellingen privacyvriendelijk zijn. Je verwerkt standaard alleen de gegevens die noodzakelijk zijn voor het specifieke doel. De AP noemt zelf voorbeelden: een app registreert geen locatie als dat niet nodig is, het vakje “Ja, ik wil aanbiedingen ontvangen” staat niet vooraf aangevinkt (opt-in in plaats van opt-out) en je vraagt bij een nieuwsbrief niet meer gegevens dan nodig.
Dataminimalisatie in de praktijk
Dataminimalisatie is de goedkoopste privacymaatregel: gegevens die je niet hebt, kunnen ook niet lekken. Stel bij elk formulier en elke databasetabel de vraag waarvoor je een gegeven nodig hebt. Een paar voorbeelden:
- Vraag geen geboortedatum als een leeftijdscheck volstaat.
- Sla geen kopie van een identiteitsbewijs op als je alleen wilt controleren wie iemand is.
- Gebruik pseudonieme ID’s in rapportages en exports, in plaats van namen.
- Leg vast hoe lang je gegevens bewaart en laat de applicatie ze daarna automatisch verwijderen of anonimiseren.
Dit soort keuzes maak je in het functioneel ontwerp, voordat de ontwikkeling begint. Achteraf inbouwen kan, maar dan moet je bestaande data opschonen en processen aanpassen.
Toestemming en tracking
Is toestemming je grondslag, bijvoorbeeld voor marketing, dan moet die vrij gegeven, specifiek en ondubbelzinnig zijn: de gebruiker doet actief iets, zoals zelf een vakje aanvinken. Bouw dat zo dat een gebruiker zijn toestemming net zo makkelijk weer kan intrekken. Wil je bijzondere persoonsgegevens verwerken, zoals gezondheidsgegevens, dan heb je zonder wettelijke basis uitdrukkelijke (expliciete) toestemming nodig, een zwaardere vorm. Wees ook kritisch op tracking en scripts van derden in je applicatie: elke externe partij die gegevens van je gebruikers ontvangt, moet passen binnen je privacybeleid. Wees daar transparant over in je privacyverklaring.
Verwerkersovereenkomst: met wie heb je er een nodig?
Schakel je een externe partij in die persoonsgegevens in jouw opdracht verwerkt, dan is die partij een verwerker. De AVG eist dan een schriftelijke verwerkersovereenkomst (artikel 28, derde lid). Ontbreekt die, dan zijn zowel jij als de verwerker in overtreding; de aansprakelijkheid ligt dan bij beide partijen.
Bij een webapplicatie heb je vaak een verwerkersovereenkomst nodig met:
- de hostingpartij of clouddienst waar de applicatie en database draaien, inclusief cloudopslag voor bestanden en back-ups;
- de ontwikkelaar of beheerpartij als die toegang heeft tot productiegegevens, bijvoorbeeld bij support of onderhoud;
- andere leveranciers die gegevens ontvangen, zoals een e-maildienst voor notificaties.
Wat staat er in een verwerkersovereenkomst voor software?
Volgens de AP leg je onder meer vast:
- onderwerp, duur, aard en doel van de verwerking en welke gegevens het betreft;
- dat de verwerker alleen op jouw schriftelijke instructies werkt en de gegevens niet voor eigen doeleinden gebruikt;
- geheimhouding en passende beveiligingsmaatregelen;
- dat subverwerkers alleen met jouw voorafgaande toestemming worden ingeschakeld;
- hulp bij verzoeken van betrokkenen, datalekken en een DPIA;
- het verwijderen of teruggeven van gegevens na afloop;
- medewerking aan audits.
Maak de afspraken concreet en herzie ze periodiek tijdens de samenwerking, zeker als de applicatie groeit of er nieuwe gegevens bijkomen. Jij blijft als verwerkingsverantwoordelijke altijd verantwoordelijk, ook als de verwerker de overeenkomst heeft opgesteld.
Hosting: waar staan je gegevens?
De AVG verplicht niet dat je data in Nederland staat. Wel gelden aparte regels voor doorgifte naar landen buiten de Europese Economische Ruimte (EER). Dat mag alleen naar landen met een passend beschermingsniveau (een adequaatheidsbesluit van de Europese Commissie), met passende waarborgen zoals een modelcontract, of op basis van specifieke uitzonderingen. Voor de Verenigde Staten gelden aparte regels.
De eenvoudigste route is daarom hosting binnen de EER, en nagaan welke subverwerkers je hostingpartij gebruikt. Let ook op back-ups, monitoringtools en e-maildiensten: die verwerken vaak ook persoonsgegevens. Meer over het kiezen van een partij lees je in ons artikel over webapplicatie hosting.
Beveiliging en logging
De AVG vraagt “passende technische en organisatorische maatregelen”. Wat passend is, hangt af van het risico: een medisch dossier vraagt zwaardere maatregelen dan een e-mailadres. Naast de AVG kunnen ook andere wetten voor jouw sector extra eisen stellen. De AP noemt onder meer autorisaties zo beperkt mogelijk houden, accounts aan één persoon koppelen, logbestanden bijhouden en die regelmatig controleren.
Voor een webapplicatie betekent dat in elk geval:
- rollen en rechten inrichten, zodat medewerkers binnen je eigen organisatie alleen zien wat ze voor hun werk nodig hebben;
- versleuteling van verbindingen en gevoelige gegevens;
- logging van wie wanneer welke persoonsgegevens heeft bekeken, gewijzigd of geëxporteerd, zonder in de logs zelf meer gegevens op te slaan dan nodig;
- back-ups en een getest herstelplan;
- een vastgelegd beveiligingsbeleid, zodat iedereen weet hoe je met gegevensbescherming omgaat.
Hoe je dat technisch aanpakt, lees je in ons artikel over beveiliging van een webapplicatie.
Rechten van betrokkenen als functies in je applicatie
Mensen van wie je gegevens verwerkt hebben onder meer recht op inzage, rectificatie, het verwijderen van gegevens, beperking van de verwerking, dataportabiliteit en bezwaar. Je moet in principe binnen 1 maand op een verzoek reageren. In uitzonderlijke gevallen mag je dat met maximaal 2 maanden verlengen, maar dat laat je dan wel binnen die eerste maand weten.
Handmatig gegevens bij elkaar zoeken uit vijf tabellen en drie systemen is foutgevoelig. Bouw het daarom als functionaliteit:
- Inzage en export: een overzicht of download van alle gegevens van één persoon, in een gangbaar formaat zoals CSV of JSON. Dat helpt ook bij dataportabiliteit.
- Correctie: gebruikers passen hun profiel zelf aan.
- Verwijderen: een beheerfunctie die gegevens van een persoon verwijdert of anonimiseert, inclusief gekoppelde bestanden, en die rekening houdt met gegevens die je wettelijk moet bewaren, zoals de administratie.
- Toestemming beheren: een plek waar gebruikers hun voorkeuren zien en intrekken.
Controleer bij een verzoek de identiteit van de aanvrager. De AP waarschuwt dat je daarvoor niet standaard een kopie van een identiteitsbewijs mag vragen; gebruik bij voorkeur gegevens die je al hebt, zoals een ingelogd account.
Datalekken melden bij de Autoriteit Persoonsgegevens
Een datalek moet je binnen 72 uur na kennisname melden bij de Autoriteit Persoonsgegevens, tenzij het niet waarschijnlijk is dat het een risico oplevert voor betrokkenen. Is er waarschijnlijk een hoog risico, dan informeer je ook de mensen zelf. Daarnaast ben je verplicht alle datalekken in een intern datalekregister vast te leggen, ook de lekken die je niet hoeft te melden.
Een goede applicatie helpt je om snel te weten wat er gebeurd is. Met logging zie je welke gegevens betrokken waren en hoeveel mensen het raakt. Spreek in de verwerkersovereenkomst af hoe snel je ontwikkelaar of hostingpartij een incident aan jou meldt, zodat jij de termijn kunt halen.
DPIA: wanneer is die verplicht?
Een data protection impact assessment (DPIA) brengt vooraf de privacyrisico’s van een verwerking in kaart. Die is verplicht als een verwerking waarschijnlijk een hoog privacyrisico oplevert. Volgens de AVG is dat in elk geval zo bij grootschalige verwerking van bijzondere persoonsgegevens, zoals gezondheidsgegevens, bij strafrechtelijke gegevens en bij het systematisch beoordelen van mensen met geautomatiseerde besluiten.
De AP heeft daarnaast een lijst van verwerkingen waarvoor een DPIA verplicht is. Staat jouw verwerking er niet op, dan gebruik je de 9 criteria van de Europese toezichthouders, zoals gevoelige gegevens, gekoppelde databases, gegevens over kwetsbare personen (bijvoorbeeld werknemers of patiënten) en nieuwe technologie. Voldoet je verwerking aan 2 of meer criteria, dan is een DPIA de vuistregel. Doe de DPIA vóór de bouw, zodat de uitkomst nog invloed heeft op het ontwerp.
Checklist: AVG en software laten bouwen
Laat je AVG-software of een maatwerk applicatie bouwen en wil je dat die compliant is? Neem deze punten mee in je project:
- Breng in kaart welke persoonsgegevens de applicatie verwerkt, met welk doel en op welke grondslag.
- Schrap velden die niet noodzakelijk zijn en leg bewaartermijnen vast.
- Bepaal of een DPIA nodig is.
- Sluit verwerkersovereenkomsten met ontwikkelaar, hostingpartij en andere leveranciers.
- Kies hosting binnen de EER of regel passende waarborgen.
- Ontwerp rollen, rechten en logging.
- Bouw functies voor inzage, export, correctie en verwijderen.
- Werk documenten als je verwerkingsregister en privacyverklaring bij.
- Leg vast hoe je een datalek signaleert, beoordeelt en meldt.
Hoe wij privacy meenemen in een maatwerk webapplicatie
Bij Inesta bespreken we privacy al in de ontwerpfase: welke gegevens zijn echt nodig, wie mag wat zien en hoe lang bewaar je het. Een NDA is bij ons standaard en de code is altijd eigendom van de klant. Wil je een maatwerk webapplicatie laten bouwen die vanaf het begin rekening houdt met de AVG? Vertel ons wat je wilt bouwen; je krijgt binnen één werkdag reactie.