Scheid het organisatieplan van technische scenario’s
Het organisatieplan bevat de vaste werkwijze: melden, beoordelen, opschalen, besluiten, communiceren en afsluiten. Daaronder hangen scenario’s voor bijvoorbeeld uitval van een leverancier, een overgenomen account of ransomware. Een scenario beschrijft herkenbare signalen, benodigde expertise en beslismomenten. Zo hoeft de algemene bellijst niet in ieder technisch document opnieuw te worden bijgehouden.
Maak een compacte startkaart die ook bij uitval van de normale omgeving beschikbaar is. Zet daarop het meldpunt, de vervanger van de incidentcoördinator, het alternatieve communicatiekanaal en de plek van het actuele plan. Bewaar die informatie toegankelijk voor bevoegde medewerkers. Een plan achter hetzelfde aanmeldsysteem dat mogelijk uitvalt, levert een voorspelbare blinde vlek op.
Leg mandaat en vervanging vast vóór de crisis
Benoem een incidentcoördinator, technische verantwoordelijke, proceseigenaar, communicatieverantwoordelijke en iemand voor het logboek. Privacy en juridische expertise sluiten aan wanneer gegevens, contracten of meldplichten geraakt worden. Meerdere rollen kunnen bij kleine organisaties worden gecombineerd, zolang het werk uitvoerbaar blijft en iemand belangrijke besluiten blijft vastleggen.
Bespreek vooraf wie een koppeling mag stilzetten, externe hulp mag inschakelen of tijdelijk een handmatige werkwijze mag starten. Leg grenzen en vervangers vast. De technisch snelste maatregel kan immers gevolgen hebben voor veiligheid of dienstverlening. Een bereikbaarheidsafspraak met een externe partij moet daadwerkelijk zijn overeengekomen; alleen een telefoonnummer in het plan opnemen regelt geen beschikbaarheid.
Classificeer op gevolgen en onzekerheid
Vraag bij de eerste melding welke dienst is geraakt, wat is waargenomen, wanneer dat gebeurde en of gevolgen nog toenemen. Scheid vastgestelde feiten van vermoedens. Een storing kan een aanval blijken; een aanval hoeft niet zichtbaar alle systemen te raken. Zorg dat nieuwe informatie tot herclassificatie kan leiden zonder dat iemand eerst een eerdere inschatting hoeft te verdedigen.
Onderstaande tabel is een fictief organisatiemodel. Maak eigen grenzen op basis van uw processen en risico’s. Een mogelijk ernstig gevolg kan voldoende reden zijn om expertise en bestuur te betrekken, ook wanneer de technische oorzaak nog onbekend is. Gebruik de niveaus niet als vervanging van wettelijke criteria voor een meldplichtig incident.
De tabel is opzij te schuiven.
| Signaal | Eerste organisatieactie | Besluit dat moet zijn belegd |
|---|---|---|
| Beperkte verstoring met bekende oplossing | Registreren, technisch beoordelen en volgen | Wie bevestigt dat reguliere afhandeling volstaat? |
| Onverklaarde toegang of mogelijk gegevensverlies | Incidentcoördinator en relevante expertise betrekken | Wie beperkt toegang en bewaakt onderzoek? |
| Kritieke dienstverlening of veiligheid bedreigd | Crisisregie en continuïteitsroute activeren | Wie beslist over stilleggen, uitwijk en externe communicatie? |
| Omvang onbekend en signalen nemen toe | Vaste korte updates en gerichte verificatie | Wie schaalt op bij uitblijven van duidelijkheid? |
Organiseer één feitenbeeld en veilige communicatie
Houd een tijdlijn bij met waarnemingen, genomen maatregelen, beslissers en open vragen. Leg bij een besluit ook het verwachte nadeel en de reden vast. Dat helpt wanneer teams wisselen of later blijkt dat een aanname niet klopt. Beperk persoonsgegevens en toegangsrechten tot wat nodig is voor behandeling en verantwoording van het incident.
Spreek af wie intern, met leveranciers en met betrokkenen communiceert. Gebruik een alternatief kanaal wanneer de betrouwbaarheid van reguliere e-mail onzeker is. Geef updates met bekende feiten, onzekerheden, handelingsadvies en het volgende informatiemoment. Vermijd geruststellingen die onderzoek nog niet ondersteunt. NIST SP 800-61r3 verbindt incidentrespons met het bredere risicomanagement; de communicatie en voorbereiding horen daar al vóór een incident bij.
Maak afzonderlijke meldroutes voor AVG en Cyberbeveiligingswet
Een datalek en een significant cyberincident hebben verschillende criteria. Leg per regime vast wie toepasselijkheid beoordeelt, wanneer kennisname is vastgesteld en wie meldt. Onder de AVG meldt de verwerkingsverantwoordelijke een datalek onverwijld en waar mogelijk binnen 72 uur na kennisname aan de bevoegde toezichthouder, tenzij een risico voor rechten en vrijheden onwaarschijnlijk is. Bij waarschijnlijk hoog risico moeten in beginsel ook betrokkenen onverwijld worden geïnformeerd.
De reguliere CBW-route voor significante incidenten omvat zo snel mogelijk een vroegtijdige waarschuwing, uiterlijk binnen 24 uur na kennisname, en een incidentmelding uiterlijk binnen 72 uur. Het eindverslag volgt uiterlijk één maand na die incidentmelding. Bij een incident dat dan nog voortduurt, komt eerst een voortgangsverslag; het eindverslag volgt uiterlijk één maand na afhandeling. Sectorale uitzonderingen kunnen afwijken; controleer vooraf de toepasselijke route.
Zet deze routes naast contractuele meldingen aan klanten, verzekeraar en leveranciers. Eén melding dekt niet automatisch alle verplichtingen. Laat beschikbare feiten tijdig beoordelen en plan vervolgupdates. Ontbrekende details zijn geen reden om zonder meer te wachten tot het onderzoek klaar is. Neem contactgegevens en toegang tot meldportalen vooraf op in het plan.
Definieer wanneer herstel verantwoord is
Een systeem dat opnieuw aanstaat, is niet automatisch betrouwbaar. Leg vast wie controleert of de oorzaak voldoende is weggenomen, gegevens bruikbaar zijn en noodzakelijke koppelingen werken. Bepaal welke dienstverlening eerst wordt hersteld en welke controles vooraf nodig zijn. Laat de proceseigenaar de bruikbaarheid beoordelen en technische deskundigen de relevante beveiligingsvoorwaarden toetsen.
Maak afspraken over extra waarneming na herstel en terugval als nieuwe afwijkingen optreden. Bewaar informatie die nodig is voor onderzoek zorgvuldig; ondoordachte herstelhandelingen kunnen relevante sporen overschrijven. Specialistische analyse en herstel worden op elkaar afgestemd. Het plan geeft bevoegdheden en afwegingspunten, geen universeel commando dat bij ieder incident veilig is.
Fictieve oefening: de planningsdienst valt uit
Een fictieve organisatie ontvangt vlak voor de werkdag meldingen dat medewerkers hun planning niet kunnen openen. De leverancier meldt een verstoring zonder oorzaak. In de oefening heeft de incidentcoördinator geen toegang tot de normale mailbox en is de vaste IT-contactpersoon afwezig. De groep moet de bellijst, vervanging en handmatige werkwijze daadwerkelijk terugvinden.
Vervolgens krijgt het team een tweede bericht: er wordt onderzocht of onbevoegde toegang heeft plaatsgevonden. De deelnemers bepalen welke aanvullende feiten nodig zijn, wie privacy en bestuur betrekt en hoe lopende communicatie wordt aangepast. De evaluatie beoordeelt besluitvorming en samenwerking, niet hoe snel iemand een technische oorzaak raadt. Elke gevonden tekortkoming krijgt een eigenaar en een nieuwe oefen- of controledatum.
Wat moet in ieder geval zijn geregeld?
Startkaart en actuele contactgegevens zijn buiten de normale omgeving bereikbaar.
Mandaat, vervangers en externe beschikbaarheid zijn afgesproken.
Escalatiecriteria onderscheiden feiten, gevolgen en onzekerheid.
AVG-, CBW- en contractuele meldroutes zijn apart beoordeeld.
Communicatie, beslislogboek en herstelcriteria zijn voorbereid.
Een realistische oefening levert toegewezen verbeteracties op.
Deze uitleg is algemeen en vervangt geen beoordeling van uw specifieke organisatie, wettelijke positie, verwerking of incident.