Wat een incidentrespons-draaiboek is (en waarom elke school er een nodig heeft)

11-09-2026 · 6 min leestijd

Een leerkracht meldt vrijdagmiddag om 16:00 dat er "iets vreemds" gebeurt met het cijfersysteem. Wie wordt er nu gebeld? Wie mag beslissen om accounts tijdelijk te blokkeren? Moet de directie meteen ingelicht worden, of eerst de IT-ondersteuning? En wat gebeurt er als het antwoord op deze vragen "dat weten we eigenlijk niet precies" is — op het moment dat het er juist toe doet?

Dit is precies waar een incidentrespons-draaiboek voor is: geen technisch document voor IT'ers alleen, maar een simpel, van tevoren afgesproken stappenplan dat vastlegt wie wat doet zodra er iets misgaat — zodat die beslissing niet improviserend genomen hoeft te worden op het moment van paniek.

Waarom "we lossen het dan wel op" niet werkt

Scholen zonder draaiboek reageren op een incident zoals de meeste organisaties zonder draaiboek: ad hoc, met de beste bedoelingen, maar vaak te laat en op de verkeerde volgorde. Typische problemen die dan ontstaan:

• Niemand weet wie de beslissing mag nemen om een account te blokkeren of het netwerk (deels) af te sluiten — waardoor kostbare tijd verloren gaat aan overleg terwijl het probleem doorgaat.
• Bewijs gaat verloren. Een systeem dat te snel wordt herstart of "opgeschoond" voordat iemand heeft gekeken wat er precies gebeurd is, wist tegelijk de sporen die nodig waren om te begrijpen wat er misging.
• Communicatie naar ouders en personeel komt te laat of te vaag. Zonder vooraf afgesproken sjabloon ontstaat er vaak dagen vertraging voor er iets naar buiten gaat — in welk vacuüm geruchten sneller de ronde doen dan feiten.

Wat een basaal draaiboek in elk geval bevat

1. Een belronde, geen zoekactie. Eén vaste lijst met wie als eerste gebeld wordt (IT-coördinator, directie, eventueel een externe partij), inclusief telefoonnummers die niet pas opgezocht hoeven worden op het moment zelf.
2. Een duidelijk mandaat. Vastleggen wie mag beslissen om een account te blokkeren of systeemtoegang te beperken, zonder daarvoor eerst een voltallige vergadering nodig te hebben.
3. Bewaar bewijs voor je opruimt. De eerste instinctieve reactie — "even snel resetten en opnieuw beginnen" — is precies de verkeerde eerste stap. Eerst vastleggen wat er te zien is (wie was ingelogd, welk bestand, welk tijdstip), pas daarna herstellen.
4. Een communicatiesjabloon. Een kort, eerlijk bericht klaar hebben liggen voor ouders en personeel scheelt kostbare tijd — en voorkomt dat een school moet improviseren onder druk van bezorgde telefoontjes.
5. Een nabespreking, ook als het meeviel. Wat ging er goed, wat kostte te veel tijd, wat moet volgende keer sneller? Zonder deze stap leert een school niets van een incident dat wél goed afliep.

Waarom dit ook een onderwijskundige kans is

Een school die een eigen (of eenvoudig) incidentrespons-draaiboek heeft, heeft meteen ook een concreet, eigen voorbeeld te delen met leerlingen — in plaats van alleen een fictief scenario. Dat sluit direct aan bij wat leerlingen zelf ervaren in Hack The School, waar ze als SOC-analist een schoolincident reconstrueren aan de hand van sporen: wie logde wanneer in, welk bestand werd gedownload, welke aanwijzingen samen een verhaal vertellen (zie ook wat doet een SOC-analist). Het verschil tussen het spel en de praktijk is dan opeens klein: "dit is precies wat er bij ons ook zou gebeuren, en dit is wie het dan oppakt."

Hoe je hiermee begint zonder een groot project te maken

• Begin met de belronde, niet met een compleet document. Eén A4'tje met namen, rollen en telefoonnummers is al een enorme verbetering ten opzichte van niets.
• Wijs één verantwoordelijke aan, ook als die persoon niet fulltime IT doet — iemand die weet dat hij of zij die rol heeft, is al de helft van het werk.
• Oefen het een keer, al is het informeel. Een kort gesprek in het team over "stel dat dit morgen gebeurt" legt vaak al de grootste gaten in het plan bloot.