Klantportaal beveiligen: checklist voor rollen, logging en AVG

Een veilig klantportaal rust op vier afspraken: rechten per rol die op de server worden afgedwongen, logging van wat er gebeurt, een verwerkersovereenkomst met elke partij die als verwerker persoonsgegevens voor jou verwerkt, en een plan voor als er toch een datalek is. Deze checklist is geschreven voor de opdrachtgever, niet voor de programmeur. Je leest wat de AVG en OWASP zeggen, wat je kunt vragen en hoe je de antwoorden controleert. Dit is algemene informatie en geen juridisch advies. Voor jouw situatie raadpleeg je een jurist of functionaris gegevensbescherming.

Welke gegevens staan in een klantportaal?

Het NCSC wijst erop dat veel webapplicaties persoonsgegevens of andere gevoelige informatie verwerken, en een klantportaal is daar een duidelijk voorbeeld van. Denk aan namen en adressen, facturen, documenten, berichten en soms dossiers. Daarmee is beveiliging geen technische bijzaak maar een voorwaarde voor het gebruik. De AVG spreekt over de verwerkingsverantwoordelijke en de verwerker, en artikel 28 regelt hun onderlinge verhouding. Voor je aan beveiligingsmaatregelen begint, maak je daarom eerst een overzicht: welke gegevens staan in het portaal, van wie, en wie heeft er toegang toe? Wil je een klantportaal laten bouwen, neem dit overzicht dan mee in de offerteronde.

Drie beginselen uit artikel 5 AVG helpen bij het maken van dat overzicht. Persoonsgegevens moeten minimaal worden verwerkt, dus je vraagt alleen wat je nodig hebt. Ze mogen niet langer identificeerbaar worden bewaard dan nodig is, dus je bepaalt een bewaartermijn. En ze moeten zo worden verwerkt dat een passende beveiliging gewaarborgd is, door passende technische of organisatorische maatregelen. Daarbij komt artikel 5 lid 2: de verwerkingsverantwoordelijke is verantwoordelijk voor de naleving en kan die aantonen. Leg dus vast wat je hebt besloten, zodat je het kunt laten zien.

Rollen en rechten: wie mag wat zien?

Volgens OWASP blijft Broken Access Control per 11 oktober 2026 in de OWASP Top 10:2025 op nummer 1 staan als het ernstigste applicatiebeveiligingsrisico. Voor een portaal komt het naar onze uitleg neer op rechten per rol. Een klant ziet alleen zijn eigen gegevens. Een medewerker ziet wat bij zijn taak hoort. Een beheerder kan gebruikers en instellingen beheren. Ons advies: laat die rechten op de server controleren, bij elk verzoek, en niet alleen in het scherm door knoppen te verbergen. Vraag je bouwer hoe dat is opgezet en of er tests zijn waarin een klant probeert gegevens van een andere klant op te vragen.

Maak samen met je bouwer een rolmatrix: rollen in de rijen, functies in de kolommen en een vinkje waar het mag. Begin bij het laagste recht en geef alleen extra rechten als daar een reden voor is. Over koppelingen schrijft OWASP in de API Security Top 10 dat objectniveau-autorisatiecontroles moeten worden overwogen in elke functie die via een ID van de gebruiker bij een databron komt. Meer daarover staat in het artikel over API-beveiliging. Vraag ook wat er gebeurt als een medewerker vertrekt: wie trekt de rechten in en hoe snel?

Wat moet worden gelogd en wie kijkt mee?

Security Logging and Alerting Failures staat als categorie A09:2025 in de OWASP Top 10:2025. Voor een portaal betekent het dat de applicatie bijhoudt wat er gebeurt en dat iemand een melding krijgt bij verdacht gedrag. Zonder logboek kun je na een incident niet vaststellen wat er is gezien of veranderd, en dat maakt het beoordelen van een datalek moeilijk. Vraag je bouwer welke gebeurtenissen worden vastgelegd, waar het logboek staat, wie er toegang toe heeft en of een melding naar een persoon gaat. Een logboek dat niemand leest, beschermt niets.

Welke gebeurtenissen horen in het logboek? Dat is een keuze per portaal, maar denk aan geslaagde en mislukte inlogpogingen, wijzigingen in rechten, het inzien of downloaden van gevoelige documenten, het aanpassen van betaalgegevens en het verwijderen van gegevens. OWASP adviseert in de Authentication Cheat Sheet een extra laag verificatie voor gevoelige acties, en naar ons idee horen die acties ook in het logboek. Een logboek kan zelf persoonsgegevens bevatten. Is dat zo, dan gelden de beginselen uit artikel 5 AVG ook daar: leg een bewaartermijn vast en beperk wie het mag inzien. Schrijf geen wachtwoorden of volledige documenten in het logboek.

Wat regelt een verwerkersovereenkomst volgens artikel 28 AVG?

