Hoe waarborg je de AVG-compliance bij maatwerksoftware voor scholen?

AVG-compliance bij maatwerksoftware voor scholen vraagt om meer dan een checkbox-aanpak. Je moet zorgen voor een verwerkersovereenkomst met je softwareontwikkelaar, privacy by design toepassen vanaf dag één, en een DPIA uitvoeren zodra je grootschalig persoonsgegevens van leerlingen verwerkt. Scholen zijn wettelijk verantwoordelijk voor de gegevens die via hun software stromen, ook als die software extern is gebouwd. In dit artikel krijg je per vraag een concreet antwoord.

Wat houdt AVG-compliance in voor scholen?

AVG-compliance voor scholen betekent dat je als onderwijsinstelling voldoet aan de Algemene Verordening Gegevensbescherming bij het verwerken van persoonsgegevens van leerlingen, ouders en medewerkers. Je bent als school de verwerkingsverantwoordelijke: jij bepaalt het doel en de middelen van de gegevensverwerking, en jij draagt de juridische verantwoordelijkheid.

In de praktijk gaat dat om een aantal concrete verplichtingen:

• Je verwerkt alleen gegevens die je echt nodig hebt voor een bepaald doel (dataminimalisatie)
• Je informeert betrokkenen over hoe je hun gegevens gebruikt
• Je sluit verwerkersovereenkomsten af met alle partijen die namens jou gegevens verwerken
• Je documenteert je verwerkingen in een verwerkingsregister
• Je reageert tijdig op verzoeken van betrokkenen, zoals inzage- of verwijderingsverzoeken

Leerlinggegevens vallen onder bijzonder gevoelige informatie. Denk aan gezondheidsgegevens, ondersteuningsbehoeften of gedragsregistraties. Die categorie vraagt extra zorgvuldigheid en soms een aanvullende juridische grondslag.

Waarom is maatwerksoftware een groter AVG-risico dan standaardsoftware?

Maatwerksoftware voor het onderwijs brengt meer AVG-risico met zich mee dan standaardsoftware omdat de school zelf mede bepaalt hoe de applicatie wordt gebouwd, welke gegevens erin zitten en hoe die worden opgeslagen. Bij standaardsoftware van een grote leverancier is de compliance-documentatie al grotendeels aanwezig. Bij maatwerk bouw je die vanaf de grond op.

Dat heeft een aantal concrete gevolgen. De technische en organisatorische beveiligingsmaatregelen moeten bewust worden ontworpen, niet automatisch overgenomen. Toegangsbeheer, logging, versleuteling en dataretentie zijn keuzes die jij en je ontwikkelaar samen maken. Als die keuzes niet goed worden gedocumenteerd, ontstaat er een grijs gebied dat toezichthouders zoals de Autoriteit Persoonsgegevens niet waarderen.

Bovendien is maatwerksoftware vaker flexibel uitbreidbaar, wat betekent dat er in de loop van de tijd nieuwe verwerkingen kunnen ontstaan zonder dat iemand opnieuw de AVG-check doet. Dat vraagt om een actief beheerproces, niet alleen een eenmalige beoordeling bij de livegang.

Welke AVG-eisen gelden specifiek voor softwareontwikkelaars in het onderwijs?

Een softwareontwikkelaar die maatwerk bouwt voor een school treedt op als verwerker in de zin van de AVG. Dat betekent dat de ontwikkelaar uitsluitend handelt op basis van de instructies van de school en zelf geen eigen doeleinden mag nastreven met de gegevens. De ontwikkelaar is verplicht passende technische en organisatorische maatregelen te treffen om de gegevens te beveiligen.

Specifiek voor het onderwijs gelden ook de afspraken uit het Convenant Digitale Onderwijsmiddelen en Privacy (NDPA). Hoewel dit convenant primair gericht is op educatieve applicaties, geeft het een goede indicatie van wat scholen verwachten van hun leveranciers: transparantie over subverwerkers, geen gebruik van leerlingdata voor commerciële doeleinden, en duidelijke afspraken over dataverwijdering na afloop van de samenwerking.

Praktisch gezien moet een ontwikkelaar aantoonbaar kunnen maken dat:

• Gegevens versleuteld worden opgeslagen en verzonden
• Toegang tot productiedata beperkt is tot geautoriseerde personen
• Er een procedure is voor het melden van datalekken
• Subverwerkers (zoals hostingpartijen) ook AVG-compliant zijn

Hoe zorg je voor privacy by design bij maatwerksoftware?

Privacy by design betekent dat je privacybescherming inbouwt in de architectuur van de software, niet er achteraf aan toevoegt. Bij maatwerksoftware voor het onderwijs doe je dat door al in de ontwerpfase te bepalen welke gegevens je echt nodig hebt, hoe lang je ze bewaart, wie er toegang toe heeft en hoe je ze beveiligt.

Concrete stappen om privacy by design te realiseren:

1. Dataminimalisatie in het ontwerp: Vraag jezelf bij elk dataveld af waarom je dit gegeven nodig hebt. Als je het niet kunt beantwoorden, laat het dan weg.
2. Rolgebaseerde toegang: Zorg dat gebruikers alleen de gegevens zien die ze voor hun functie nodig hebben. Een administratief medewerker hoeft geen medische gegevens te zien.
3. Standaard privacyvriendelijke instellingen: Privacy by default betekent dat de meest privacyvriendelijke instelling de standaard is, niet een optie die je apart moet aanzetten.
4. Pseudonimisering waar mogelijk: Gebruik technische ID's in plaats van namen waar dat kan, zodat een datalek minder schade aanricht.
5. Bewaar- en verwijdertermijnen automatiseren: Bouw in dat gegevens na een bepaalde periode automatisch worden gearchiveerd of verwijderd.

