# Noodoefening aan tafel: een webserverincident doorspelen

> Tabletop-oefening voor IT: speel een webserverincident aan tafel door, met draaiboek, rollen, injecties en een evaluatie die iets verandert.

Bron: https://phpsos.de/nl/blog/notfalluebung-am-tisch/  
Stand: 25-10-2026  
Aanbieder: PHP SOS, PHP-noodhulp en serverbeveiliging. Directe hulp via WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wij%20hebben%20hulp%20nodig%20met%20onze%20PHP-server.%20Bedrijf%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort gezegd:** Een tabletop-oefening in de IT speelt een beveiligingsincident aan tafel door: een moderator geeft stap voor stap nieuwe informatie over de situatie, de deelnemers beslissen zoals in een noodgeval, en aan het eind ligt er een lijst met concrete verbeteringen. Voor webservers is een scenario naar het voorbeeld van PHP2Shell geschikt, omdat het techniek, beslissingen onder onzekerheid, gegevensbescherming en communicatie tegelijk raakt.

## Waarom een plan pas werkt door oefenen

Veel bedrijven hebben inmiddels een noodplan. Of het werkt, blijkt pas als iemand het onder tijdsdruk gebruikt. Staat het juiste telefoonnummer erin? Weet de directie dat zij over een uitschakeling moet beslissen? Kent de dienstverlener de toegangen? Zulke vragen beantwoordt een oefening aan tafel in enkele uren.