Artikel 28 AVG gaat over verwerkers. Volgens lid 1 doet de verwerkingsverantwoordelijke uitsluitend een beroep op verwerkers die afdoende garanties bieden voor passende technische en organisatorische maatregelen. Volgens lid 3 wordt de verwerking door een verwerker geregeld in een overeenkomst of andere rechtshandeling, de verwerkersovereenkomst. Daarin staat onder meer dat de verwerker de persoonsgegevens uitsluitend verwerkt op basis van schriftelijke instructies van de verwerkingsverantwoordelijke. Dit is algemene informatie en geen juridisch advies. Of een partij in jouw situatie verwerker is, beoordeel je samen met een jurist.

Bij een klantportaal kun je denken aan partijen die mogelijk als verwerker optreden: de hoster, de partij die het portaal beheert, een dienst voor e-mail of berichten en eventuele andere koppelingen. Of een partij in jouw situatie verwerker is, hangt af van de afspraken en de feiten; dat is algemene uitleg met een voorbehoud. Volgens artikel 28 lid 2 neemt een verwerker geen andere verwerker in dienst zonder voorafgaande specifieke of algemene schriftelijke toestemming van de verwerkingsverantwoordelijke. Vraag je leverancier dus om een lijst van de partijen die bij het portaal betrokken zijn en laat vastleggen dat wijzigingen aan die lijst vooraf worden gemeld. Voor het aspect hosting kun je kijken naar onze hostingdienst.

Wat moet je doen bij een datalek?

Artikel 32 AVG schrijft voor dat de verwerkingsverantwoordelijke en de verwerker passende technische en organisatorische maatregelen treffen om een op het risico afgestemd beveiligingsniveau te waarborgen. Welke maatregelen in jouw geval passend zijn, hangt volgens die tekst af van het risico. Daarom is het zinvol om in de overeenkomst te verwijzen naar een benoemde maatstaf, zoals de OWASP Top 10:2025 en de Application Security Verification Standard. Dan kun je later toetsen of de afspraak is nagekomen. Zo maak je van een vage belofte een afspraak die je kunt controleren.

Een datalek is een inbreuk in verband met persoonsgegevens. Volgens artikel 33 lid 1 AVG meldt de verwerkingsverantwoordelijke het lek zonder onredelijke vertraging en, indien mogelijk, uiterlijk 72 uur nadat hij er kennis van heeft genomen bij de toezichthouder. Een melding is niet nodig als het onwaarschijnlijk is dat de inbreuk een risico voor de rechten en vrijheden van betrokkenen oplevert. Volgens lid 2 informeert de verwerker de verwerkingsverantwoordelijke zonder onredelijke vertraging zodra hij kennis heeft genomen van een inbreuk. Dit is algemene informatie en geen juridisch advies.

Welke checklist gebruik je als opdrachtgever?

Die termijn van 72 uur begint bij kennisname, dus bereid je voor voordat er iets gebeurt. Spreek met je leverancier af wie je belt, op welk nummer en hoe snel hij reageert. Bepaal intern wie beslist over een melding en wie de toezichthouder benadert. Zorg dat het logboek is te raadplegen, zodat je kunt zien wat er is gebeurd. Bewaar een korte beschrijving van elk incident, ook als je besluit niet te melden, want volgens artikel 5 lid 2 AVG moet je naleving kunnen aantonen. Oefen het één keer door, op papier. Dan weet iedereen wie wat doet.

Een checklist voor de opdrachtgever, deel één: toegang en rechten. Is er een rolmatrix en wordt die op de server afgedwongen? Is getest of een klant gegevens van een andere klant kan ophalen? Is inloggen ingericht volgens een benoemde richtlijn, zoals beschreven in het artikel over wachtwoorden en inloggen veilig bouwen? Wordt voor gevoelige acties extra verificatie gevraagd? Is er een procedure voor het intrekken van rechten bij vertrek? Worden alleen de gegevens verzameld die nodig zijn, en is er een bewaartermijn vastgelegd? Noteer per vraag wie het antwoord geeft en wanneer.

Waar vraag je je bouwer naar?

Deel twee: afspraken en incidenten. Is er een verwerkersovereenkomst met de bouwer, de hoster en elke andere partij die persoonsgegevens verwerkt? Is er een lijst van subverwerkers en een afspraak dat wijzigingen vooraf worden gemeld? Welke gebeurtenissen worden gelogd, hoe lang worden logs bewaard en wie krijgt een melding bij verdacht gedrag? Wie meldt een datalek aan wie, en binnen welke termijn? Welke maatstaf geldt voor de beveiliging, met welke editie? Wie is verantwoordelijk voor updates na oplevering? Laat de antwoorden schriftelijk vastleggen en plan een herhaling bij grote wijzigingen.

Digitaalnu bouwt klantportalen als webapplicatie tegen een vaste prijs, vanaf €2.000 per project. De code en de data zijn voor 100% van jou, dus je kunt het portaal later door een andere partij laten beoordelen of beheren. Neem deze checklist mee naar de intake. Wat een klantportaal kost en of SaaS of maatwerk bij je past, reken je door in wat een klantportaal kost. En de tien grote risico's lees je in de OWASP Top 10 uitgelegd.

Laatst bijgewerkt op 11 oktober 2026