Privacy by design is geen eenmalige actie. Elke nieuwe feature of uitbreiding van de software vraagt opnieuw om deze afweging.

Wat moet er in een verwerkersovereenkomst met een softwareontwikkelaar staan?

Een verwerkersovereenkomst met een softwareontwikkelaar moet minimaal de volgende elementen bevatten: het onderwerp en de duur van de verwerking, de aard en het doel van de verwerking, het soort persoonsgegevens en de categorieën betrokkenen, en de rechten en verplichtingen van de school als verwerkingsverantwoordelijke.

Naast deze wettelijke minimumvereisten zijn er een aantal afspraken die in de praktijk veel discussie voorkomen:

• Subverwerkers: Leg vast welke subverwerkers de ontwikkelaar mag inschakelen en dat de school hiervoor toestemming geeft. Denk aan hostingproviders of clouddiensten.
• Doorgifte buiten de EER: Maak afspraken over of en hoe gegevens buiten de Europese Economische Ruimte worden opgeslagen of verwerkt.
• Beveiligingsmaatregelen: Beschrijf welke technische en organisatorische maatregelen de ontwikkelaar treft.
• Meldplicht datalekken: Spreek af dat de ontwikkelaar een datalek binnen 24 tot 48 uur meldt aan de school, zodat de school op tijd kan voldoen aan de 72-uurstermijn richting de Autoriteit Persoonsgegevens.
• Auditrecht: Leg vast dat de school het recht heeft om de naleving te controleren of een audit te laten uitvoeren.
• Dataverwijdering na afloop: Spreek af wat er met de gegevens gebeurt als de samenwerking eindigt.

Hoe ga je om met datalekken in maatwerksoftware voor scholen?

Bij een datalek in maatwerksoftware voor scholen moet je als school binnen 72 uur na ontdekking een melding doen bij de Autoriteit Persoonsgegevens, tenzij het lek waarschijnlijk geen risico oplevert voor betrokkenen. Als het lek een hoog risico oplevert, moet je ook de betrokkenen zelf informeren, zoals leerlingen of ouders.

Een goede voorbereiding op datalekken bestaat uit drie onderdelen:

1. Detectie: Zorg dat de software logging en monitoring heeft, zodat je een lek snel ontdekt. Zonder detectiemechanisme weet je niet wat er gebeurt.
2. Respons: Stel een intern protocol op. Wie belt wie? Wie neemt de beslissing om te melden? Wie communiceert naar betrokkenen?
3. Documentatie: Documenteer elk incident, ook als je besluit het niet te melden. De AVG verplicht je om alle datalekken intern te registreren.

Spreek in de verwerkersovereenkomst af dat de ontwikkelaar je binnen 24 tot 48 uur informeert bij een vermoeden van een lek. Die marge heb je nodig om zelf tijdig te kunnen handelen.

Wanneer is een gegevensbeschermingseffectbeoordeling (DPIA) verplicht?

Een DPIA is verplicht als de verwerking van persoonsgegevens waarschijnlijk een hoog risico oplevert voor de betrokkenen. Voor maatwerksoftware in het onderwijs is dat al snel het geval: je verwerkt gegevens van kinderen, vaak op grote schaal, en soms gaat het om gevoelige categorieën zoals ondersteuningsbehoeften of gedragsgegevens.

De Autoriteit Persoonsgegevens heeft een lijst gepubliceerd van verwerkingen waarvoor een DPIA verplicht is. Voor scholen zijn met name relevant:

• Grootschalige verwerking van bijzondere persoonsgegevens (zoals gezondheidsgegevens of gegevens over leerlingondersteuning)
• Stelselmatige monitoring van leerlingen, bijvoorbeeld via leerlingvolgsystemen
• Gebruik van nieuwe technologieën waarbij de risico's nog niet volledig zijn ingeschat

Een DPIA voer je uit vóór de livegang van de software, niet erna. Je brengt de risico's in kaart, beoordeelt de noodzaak en proportionaliteit van de verwerking, en beschrijft welke maatregelen je neemt om de risico's te beperken. Als de risico's na die maatregelen nog steeds hoog zijn, ben je verplicht vooraf advies te vragen aan de Autoriteit Persoonsgegevens.

Bij maatwerksoftware is de DPIA ook een nuttig instrument tijdens de ontwikkeling: het dwingt je om vroeg in het proces na te denken over welke gegevens je echt nodig hebt en hoe je die verantwoord verwerkt. Dat levert betere software op, niet alleen betere compliance. Een goede DPIA aanpak begint daarom al in de ontwerpfase, samen met een ontwikkelpartner die de AVG-vereisten kent en structureel meeneemt in het bouwproces.

Bij Corver Development helpen we organisaties in het onderwijs en de zorg om software te bouwen die van meet af aan voldoet aan de AVG-vereisten. We denken mee over de architectuur, de verwerkersovereenkomst en de DPIA, zodat je niet achteraf hoeft te repareren wat je eerder had kunnen voorkomen. Benieuwd wat wij voor jouw organisatie kunnen betekenen? Bekijk onze diensten en ontdek hoe wij samenwerken.