Op 15 augustus 2026 is het zover. Na instemming van de Eerste Kamer treden de Cyberbeveiligingswet en de Wet weerbaarheid kritieke entiteiten in werking — de Nederlandse vertaling van de Europese NIS2-richtlijn. Grote kans dat die zin je weinig zegt, en eerlijk is eerlijk: als docent hoef je hem ook niet uit je hoofd te kennen. Maar er zit een beweging achter die het onderwijs de komende jaren wél gaat voelen, tot in de lerarenkamer aan toe. De beveiligingslat in publieke ketens gaat omhoog. En iedereen die software levert aan scholen — van het leerlingvolgsysteem tot de AI die toetsen nakijkt — gaat daar vragen over krijgen.
Dit stuk is die uitleg. Wat de wet is, voor wie hij geldt, waarom "wij zijn AVG-proof" vanaf nu een onvoldoende antwoord is, welke zes vragen je aan elke edtech-leverancier zou moeten stellen, en — omdat we vinden dat je niet over andermans huiswerk mag schrijven zonder je eigen werk te laten zien — hoe wij het bij Corrigo geregeld hebben. Het is een longread. Pak er koffie bij. Het gaat over de gegevens van jouw leerlingen, dus het mag even duren.
Wat is de Cyberbeveiligingswet eigenlijk?
Even terug naar het begin. In Europa geldt sinds een paar jaar de NIS2-richtlijn: een pakket regels dat organisaties in vitale en belangrijke sectoren verplicht hun digitale weerbaarheid serieus te nemen. Niet als vrijblijvend advies, maar als wet — met toezicht, met meldplichten en met bestuurders die er persoonlijk op aangesproken kunnen worden. Een Europese richtlijn werkt alleen niet vanzelf; elk land moet hem omzetten in eigen wetgeving. Voor Nederland is dat de Cyberbeveiligingswet, samen met de Wet weerbaarheid kritieke entiteiten. Na een langere aanloop dan gepland heeft de Eerste Kamer ingestemd, en op 15 augustus 2026 treden beide wetten in werking.
De kern van de Cyberbeveiligingswet laat zich in drie woorden samenvatten: risico’s, incidenten, verantwoordelijkheid.
Risico’s beheersen. Organisaties die onder de wet vallen, moeten aantoonbaar aan risicobeheersing doen. Niet één keer een beleidsdocument schrijven en dat in een la leggen, maar doorlopend weten waar de zwakke plekken zitten: in de eigen systemen, in de toegang van medewerkers, en — belangrijk — in de keten van leveranciers. Wie software inkoopt, koopt ook de risico’s van die software in. De wet maakt ketenbeveiliging daarmee expliciet onderdeel van je eigen huiswerk.
Incidenten melden. Ernstige incidenten moeten snel bij de toezichthouder worden gemeld — denk aan een eerste waarschuwing binnen 24 uur en een uitgebreidere melding binnen 72 uur. Dat lijkt op de datalekmeldplicht uit de AVG, maar het is breder: het gaat niet alleen om persoonsgegevens die op straat liggen, maar om elke verstoring die de dienstverlening raakt. Een ransomware-aanval die geen gegevens lekt maar wél je systemen platlegt, valt er dus ook onder.
Bestuurlijke verantwoordelijkheid. Dit is misschien wel de grootste verschuiving. Digitale veiligheid is onder de nieuwe wet geen ICT-onderwerp meer dat je kunt delegeren aan de systeembeheerder. Het bestuur moet de maatregelen goedkeuren, moet toezien op de uitvoering, en moet zelf geschoold zijn in de risico’s. Een bestuurder die het onderwerp structureel negeert, kan daar persoonlijk op worden aangesproken. Dat verandert gesprekken aan bestuurstafels — en dus ook de vragen die vanaf die tafels naar beneden komen.
Valt mijn school onder deze wet?
Nu de vraag die elke schoolleider als eerste stelt. Het eerlijke antwoord: waarschijnlijk niet rechtstreeks. De Cyberbeveiligingswet wijst sectoren aan — energie, zorg, drinkwater, digitale infrastructuur, overheid, en zo verder — en deelt organisaties daarbinnen in als essentieel of belangrijk. Het funderend onderwijs staat niet als zodanig op die lijst. Een gemiddelde middelbare school hoeft zich op 15 augustus dus niet ineens bij een toezichthouder te registreren, en een kleine edtech-leverancier evenmin.
Maar wie daaruit concludeert dat er niets verandert, leest de wet te smal. Er zijn drie routes waarlangs de lat ook voor scholen omhooggaat.
Route één: de keten. Organisaties die wél onder de wet vallen, moeten hun leveranciersrisico’s beheersen. Grote schoolbesturen, samenwerkingsverbanden, gemeenten met onderwijstaken en landelijke onderwijsorganisaties raken de wet ergens in hun keten vrijwel zeker aan. En ketenverantwoordelijkheid heeft de eigenschap dat hij naar beneden druppelt: wie zelf verantwoording moet afleggen over leveranciers, gaat die leveranciers bevragen. De inkoopvragenlijst van een groot bestuur in 2027 zal er anders uitzien dan die van 2024 — strenger, concreter, en met minder geduld voor wollige antwoorden.
Route twee: het normenkader. Het onderwijs heeft met het Normenkader Informatiebeveiliging en Privacy voor het funderend onderwijs al een eigen meetlat, ontwikkeld voor en door de sector. Scholen werken daar in groeiende mate aantoonbaar naartoe. De nieuwe wet geeft dat traject rugwind: wat eerst een ambitie was, wordt steeds meer de ondergrens die besturen van zichzelf — en dus van hun leveranciers — verwachten.
Route drie: het klimaat. Onderwijsinstellingen zijn de afgelopen jaren herhaaldelijk doelwit geweest van ransomware en datadiefstal. Elke aanval op een school of universiteit die het nieuws haalt, verschuift de norm van "beveiliging is iets voor banken" naar "beveiliging is basishygiëne". De wet is óók een codificatie van dat veranderde klimaat. Zelfs een school die nergens juridisch toe verplicht is, wil morgen niet de school zijn die er nooit naar vroeg.
Kortom: de vraag "valt mijn school eronder?" is de verkeerde vraag. De betere vraag is: welke vragen gaat mijn bestuur — of mijn ouderraad, of de journalist die belt — mij straks stellen, en kan ik ze beantwoorden?
Waarom "AVG-proof" niet meer genoeg is
Jarenlang was er in het onderwijs één toverwoord voor digitale zorgvuldigheid: AVG. Heb je een verwerkersovereenkomst? Dan zit het goed. En laten we eerlijk zijn — die reflex was begrijpelijk. De AVG was nieuw, groot en beladen met boetes, dus daar ging alle aandacht naartoe.
Maar de AVG en de Cyberbeveiligingswet beantwoorden verschillende vragen. De AVG vraagt: mág je deze persoonsgegevens verwerken, waarvoor, en zijn de rechten van leerlingen en ouders geborgd? De Cyberbeveiligingswet vraagt: is de organisatie die dat doet bestand tegen aanvallen en storingen — en kan ze dat aantonen? Dat is niet hetzelfde. Een tool kan een juridisch waterdichte verwerkersovereenkomst hebben en tóch draaien op een server waar het wachtwoord van de beheerder "welkom2024" is. Papier beschermt geen databases.
Concreet betekent het verschil dit. "AVG-proof" zegt iets over de afspraken: doeleinden, grondslagen, bewaartermijnen, rechten. Het zegt niets over de uitvoering: hoe toegang geregeld is, of er gelogd wordt, hoe snel een kwetsbaarheid gedicht wordt, of er back-ups zijn en of die ooit getest zijn, wie er ’s nachts gebeld wordt als het misgaat. De nieuwe wet — en breder: de nieuwe norm — legt de nadruk precies dáár. Op de uitvoering. Op aantoonbaarheid.
Voor scholen betekent dat een verschuiving in het inkoopgesprek. De vraag aan een leverancier is niet langer alleen "heeft u een verwerkersovereenkomst?" (het antwoord is altijd ja), maar: "hoe is de toegang tot leerlinggegevens geregeld, wat logt u, waar staan de back-ups, wat is uw incidentprocedure en wie is daarvoor bereikbaar?" Vijf vragen die niet met een stempel te beantwoorden zijn, alleen met inhoud.
En voor leveranciers — wij dus — betekent het dat je die antwoorden klaar moet hebben vóórdat de vraag komt. Niet als glossy folder, maar als feiten die kloppen en controleerbaar zijn. Verderop in dit stuk doen we precies dat.
AI in de klas maakt deze vraag urgenter, niet abstracter
Waarom schrijven wij — een AI-nakijktool — hier zo uitgebreid over? Omdat AI het beveiligingsvraagstuk in het onderwijs niet theoretischer maakt, maar juist heel tastbaar. Kijk maar wat er door een AI-nakijksysteem heen gaat: gescand leerlingwerk, met naam en handschrift. Antwoorden waaruit je leert wat een kind wel en niet begrijpt. Cijfers, foutpatronen, ontwikkeling over tijd. Dat zijn geen bedrijfsgegevens waar een aandeelhouder wakker van ligt — het zijn gegevens van dertien-, veertien-, vijftienjarigen, die zelf nooit gevraagd is of ze dit goed vinden, en die op hun school vertrouwen dat het goed geregeld is.
We schreven eerder al over de AVG-vraag bij AI-nakijken en over waarom een Iers datacenter je nog niet Europees maakt. De rode draad in beide stukken: de docent hoort niet degene te zijn die dit allemaal moet doorgronden. Een docent die zijn zondagavond terug wil, gaat niet eerst jurisdicties vergelijken — en dat hoeft ook niet, zolang degene die de tool bouwt zijn verantwoordelijkheid neemt. De nieuwe wet trekt diezelfde lijn door naar beveiliging: de deskundigheid hoort bij de leverancier te liggen, de controleerbaarheid bij de school.
Er is nog een tweede, ongemakkelijker reden waarom AI en security in het onderwijs over elkaar heen schuiven: schaduw-AI. Op elke school werken op dit moment docenten die uit eigen beweging leerlingwerk in een gratis chatbot plakken. Uit enthousiasme, uit tijdnood, met de beste bedoelingen. Maar een gratis consumenten-chatbot heeft geen verwerkersovereenkomst met de school, geeft geen garanties over waar de invoer heen gaat, en gebruikt die invoer in veel gevallen om modellen te trainen. Het leerlingwerk dat er vanavond in gaat, is de school kwijt — niet fysiek, maar wel qua zeggenschap. Geen kwade wil, wel een datalek in slow motion.
De oplossing is niet om AI de school uit te jagen; die wedstrijd is al gelopen, en het gereedschap is te nuttig. De oplossing is kanaliseren: zorg dat er voor de taken waar docenten AI voor wíllen gebruiken een route is die wél goed geregeld is — met afspraken, met beveiliging, met een aanspreekpunt. Dan hoeft niemand meer te sluipen. Precies daarom vinden wij dat elke AI-leverancier in het onderwijs het voortouw moet nemen op beveiliging, in plaats van te wachten tot een inkoper erom vraagt.
De zes vragen die je elke edtech-leverancier zou moeten stellen
Goed. Je zit als schoolleider, ICT-coördinator, privacycoördinator of gewoon als kritische docent tegenover een leverancier — van een nakijktool, een leerlingvolgsysteem, een oefenplatform, maakt niet uit. Wat vraag je? Hieronder de zes vragen die samen een compact maar dekkend beeld geven. Bij elke vraag: wat een goed antwoord is, en waar de rode vlaggen wapperen.
1. Hoe zijn de gegevens versleuteld?
Versleuteling is de bodem onder alles. Gegevens horen versleuteld te zijn op twee momenten: onderweg (tussen jouw browser en de server, en tussen systemen onderling) en in rust (op de schijf waar ze opgeslagen staan). Een goed antwoord noemt beide en is concreet: bijvoorbeeld TLS 1.2 of hoger voor transport en AES-256 voor opslag. Een rode vlag is een antwoord dat alleen "wij gebruiken een beveiligde verbinding" zegt — dat gaat alleen over onderweg, en zegt niets over de schijf waar het leerlingwerk jaren op staat.
2. Wie kan er bij de gegevens, en hoe is dat afgeschermd?
Toegangsbeheer is waar de meeste incidenten in de praktijk beginnen. De vragen: kan docent A het werk van de leerlingen van docent B zien? Wordt toegang op het niveau van de gegevens zelf afgedwongen, of alleen in de schermen van de app? Hoeveel medewerkers van de leverancier kunnen bij productiedata, en waarvoor? Een goed antwoord beschrijft afscherming op gegevensniveau — elke rij data gekoppeld aan een account, technisch afgedwongen — en het principe van minimale toegang: niemand kan bij meer dan nodig. Rode vlag: "onze medewerkers kunnen overal bij, maar die zijn te vertrouwen." Vertrouwen is geen maatregel.
3. Wat wordt er gelogd, en kijkt er iemand naar?
Logging is het verschil tussen "we zijn gehackt en weten niet sinds wanneer" en "we zagen het binnen een dag". Een goed antwoord vertelt dat er wordt bijgehouden wie wanneer wat doet, dat fouten en afwijkingen automatisch gesignaleerd worden, en — cruciaal — dat er ook daadwerkelijk iemand of iets naar die signalen kijkt. Logs waar nooit iemand naar omkijkt zijn behang. Rode vlag: een stilte, of "dat kunnen we uitzoeken als er iets is". Dan is de logging er dus niet.
4. Hoe zijn back-ups en continuïteit geregeld?
Beveiliging gaat niet alleen over inbrekers, maar ook over brand: wat als er iets stuk gaat? De vragen: worden er automatisch back-ups gemaakt, hoe vaak, en is het terugzetten ervan ooit echt geoefend? Wat gebeurt er met de dienstverlening en de data als de leverancier zelf omvalt? Een goed antwoord is nuchter en concreet; het mooiste antwoord bevat de zin "dat hebben we getest". Rode vlag: back-ups die alleen in de folder bestaan, of een leverancier die de continuïteitsvraag wegwuift met groeicijfers.
5. Wat gebeurt er bij een incident of datalek?
Niet óf het een keer misgaat is de toets, maar wat er dán gebeurt. Een goed antwoord beschrijft een procedure: de school wordt onverwijld geïnformeerd, met de aard van het incident, welke gegevens en leerlingen het raakt, wat de gevolgen kunnen zijn en welke maatregelen er genomen zijn — precies de informatie die de school nodig heeft om zelf haar meldplicht richting de Autoriteit Persoonsgegevens en de betrokkenen na te komen. Rode vlag: "dat is nog nooit voorgekomen" als volledig antwoord. Dat is geen procedure, dat is een gok.
6. Wie is het aanspreekpunt — en hoe snel reageert die?
De simpelste vraag, en verrassend vaak de ontmaskerende. Als jouw ICT-coördinator morgen een beveiligingsvraag heeft, wie mailt hij dan, en krijgt hij binnen een redelijke termijn een inhoudelijk antwoord van iemand die de systemen echt kent? Een goed antwoord is een naam of een duidelijk kanaal, dicht bij de techniek. Rode vlag: een algemeen supportadres waar beveiligingsvragen in dezelfde wachtrij belanden als vragen over vergeten wachtwoorden.
Zes vragen, geen dertig pagina’s. Een leverancier die deze zes vlot, concreet en zonder jargon beantwoordt, heeft zijn zaken vrijwel zeker beter op orde dan een leverancier die een dik certificeringsdocument overhandigt en hoopt dat je niet doorvraagt.
Hoe wij het geregeld hebben — de zes vragen, aan onszelf gesteld
Wie zes vragen aan de hele sector stelt, moet ze zelf ook beantwoorden. Bij dezen. Eén kanttekening vooraf, dezelfde die we eerder maakten: we beschrijven hier wat er geregeld is, niet tot op schroefniveau hoe. Dat is geen geheimzinnigheid om de geheimzinnigheid — een gedetailleerde plattegrond van je beveiliging publiceren is behulpzaam voor precies twee groepen: concurrenten en aanvallers. Scholen die dieper willen kijken, kunnen dat gewoon: onze verwerkersovereenkomst staat openbaar op de site, de zes antwoorden hieronder staan compact en printbaar in onze beveiligingsfactsheet, en via contact beantwoorden we elke beveiligingsvraag inhoudelijk.
Versleuteling
Leerlingwerk en alle overige gegevens zijn versleuteld in rust met AES-256 en onderweg met TLS 1.2 of hoger. Er is geen route waarlangs gegevens onversleuteld het systeem in- of uitgaan; verbindingen die dat niet ondersteunen, worden geweigerd in plaats van gedoogd. Dit staat niet alleen hier in een blogpost, het staat als verplichting in onze verwerkersovereenkomst — het document waar een school ons aan kan houden.
Toegangsbeheer
Toegang wordt afgedwongen op het niveau van de gegevens zelf, per rij in de database: het werk van jouw leerlingen is gekoppeld aan jouw account, en die koppeling wordt door de databank zelf gecontroleerd bij elke opvraging — niet alleen door de schermen van de app. Een fout in een scherm kan daardoor geen gegevens van een andere docent tonen, want de laag eronder geeft ze simpelweg niet. Voor scholen die centraal willen aansluiten ondersteunen we inloggen via de schoolomgeving (Entree Federatie), zodat het accountbeheer daar ligt waar de school het al voert. En intern hanteren we minimale toegang: systemen en mensen kunnen bij wat nodig is voor hun taak, en niet meer.
Logging en monitoring
We loggen wat er in het systeem gebeurt en — belangrijker — we kijken ernaar. Geautomatiseerde controles draaien dagelijks over de gezondheid van het platform en slaan zelf alarm bij afwijkingen, in plaats van te wachten tot een gebruiker iets meldt. Fouten in de verwerking worden centraal verzameld en onderzocht. We zijn hier bewust zuinig in wát we loggen: logbestanden zijn zelf ook een plek waar gegevens kunnen rondslingeren, dus persoonsgegevens horen er zo min mogelijk in thuis. Loggen is voor ons een beveiligingsinstrument, geen tweede kopie van de data.
Back-ups en continuïteit
Er worden automatisch back-ups gemaakt van de gegevens, op infrastructuur van gevestigde Europese en internationale aanbieders die hun sporen in beschikbaarheid hebben verdiend. Net zo belangrijk: de school blijft eigenaar van haar gegevens. Docenten kunnen hun werk en resultaten exporteren, en bij het einde van een overeenkomst worden gegevens verwijderd of overgedragen volgens de afspraken in de verwerkersovereenkomst. Continuïteit is bij ons geen bijzin maar een ontwerpkeuze: het ergste scenario voor een school — al het nakijkwerk van een jaar kwijt — is het scenario waar wij tegen bouwen.
Incidentprocedure
Als er iets misgaat, hoort de school dat van ons, onverwijld, en met de informatie die zij nodig heeft: de aard van het incident, de categorieën betrokken leerlingen en gegevens, de waarschijnlijke gevolgen en de maatregelen die we genomen hebben. Zo kan de school haar eigen meldplicht richting de Autoriteit Persoonsgegevens en, waar nodig, richting ouders en leerlingen nakomen — met feiten in plaats van paniek. Die procedure staat zwart op wit in de verwerkersovereenkomst. We hopen hem nooit nodig te hebben; we hebben hem alsof het morgen is.
Aanspreekpunt
Corrigo is gebouwd door mensen die je kunt bereiken. Beveiligingsvragen komen niet in een anonieme supportwachtrij, maar bij de makers zelf — de lijnen zijn kort, en wie ons via de contactpagina een beveiligingsvraag stelt, krijgt een inhoudelijk antwoord van iemand die het systeem daadwerkelijk kent. Voor een ICT-coördinator die een vragenlijst moet invullen is dat het verschil tussen weken heen-en-weer en één goed gesprek.
En specifiek voor de AI: waar gaat het leerlingwerk heen?
Omdat dit dé vraag is bij een AI-tool, apart en expliciet. De AI-beoordeling van leerlingwerk wordt verwerkt binnen de EU-regio van Amazon Web Services (AWS Bedrock); die gegevens blijven daarmee binnen de EU. Dat is geen toevallige serverkeuze maar een bewuste stap die we dit jaar hebben gezet en in onze verwerkersovereenkomst en subverwerkerslijst hebben vastgelegd. En minstens zo belangrijk: er wordt niet getraind op leerlingwerk. Niet door ons, en contractueel evenmin door de AI-aanbieders die wij inzetten. Het werk van jouw leerlingen maakt het model van niemand slimmer; het wordt beoordeeld, en dat is het.
Wat we bewust níet claimen
Nu het deel dat in de meeste leveranciersblogs ontbreekt: wat we niet zeggen.
We schermen niet met certificeringen die we niet hebben. Geen ISO 27001-logo op de site, geen "gecertificeerde beveiliging" in de kleine lettertjes, geen keurmerkentaal. Niet omdat we certificering onzin vinden — voor grote organisaties met tientallen systemen en honderden medewerkers is zo’n extern getoetst raamwerk waardevol — maar omdat een claim pas iets waard is als hij klopt. Een startup die met certificeringstaal strooit zonder de audits erachter, doet precies dat waar dit hele stuk tegen waarschuwt: papier laten zien in plaats van uitvoering. Zodra certificering voor onze fase en omvang de juiste stap is, zetten we die echt. Tot die tijd vertellen we je liever concreet wat er geregeld is, zodat je het kunt controleren.
We beloven ook geen onkwetsbaarheid. Niemand kan dat, en wie het toch doet, liegt of begrijpt zijn eigen vak niet. Software heeft fouten; de vraag is hoe snel je ze vindt, hoe eerlijk je erover bent en hoe goed je gebouwd hebt op het moment dat er tóch iets doorheen glipt. Daarom investeren we structureel in doorlopende controles en laten we onze eigen aannames periodiek grondig tegen het licht houden — en daarom staat de incidentprocedure hierboven zo prominent. Beveiliging is geen toestand die je bereikt, het is werk dat je blijft doen.
En we claimen niet dat een verwerkersovereenkomst alles oplost — terwijl we hem wél gewoon openbaar op de site hebben staan, zodat je hem kunt lezen vóórdat je ons je vertrouwen geeft. Papier is het begin van controleerbaarheid, niet het einde van het gesprek.
Wat er verder nog aankomt: van NIS2 tot de AI-verordening
De Cyberbeveiligingswet staat niet op zichzelf. Vrijwel gelijktijdig — augustus 2026 — worden ook belangrijke delen van de Europese AI-verordening van kracht, de wet die eisen stelt aan AI-systemen naar gelang hun risico. Voor AI in het onderwijs is dat een grote: systemen die leerprestaties beoordelen, zitten in de categorie waar de strengste eisen aan hangen, en de vraag hoe een AI-nakijktool zich daartoe verhoudt is er een die elke aanbieder in deze markt scherp moet kunnen beantwoorden. Wij volgen dat traject op de voet en hebben er juridisch werk van gemaakt vóórdat de deadline ons dwong — de docent houdt bij Corrigo het oordeel, de AI doet het voorwerk, en dat onderscheid is precies waar de verordening om draait. Daarover binnenkort meer in een eigen stuk, want het verdient er een.
De grotere beweging is duidelijk: Europa trekt de teugels aan rond digitale infrastructuur, gegevens en AI, en het onderwijs — met zijn minderjarige betrokkenen en publieke taak — zit telkens in het hart van de doelgroep die beschermd wordt. Voor scholen is dat per saldo goed nieuws: de wetten dwingen af wat een goede leverancier toch al hoorde te doen. De kaf-en-koren-scheiding wordt de komende twee jaar zichtbaar. Leveranciers die hun beveiliging serieus namen toen het nog niet hoefde, hebben nu een voorsprong; leveranciers die "AVG-proof" als eindstation zagen, krijgen huiswerk.
Praktisch: wat je als school vóór het nieuwe schooljaar kunt doen
Geen groot project, gewoon een lijstje. Dit kan een schoolleider of ICT-coördinator in één middag in gang zetten:
- Inventariseer welke digitale tools er echt gebruikt worden — inclusief de tools die docenten op eigen houtje gebruiken. De officiële lijst is altijd korter dan de werkelijkheid, en juist het verschil tussen die twee is je risico.
- Check per tool of er een verwerkersovereenkomst ligt — en of die vindbaar is. Een overeenkomst die niemand kan vinden als het misgaat, bestaat in de praktijk niet.
- Stel de zes vragen uit dit stuk aan je drie belangrijkste leveranciers. Niet als examen, maar als gesprek. Let minder op de perfectie van de antwoorden en meer op de snelheid en concreetheid ervan.
- Maak één afspraak over AI-gebruik door docenten. Welke tools mogen wél met leerlingwerk, welke niet, en waar meldt een docent twijfel? Eén A4 met drie regels verslaat een verbod dat niemand naleeft.
- Zet beveiliging één keer per jaar op de agenda van het bestuur of de schoolleiding. Niet omdat de wet het van jouw school eist, maar omdat de vragen tóch komen — van het bestuur, van ouders, of van de krant. Wie het gesprek zelf plant, voert het op zijn eigen moment.
Meer over hoe Corrigo scholen hierin meeneemt — van proefperiode tot verwerkersovereenkomst tot uitrol per sectie — vind je op de pagina voor scholen.
Kleine woordenlijst voor het beveiligingsgesprek
Wie het gesprek met een leverancier of bestuur ingaat, komt een handvol termen telkens tegen. Je hoeft ze niet te kunnen spellen, wel te kunnen plaatsen. De belangrijkste, zonder jargon uitgelegd:
- NIS2 — de Europese richtlijn voor netwerk- en informatiebeveiliging waar de Nederlandse Cyberbeveiligingswet uit voortkomt. Als iemand "NIS2" zegt en iemand anders "Cyberbeveiligingswet", hebben ze het over hetzelfde bouwwerk: Europa tekende het, Nederland bouwt het.
- Versleuteling in rust en onderweg — gegevens onleesbaar maken voor iedereen zonder sleutel, zowel op de schijf waar ze staan ("in rust", bijvoorbeeld AES-256) als tijdens het transport tussen jouw browser en de server ("onderweg", bijvoorbeeld TLS). Je hebt allebei nodig; één van de twee is een halve deur.
- Toegangsbeheer op gegevensniveau — de afscherming zit in de databank zelf, niet alleen in de schermen van de app. Elke rij data weet van wie hij is, en de databank weigert elke opvraging door een ander. Een programmeerfout in een scherm kan dan geen andermans leerlingen tonen.
- Verwerkersovereenkomst — het contract tussen school en leverancier over de omgang met persoonsgegevens: wat er verwerkt wordt, waarvoor, hoe het beveiligd is, wie de subverwerkers zijn en wat er bij een datalek gebeurt. De school blijft verantwoordelijk; dit document maakt de leverancier aanspreekbaar.
- Subverwerker — een partij die de leverancier zelf weer inschakelt, zoals een hostingpartij of een AI-aanbieder. De keten is zo sterk als de zwakste subverwerker, dus de lijst hoort openbaar of op zijn minst vóór ondertekening beschikbaar te zijn.
- Meldplicht — de verplichting om incidenten te melden: onder de AVG bij de Autoriteit Persoonsgegevens als er persoonsgegevens in het geding zijn, onder de Cyberbeveiligingswet bij de toezichthouder als de dienstverlening geraakt wordt. Voor jou als school telt vooral: de leverancier moet jóu zo snel informeren dat jij jouw meldplicht kunt halen.
- Datalek versus incident — een datalek gaat over persoonsgegevens die zijn ingezien, gewijzigd of verdwenen; een incident is breder en omvat ook storingen en aanvallen zonder gelekte gegevens. Een platgelegde nakijkweek zonder gelekte data is geen datalek, maar wél een incident dat je leverancier serieus hoort af te handelen.
- Schaduw-AI — AI-gebruik dat buiten het zicht en de afspraken van de school om gebeurt, zoals leerlingwerk in een gratis chatbot plakken. Het grootste beveiligingsrisico van dit moment in het onderwijs, juist omdat het uit goede bedoelingen voortkomt.
Veelgestelde vragen over AI en security op school
Is toetsen nakijken met AI veilig?
Dat hangt volledig af van hoe de leverancier het geregeld heeft: waar het leerlingwerk wordt verwerkt, wie erbij kan, of er op de data getraind wordt en wat er bij een incident gebeurt. "AI" zegt op zichzelf niets over veiligheid — net zomin als "software". Vraag om een verwerkersovereenkomst en een concreet beveiligingsoverzicht: versleuteling, toegangsbeheer, logging, back-ups, incidentprocedure en een aanspreekpunt. Bij Corrigo is de AI-beoordeling van leerlingwerk binnen de EU-regio van AWS Bedrock ingericht, wordt er niet op leerlingdata getraind, en is dat alles vastgelegd in de verwerkersovereenkomst.
Valt mijn school onder de Cyberbeveiligingswet (NIS2)?
De meeste individuele scholen in het funderend onderwijs vallen niet rechtstreeks onder de Cyberbeveiligingswet; de wet richt zich op essentiële en belangrijke entiteiten in aangewezen sectoren. Maar de wet werkt door in de keten: grote besturen, samenwerkingsverbanden en gemeenten gaan strengere eisen stellen aan leveranciers, en dus indirect aan de tools die een school inkoopt. Check bij twijfel je koepelorganisatie of bestuur — en gedraag je vooral alsof de vragen toch komen, want dat doen ze.
Wat is het verschil tussen de AVG en de Cyberbeveiligingswet?
De AVG gaat over persoonsgegevens: mag je ze verwerken, waarvoor, en zijn de rechten van betrokkenen geborgd. De Cyberbeveiligingswet gaat over digitale weerbaarheid: is een organisatie bestand tegen aanvallen en storingen, worden risico’s beheerst, worden incidenten gemeld en is het bestuur aantoonbaar verantwoordelijk. Een tool kan keurig een verwerkersovereenkomst hebben en tóch zwak beveiligd zijn — "AVG-proof" zegt niets over het beveiligingsniveau. Je hebt beide nodig: de afspraken én de uitvoering.
Waar worden leerlinggegevens bij Corrigo verwerkt en opgeslagen?
De AI-beoordeling van leerlingwerk wordt verwerkt binnen de EU-regio van Amazon Web Services (AWS Bedrock); die gegevens blijven daarmee binnen de EU. Opslag is versleuteld in rust (AES-256) en onderweg (TLS 1.2 of hoger). De volledige en actuele subverwerkerslijst staat in onze verwerkersovereenkomst, openbaar op de site — je hoeft er geen account voor aan te maken en geen verkoopgesprek voor te voeren.
Traint Corrigo AI-modellen op leerlingwerk?
Nee. Corrigo traint geen AI-modellen op leerlingwerk, en de AI-aanbieders die wij als subverwerker inzetten gebruiken de via Corrigo verwerkte gegevens contractueel niet voor het trainen van hun modellen. Het werk van je leerlingen wordt beoordeeld en daarna met rust gelaten. Dit staat expliciet in de verwerkersovereenkomst, dus het is geen belofte in een blog maar een afspraak waar je ons aan kunt houden.
Wat doet Corrigo bij een datalek of beveiligingsincident?
We stellen de school onverwijld op de hoogte, met ten minste: de aard van het incident, de categorieën betrokken leerlingen en gegevens, de waarschijnlijke gevolgen en de maatregelen die we hebben genomen. Daarmee kan de school haar eigen meldplicht richting de Autoriteit Persoonsgegevens en betrokkenen nakomen. De procedure staat in de verwerkersovereenkomst; het aanspreekpunt bereik je via de contactpagina.
Mag een docent leerlingwerk in een gratis AI-chatbot plakken?
Vrijwel altijd niet. Bij gratis consumenten-chatbots is er meestal geen verwerkersovereenkomst met de school, geen garantie over de verwerkingslocatie, en vaak wél training op wat je invoert. Leerlingwerk bevat persoonsgegevens — een naam, een handschrift, een prestatie — en de school is daarvoor verantwoordelijk, ook als een docent op eigen initiatief handelt. De praktische route: gebruik voor leerlingwerk alleen tools waarmee de school afspraken heeft, en maak dat als school expliciet, zodat docenten niet hoeven te gokken.
Wat moet er in een verwerkersovereenkomst met een AI-leverancier staan?
Ten minste: welke gegevens er worden verwerkt en met welk doel, de beveiligingsmaatregelen (versleuteling, toegangsbeheer), de subverwerkers en hun verwerkingslocaties, een expliciete bepaling over wel of niet trainen op de data, de meldprocedure bij datalekken, bewaartermijnen en verwijdering bij einde overeenkomst, en ondersteuning bij rechten van betrokkenen. Twee snelle rode vlaggen: een ontbrekende trainingsbepaling en een subverwerkerslijst die "op aanvraag" is. Wat je vóór het tekenen niet mag zien, wordt na het tekenen zelden mooier.
Heeft Corrigo een ISO 27001-certificaat?
Nee — en dat beweren we dan ook nergens, ook niet in bedekte termen. We vinden dat je alleen met certificeringen mag schermen als je ze daadwerkelijk hebt; certificeringstaal zonder audit is precies het soort papieren veiligheid waar dit artikel voor waarschuwt. Wat we wél hebben: concrete, controleerbare maatregelen die openbaar in onze verwerkersovereenkomst staan, en de bereidheid elke beveiligingsvraag inhoudelijk te beantwoorden. Zodra certificering past bij onze fase en omvang, doen we het echt.
Wat is het Normenkader IBP en wat doet Corrigo ermee?
Het Normenkader Informatiebeveiliging en Privacy voor het funderend onderwijs is de meetlat waarmee scholen in het po en vo hun digitale veiligheid opbouwen en toetsen, met concrete normen en groeiende ambitieniveaus. Scholen die ermee werken, vertalen die normen door naar hun leveranciers — en dat merken wij aan de vragenlijsten die we krijgen. Wij gebruiken het kader als leidraad voor de eisen die we aan onszelf stellen en beantwoorden de leveranciersvragen die eruit voortvloeien concreet en zonder omwegen. Precies zoals het bedoeld is.
Tot slot: de lat gaat omhoog, en dat is goed nieuws
Op 15 augustus verandert er voor de meeste scholen juridisch weinig — en tegelijk verandert er alles aan de richting. Beveiliging verschuift van "iets voor de ICT’er" naar bestuurstafel, van vinkje naar aantoonbaarheid, van folder naar feiten. Voor het onderwijs, dat werkt met de gegevens van kinderen, is dat geen last maar een inhaalslag die er allang had moeten zijn.
Voor jou als docent hoeft het geen studie te worden. Onthoud de kern: een goede leverancier kan zes simpele vragen concreet beantwoorden, heeft zijn afspraken openbaar staan, claimt niets wat hij niet waar kan maken en is bereikbaar als het erop aankomt. Meet ons daar gerust aan. Onze verwerkersovereenkomst, ons privacybeleid én onze printbare beveiligingsfactsheet staan open en bloot op de site, en wie voor zijn school een ingevulde vragenlijst nodig heeft, krijgt die via contact — van iemand die het systeem zelf gebouwd heeft.
En wil je gewoon eerst zien wat nakijken met AI voor je zondagavond betekent, voordat je ook maar één leerlinggegeven toevertrouwt? Probeer het op een voorbeeldproject. Eerst zien, dan vertrouwen. Dat principe geldt bij ons voor het nakijken — en voor de beveiliging eromheen net zo hard.