De oktoberweek van 2026 liet zien hoe snel een situatie kan escaleren: voorafgaande aankondiging door php.net op 20 oktober, patches op 21 oktober om 16.00 uur Duitse tijd, BSI-waarschuwingsniveau Oranje (BSI: Duitse federale dienst voor informatiebeveiliging), uitschakeling van openbare websites volgens mediaberichten. Wie dit verloop vooraf eens had geoefend, hoefde minder te improviseren. Het verloop in detail beschrijft de [chronologie van PHP2Shell](https://phpsos.de/nl/ratgeber/php2shell-chronologie/). Hoe u het plan zelf opbouwt, leest u onder [IT-noodplan voor webservers opstellen](https://phpsos.de/nl/compliance/notfallplan-erstellen/); hier gaat het om het oefenen.

## Tabletop-oefening in de IT: rollen en voorbereiding

Een goede oefening heeft weinig materiaal nodig, maar duidelijke rollen. De **moderator** leidt door het draaiboek, speelt informatie in en bewaakt de tijd. Hij of zij discussieert niet mee, maar stelt vragen. Een **notulist** noteert beslissingen, open vragen en elk moment waarop iemand zegt „dat zou ik nu niet weten“. Optioneel observeert nog iemand hoe de communicatie verloopt.

De **deelnemers** zijn de mensen die in een noodgeval daadwerkelijk handelen: directie, interne IT of externe dienstverlener, functionarissen voor gegevensbescherming, communicatie, zo nodig inkoop of juridische zaken. Belangrijk is dat vervangers erbij zijn, want incidenten houden zich niet aan vakantieplanningen.

Tot de voorbereiding horen: het actuele noodplan op papier, de contactlijst, een overzicht van de websites en servers en een ruimte zonder onderbrekingen. Spreek vooraf af dat het om leren gaat, niet om cijfers. Wie bang is zich te blameren, zegt niet wat hij niet weet.

## Een kant-en-klaar draaiboek: kritiek PHP-lek op vrijdagmiddag

Het volgende scenario is fictief, maar volgt het patroon van een echte situatie. Pas systemen en namen aan uw omgeving aan. Elke injectie krijgt tien tot twintig minuten discussie.

| Stap | Injectie van de moderator | Kernvraag aan de ronde |
|---|---|---|
| 1 | De vakpers meldt een kritiek lek in PHP, patches zijn aangekondigd maar er nog niet. | Wie hoort dit als eerste, en wie moet worden geïnformeerd? |
| 2 | De patches verschijnen in de middag. Het BSI adviseert direct bijwerken, anders tijdelijke uitschakeling. | Welke van onze systemen zijn getroffen, en hoe weten we dat? |
| 3 | De hoster laat niets van zich horen. Een eigen server draait met een PHP-versie zonder officiële update. | Patchen, uitschakelen of afwachten, en wie beslist dat? |
| 4 | De shop moet in het weekend een actie draaien. Verkoop dringt erop aan niets uit te schakelen. | Hoe wegen we omzet en risico af, en hoe documenteren we de beslissing? |
| 5 | Een beheerder vindt op maandag een onbekend PHP-bestand in de uploadmap. | Wat doen we eerst, wat laten we bewust na? Wie zet bewijs veilig? |
| 6 | Het is onduidelijk of klantgegevens zijn weggelekt. | Wie beoordeelt een mogelijke meldplicht, en wanneer loopt de termijn? |
| 7 | Een journaliste vraagt waarom de website offline is. | Wie spreekt naar buiten, en wat zeggen we zolang we weinig weten? |

Stap 6 raakt de AVG. In de oefening volstaat het de procedure te verhelderen: wie de functionarissen voor gegevensbescherming erbij betrekt en wanneer. De juridische beoordeling blijft bij vakmensen; de hoofdlijnen over de termijn staan in art. 33 AVG.

## Typische inzichten en hoe u ze vastlegt

Bepaalde lacunes duiken bij bijna elke eerste oefening op. Er ontbreekt een volledige lijst van welke websites op welke servers met welke PHP-versie draaien. De contactgegevens van de hoster zijn verouderd of staan alleen in een mailbox die in een noodgeval niet bereikbaar is. Niemand weet zeker of de directie een uitschakeling zelf mag bevelen of dat iemand moet instemmen.

Leg elk inzicht in drie delen vast: wat hebben we vastgesteld, wat veranderen we en wie doet dat voor wanneer. Een inzicht zonder verantwoordelijke blijft volgens ervaring liggen. Orden de punten naar effect: een ontbrekend noodnummer is snel verholpen en helpt direct, een nieuwe monitoringoplossing vraagt planning.

Voor de gestructureerde evaluatie na de oefening is dezelfde aanpak geschikt als na een echt incident. Die staat beschreven in het artikel [Lessons learned: beter worden na het incident](https://phpsos.de/nl/blog/lessons-learned-nach-vorfall/). De contactlijst, die in de oefening meestal zwakke plekken toont, behandelt [Noodcontacten: wie moet wanneer worden geïnformeerd?](https://phpsos.de/nl/blog/notfallkontakte-liste/).

> **Tip:**
> Herhaal de oefening na zes tot twaalf maanden met een ander scenario, bijvoorbeeld een gehackte website met doorverwijzing naar vreemde sites. Zo controleert u of de maatregelen uit de eerste ronde echt zijn doorgevoerd.

## Hoe helpt PHP SOS concreet?

1. Wij passen het draaiboek aan op uw werkelijke websites, servers en dienstverleners en bereiden de injecties voor.
2. Wij modereren de oefening op afstand of per videoconferentie en houden ons met oordelen terug totdat de ronde heeft besloten.
3. Wij leveren daarna een verslag met inzichten, maatregelen, verantwoordelijken en data.
4. Op verzoek oefenen we daarna het technische deel, dus inventarisatie, patch en sporenonderzoek, zoals onze [incident response](https://phpsos.de/nl/leistungen/incident-response/) dat in een noodgeval afwerkt.

## Conclusie

Een noodoefening aan tafel is de goedkoopste manier om de zwakke plekken van een noodplan te vinden voordat een echt incident dat doet. Een middag, een realistisch draaiboek en een eerlijke evaluatie volstaan voor het begin. Beslissend is dat uit elk inzicht een taak met naam en datum wordt.


## Veelgestelde vragen

**Wat is een tabletop-oefening?**  
Een oefening waarbij de betrokkenen een incident gezamenlijk aan tafel doorspreken, zonder aan echte systemen te werken. Een moderator speelt stap voor stap nieuwe informatie in, de groep beslist en motiveert. Zo worden lacunes in plan, verantwoordelijkheden en contactlijsten zichtbaar.

**Wie moet aan een noodoefening deelnemen?**  
Iedereen die in een noodgeval beslist of handelt: directie, IT of dienstverlener, gegevensbescherming, communicatie en, indien aanwezig, de verantwoordelijke voor verzekeringskwesties. Meer dan acht tot tien personen maken de ronde log.

**Hoe lang duurt een tabletop-oefening?**  
Voor een eerste doorloop volstaan twee tot drie uur inclusief evaluatie. Belangrijker dan de lengte is dat de resultaten worden vastgelegd en maatregelen met een datum worden toegewezen.

**Moet het scenario realistisch zijn?**  
Het moet bij uw omgeving passen, maar hoeft niet tot in detail te kloppen. Een scenario naar het voorbeeld van een echte situatie zoals PHP2Shell oogt geloofwaardig en richt de discussie op beslissingen in plaats van technische details.

## Bronnen

- [BSI (Duitse federale dienst voor informatiebeveiliging): informatie over noodmanagement](https://www.bsi.bund.de/)
- [php.net: beveiligingsmeldingen](https://www.php.net/)
- [AVG, art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)