Wat het Privacyconvenant en het Normenkader IBP van je onderwijssoftware vragen.

Welke regels gelden er voor onderwijssoftware?

Wie software bouwt voor scholen ontdekt vroeg of laat dat de AVG maar het halve verhaal is. Het onderwijs heeft een eigen stelsel van afspraken opgetuigd: een convenant met modelcontracten, een pseudoniem voor leerlingen, een normenkader voor besturen en een koppelvlakstandaard voor het berichtenverkeer. Ze zijn allemaal onderling verweven, ze hebben allemaal hun eigen versienummer, en ze komen alle vier terug in de vragenlijst die een schoolbestuur je stuurt voordat er een handtekening onder een contract gaat.

Hieronder loop ik de vier langs: wat ze zijn, wie ze bindt, en — belangrijker — wat ze concreet betekenen voor de architectuur van je applicatie.

Het Privacyconvenant 4.0: de contractlaag

Het Privacyconvenant Digitale Onderwijsmiddelen en Privacy is een afspraak tussen sectorraden en leveranciers over hoe je met leerlinggegevens omgaat. De actuele versie is 4.0. Het convenant is geen wet, maar functioneert wel als toegangseis: schoolbesturen controleren of je in het openbare deelnemersregister staat en gebruiken standaard de bijbehorende modelverwerkersovereenkomst.

Wat er in het pakket zit

• De modelverwerkersovereenkomst 4.0: het juridische raamwerk tussen school (verwerkingsverantwoordelijke) en leverancier (verwerker).
• Bijlage 1 — de privacybijsluiter: per product beschrijf je welke persoonsgegevens je verwerkt, met welk doel, en hoe lang je ze bewaart. Dit is het document waar de meeste leveranciers op vastlopen, omdat het dwingt tot een eerlijke inventarisatie van je datamodel.
• Bijlage 2 — beveiligingsbijlage: de technische en organisatorische maatregelen, gekoppeld aan een classificatie.
• Bijlage 3 — de wijzigingsbijlage: nieuw in 4.0. Wijk je af van het model, dan leg je dat hier vast, met onderbouwing. Stilzwijgend afwijken kan niet meer.
• Bijlage 4 — subverwerkers: de lijst van partijen die jij inschakelt, inclusief vestigingsland.

Versie 4.0 stelt ook strengere eisen aan doorgifte buiten de EER: standard contractual clauses alleen zijn niet genoeg, je moet aantonen dat het beschermingsniveau gelijkwaardig blijft. Voor doorlopende product- of dienstenovereenkomsten gold 1 augustus 2026 als uiterste datum om over te stappen op versie 4.0. Die datum is inmiddels gepasseerd — draai je nog op een 3.0-overeenkomst, dan is dat het eerste wat je bij je volgende contractronde tegenkomt.

De privacybijsluiter is geen formulier dat je invult nadat de software af is. Als je hem eerlijk invult, is hij een ontwerpdocument.

Wat dit van je software vraagt

De bijsluiter dwingt je om per gegeven een doel en een bewaartermijn te benoemen. Dat betekent dat je bewaartermijnen ook echt moet kunnen uitvoeren: een deleted_at-kolom die niets opruimt telt niet. Bouw verwijderroutines die aantoonbaar draaien, en log dat ze gedraaid hebben. Dezelfde logica geldt voor het recht op inzage: als een ouder vraagt welke gegevens je van een leerling hebt, moet dat een query zijn en geen archeologische expeditie door zes tabellen.

Het ECK iD: identificeren zonder persoonsgegevens

In de leermiddelenketen moeten scholen, distributeurs en uitgevers weten dat een licentie bij dezelfde leerling hoort — zonder dat iedereen naam, geboortedatum en klas doorgeeft. Daarvoor bestaat het ECK iD: een ketenpseudoniem dat door de Nummervoorziening van Kennisnet wordt afgeleid uit het persoonsgebonden nummer van de leerling.

Het idee is elegant: het pseudoniem is stabiel genoeg om een leerling door de keten te volgen, en betekenisloos genoeg om buiten die keten niets prijs te geven. Maar er hangt een aantal harde eisen aan.

