Kort gezegd: Een lijst van IT-noodcontacten noemt voor elke rol een persoon met vervanger, de bereikbaarheid ook buiten kantooruren, de aanleiding waarbij die persoon wordt geïnformeerd en de gegevens die bij het telefoontje klaar moeten liggen. De lijst ligt uitgeprint en op een afzonderlijk apparaat, wordt regelmatig getest en bevat ook instanties met meldtermijnen. Zo gaat er in een noodgeval geen tijd verloren met zoeken.
Het nummer dat niemand heeft
Een vrijdagavond, de shop toont vreemde doorverwijzingen, de beheerder heeft een vermoeden. Wat nu? De hoster bellen, maar welk nummer geldt buiten kantooruren en welk klantnummer is nodig? Het bureau, maar wie daar heeft toegang tot de server? De verzekering, maar waar staat het polisnummer? En wie beslist of de shop offline gaat?
Zulke momenten kennen veel bedrijven, en de PHP2Shell-week heeft ze vermenigvuldigd. Het noodplan ligt in het beste geval klaar, maar de contactlijst daarin is vaak de zwakste schakel: verouderd, onvolledig of alleen digitaal opgeslagen op precies het systeem dat op dat moment niet beschikbaar is. Hoe het plan als geheel is opgebouwd, beschrijft IT-noodplan voor webservers opstellen. Hier gaat het om de lijst zelf.
Wie hoort op de lijst van noodcontacten?
De volgende tabel ordent de typische contacten naar de aanleiding waarbij ze worden geïnformeerd en noemt wat u bij het eerste contact klaar moet hebben.
| Contact | Wanneer informeren | Wat klaarhouden |
|---|---|---|
| Noodleiding (vaak directie) | bij elk vermoeden van een incident | korte situatie, eerste inschatting |
| IT-verantwoordelijken en beheerders | direct, voor technische controle | getroffen systemen volgens inventaris |
| Hoster (noodkanaal) | bij vermoeden op de server, voor uitschakeling of logs | klantnummer, contractnummer, wachtwoord voor de support |
| Bureau of ontwikkelaar | als de toepassing getroffen is | projectnaam, toegangen, contactpersoon |
| IT-beveiligingsdienstverlener | bij bevestigde of waarschijnlijke inbraak | waarnemingen tot nu toe, tijdstippen |
| Functionaris voor gegevensbescherming | zodra persoonsgegevens getroffen kunnen zijn | soorten gegevens, periode, systemen |
| Cyberverzekering | volgens de polisvoorwaarden, meestal vroeg | polisnummer, schademeldroute |
| Juridisch adviseur | bij meldplichten, afpersing, aansprakelijkheid | stand van zaken, tot nu toe genomen stappen |
| Toezichthouder voor gegevensbescherming | bij meldingsplichtige datalek, indien mogelijk binnen 72 uur | gegevens volgens art. 33 lid 3 AVG |
| Zentrale Ansprechstelle Cybercrime (ZAC, Duits aanspreekpunt cybercrime van de politie) | bij aangifte van een strafbaar feit | bewijzen, tijdlijn |
| BSI | bij meldplicht volgens NIS2 | volgens de richtlijnen van het BSI |
| Communicatie | vóór elke informatie naar buiten | afgestemde feiten |
Het bevoegde ZAC vindt u via de politie van uw deelstaat; hoe de aangifte verloopt, leest u onder Aangifte doen: Zentrale Ansprechstellen Cybercrime. Welke termijnen en verplichtingen verzekeringen doorgaans stellen, beschrijft Cyberverzekering: wat bij schade telt.
Wat elke vermelding moet bevatten
Een naam en een telefoonnummer volstaan niet. Een volledige vermelding beantwoordt zes vragen:
- Rol: waarvoor is de persoon verantwoordelijk, wat mag hij of zij beslissen?
- Naam en vervanger: wie springt bij als de eerste persoon niet bereikbaar is?
- Bereikbaarheid: telefoon, ook mobiel, en een tweede weg. Geldt het nummer ook 's nachts en in het weekend?
- Aanleiding: bij welke gebeurtenis wordt deze persoon geïnformeerd?
- Legitimatie: klantnummer, contractnummer, supportwachtwoord, zodat het telefoontje niet strandt op de identiteitscontrole.
- Stand: wanneer is de vermelding voor het laatst gecontroleerd?
Vooral punt 5 wordt vaak onderschat. Hosters en registrars controleren aan de telefoon of de beller bevoegd is, en terecht. Wie eerst het klantwachtwoord moet zoeken, verliest kostbare tijd. Bewaar zulke gegevens veilig, maar zo dat de noodleiding er in een noodgeval bij kan.
Neem telefoonnummers van dienstverleners over uit het contract of van de officiële website, nooit uit een e-mail. Oplichters gebruiken bekende beveiligingssituaties graag voor valse berichten met „noodnummers“.
De volgorde in een noodgeval
Niet alle contacten zijn tegelijk nodig. Een gefaseerde aanpak heeft zich bewezen: eerst noodleiding en techniek, zodat een eerste inschatting ontstaat en over beperking van de schade kan worden besloten. Daarna hoster, bureau en beveiligingsdienstverlener voor het technische werk. Zodra persoonsgegevens getroffen kunnen zijn, de functionaris voor gegevensbescherming, want vanaf het bekend worden van een datalek loopt de termijn van art. 33 AVG. Verzekering en juridisch adviseur volgen vroeg, voordat belangrijke besluiten vallen. Communicatie naar buiten komt als laatste en alleen met afgestemde feiten.
Welke stappen na de eerste alarmering volgen, vat de checklist na een hack samen. Deze pagina geeft algemene aanwijzingen; meldplichten en juridische vragen regelt u met de functionaris voor gegevensbescherming en een advocaat.
Plan bovendien een tweede communicatiekanaal in. Is de mailserver getroffen of bestaat het vermoeden dat een aanvaller interne mailboxen meeleest, dan moet het overleg via een afzonderlijk kanaal lopen, bijvoorbeeld per telefoon of via een vooraf ingerichte groep op een andere dienst. Leg dit kanaal vooraf vast en neem het op in de lijst. In een noodgeval een nieuwe weg zoeken kost tijd en zorgt voor onzekerheid over welk bericht echt is.
De lijst levend houden
Contactlijsten verouderen onopgemerkt. Medewerkers wisselen, dienstverleners wijzigen noodnummers, contracten lopen af. Plan daarom twee vaste controlemomenten per jaar en een aanleidingsmoment bij elke wijziging. Een kort testtelefoontje buiten kantooruren laat het betrouwbaarst zien of een noodkanaal echt werkt. Vraag daarbij ook of de persoon weet dat hij of zij op de lijst staat en wat er in een noodgeval van hem of haar wordt verwacht.
Hoe helpt PHP SOS concreet?
- Wij stellen samen met u de lijst van technische noodcontacten op en controleren of hosters en bureaus werkelijk een noodkanaal hebben.
- Wij leggen vast welke gegevens per contact klaar moeten liggen, zodat een telefoontje direct effect heeft.
- Wij begeleiden een testrun van de alarmering en verwerken de lacunes in uw documenten.
- In een noodgeval staan wij als technisch aanspreekpunt via incident response op uw lijst.
Conclusie: Een goede contactlijst is kort, volledig en getest. Ze bepaalt of de eerste uren van een incident met handelen of met zoeken verstrijken.
Veelgestelde vragen
Wie hoort op een lijst van IT-noodcontacten?
Intern directie, IT, functionaris voor gegevensbescherming en communicatie, extern hoster, bureau, IT-beveiligingsdienstverlener, cyberverzekering, juridisch adviseur, de bevoegde toezichthouder voor gegevensbescherming en het aanspreekpunt cybercrime van de politie, bij NIS2-plicht aanvullend het BSI.
Waar bewaar ik de noodcontacten?
Op minstens twee plaatsen, waarvan een zonder de eigen IT bereikbaar is, bijvoorbeeld uitgeprint in de noodmap en op een afzonderlijk apparaat. Een lijst die alleen in de mailbox of op de getroffen server staat, is in een noodgeval niet beschikbaar.
Hoe vaak moet de lijst worden gecontroleerd?
Minstens twee keer per jaar en na elke wisseling van personeel of dienstverlener. Een kort testtelefoontje laat zien of nummers kloppen en of de personen weten dat ze op de lijst staan.
Moet de toezichthouder voor gegevensbescherming altijd worden geïnformeerd?
Niet bij elk incident. Art. 33 AVG vereist een melding bij een inbreuk op de beveiliging van persoonsgegevens, indien mogelijk binnen 72 uur, tenzij de inbreuk waarschijnlijk geen risico voor de betrokkenen inhoudt. De beoordeling maakt u samen met de functionaris voor gegevensbescherming; deze pagina is geen juridisch advies.