• Versleuteld opslaan: het ECK iD is zelf een persoonsgegeven en hoort niet in platte tekst in je database.
• Logisch gescheiden houden: bewaar het niet in dezelfde tabel als de identificerende gegevens die je juist wilde vermijden. Anders heb je het pseudoniem net zo hard weer aan een naam gekoppeld.
• Niet hergebruiken buiten de keten: het pseudoniem is bedoeld voor de leermiddelenketen, niet als universele klantsleutel in je hele portfolio.
• Niet loggen: pseudoniemen die in applicatielogs of foutmeldingen belanden, lekken alsnog naar plekken waar je ze niet wilt hebben.

Dat laatste punt onderschatten teams stelselmatig. Een pseudoniem in een debug-log is nog steeds een persoonsgegeven op een plek zonder bewaartermijn. Dit is precies waar een doordacht audit trail-ontwerp zich terugbetaalt: je legt vast wíé wat deed, zonder de gegevens zelf te dupliceren.

Het Normenkader IBP: wat je schoolklant van jou gaat vragen

Het Normenkader informatiebeveiliging en privacy voor het onderwijs legt voor alle scholen in het primair, voortgezet en speciaal onderwijs dezelfde eisen vast. Het is opgebouwd rond volwassenheidsniveaus, met een Groeipad in vijf fasen om daar stap voor stap te komen.

De tijdlijn is concreet. Schoolbesturen doen in 2026 een zelfevaluatie (nulmeting) en maken op basis daarvan een plan om eind 2029 volwassenheidsniveau 3 te halen; vanaf 1 januari 2027 moeten zij uitleg kunnen geven over hun voortgang.

Formeel bindt dit besturen, niet leveranciers. Praktisch werkt het anders. Een bestuur dat zijn voortgang moet verantwoorden, kan dat alleen als de systemen die het inkoopt meewerken. De normen over toegangsbeheer, logging, classificatie van systemen en leveranciersafspraken landen daardoor rechtstreeks in jouw backlog.

De vier vragen die altijd terugkomen

1. Toegangsbeheer: ondersteun je rolgebaseerde rechten, en kan een school zelf rollen inrichten zonder tussenkomst van jouw supportafdeling?
2. Sterke authenticatie: ondersteun je single sign-on via de identiteitsvoorzieningen die de school al gebruikt, en tweefactorauthenticatie voor beheerdersrollen?
3. Logging: kan de school zien wie welke leerlinggegevens heeft ingezien, en hoe lang bewaar je die logs?
4. Classificatie: welke classificatie heeft jouw applicatie, en op basis waarvan?

Die laatste vraag is de brug naar de volgende laag.

Edukoppeling en het Certificeringsschema IBP ROSA

Waar het normenkader over de organisatie gaat, gaat Edukoppeling over het berichtenverkeer. Het is de sectorstandaard voor geautomatiseerde uitwisseling van gesloten gegevens tussen informatiesystemen van onderwijsorganisaties, uitvoeringsorganisaties en leveranciers. De standaard beschrijft de transportlaag — niet de inhoud van de berichten.

Er zit beweging in. De conceptversie van juni 2026 verlegt het zwaartepunt van SOAP-webservices naar RESTful APIs met een OAuth 2.0 client credentials-profiel, kent twee risicoprofielen (laag en hoog) voor clientauthenticatie, en voegt een CloudEvents-profiel toe voor asynchrone, gebeurtenisgedreven uitwisseling. Het oude WUS-profiel wordt niet meer ondersteund. Bouw je nu een nieuwe koppeling, kijk dan naar de REST-kant — ook al is de laatst vastgestelde versie nog de oudere.

Daaraan gekoppeld zit het Certificeringsschema informatiebeveiliging en privacy ROSA, sinds versie 4.0 (december 2025) de basislijn voor applicaties in de keten. Het werkt met een BIV-classificatie: je bepaalt per applicatie het vereiste niveau voor beschikbaarheid, integriteit en vertrouwelijkheid, en die drie scores bepalen samen welke maatregelen je moet kunnen aantonen. Het schema is verplicht voor het primair, voortgezet en middelbaar beroepsonderwijs, en sinds 29 juni 2026 aanbevolen voor het hoger onderwijs.

Classificeren is geen papierwerk achteraf. Een applicatie die op vertrouwelijkheid hoog scoort, vraagt om andere keuzes in je datamodel dan een die dat niet doet.

Waar het in je architectuur landt

Vier regimes, één codebase. Als je ze uit elkaar trekt naar concrete bouwstenen, blijft er een lijst over die je vanaf dag één kunt meenemen:

• Doelbinding in het datamodel: elk veld heeft een doel en een bewaartermijn, en die termijn wordt uitgevoerd door een taak die je kunt aantonen.
• Pseudonimisering als eerste keuze: het ECK iD versleuteld en apart, identificerende gegevens alleen waar ze functioneel nodig zijn.
• Rolgebaseerde toegang die de school zelf beheert: anders wordt elke personeelsmutatie een supportticket, en dat haalt geen enkele audit.
• Single sign-on op de identiteitsvoorziening van de school: minder wachtwoorden in omloop is zowel een beveiligings- als een gebruiksargument. Zie ook identity- en accessmanagement.
• Toegangslogging met een eigen bewaartermijn: wie zag welk leerlingdossier, en wanneer.
• Subverwerkers in beeld: elke externe dienst die je aanroept staat in bijlage 4, inclusief regio. Dat maakt de keuze voor hosting binnen de EU een ontwerpbeslissing en geen detail.
• API-koppelingen langs de standaard: OAuth 2.0, nette scopes, en berichten die passen bij de afspraken in de keten.

Mijn kijk op onderwijssoftware en compliance

Het onderwijs krijgt vaak het verwijt dat het te veel regelt. Ik zie het anders. De sector heeft precies dat gedaan wat andere sectoren nalaten: de open normen van de AVG vertaald naar modelcontracten, een werkend pseudoniem en een gedeelde standaard voor gegevensuitwisseling. Dat scheelt elke leverancier een eigen juridische uitvinding per klant.

Wat me wel opvalt, is waar het misgaat. Bijna nooit bij de grote dingen — versleuteling, back-ups, toegangsrechten — die zitten meestal wel goed. Het gaat mis bij de kleine, saaie dingen: een exportfunctie die net iets te veel meeneemt, een logregel met een leerlingnummer erin, een bewaartermijn die op papier staat maar nergens wordt afgedwongen. Dat zijn geen beveiligingsfouten, dat zijn ontwerpfouten. En ze zijn achteraf duurder te repareren dan vooraf te voorkomen.

Mijn advies aan iedereen die met onderwijssoftware begint: vul de privacybijsluiter in vóórdat je bouwt. Niet omdat het moet, maar omdat het je datamodel scherper maakt. Elk veld waarvan je het doel niet kunt opschrijven, hoort er waarschijnlijk niet te staan.

— Jasper

Zo helpt Coding Agency hierbij

Wij bouwen maatwerkapplicaties voor organisaties met zware eisen aan privacy en gegevensuitwisseling — van leerling- en ouderportalen tot koppelingen met administratiesystemen. Dat betekent in de praktijk: doelbinding en bewaartermijnen in het datamodel, pseudonimisering waar het kan, AVG-vereisten die daadwerkelijk zijn uitgevoerd in plaats van beschreven, en koppelingen die aansluiten op de standaarden van de keten. De aanpak lijkt sterk op wat we doen voor zorgsoftware en voor gemeenten: eerst het regime helder, dan pas de architectuur.

Twijfel je of je huidige applicatie de vragenlijst van een schoolbestuur doorstaat, of sta je aan het begin van een nieuw traject? Neem contact op voor een vrijblijvend gesprek.

Bronnen: Privacyconvenant Onderwijs (privacyconvenant.nl), Normenkader IBP (Kennisnet) en Edustandaard.