Kort gezegd: Lessons learned na een IT-incident betekent: na de technische afronding komen alle betrokkenen bij elkaar, reconstrueren het verloop, benoemen zonder schuldvraag wat goed ging en wat niet, en leiden daaruit maatregelen met verantwoordelijken en data af. Dat geldt ook voor bijna-incidenten zoals een glimpflijk verlopen PHP2Shell-week. Beslissend is niet het verslag, maar de latere controle of de maatregelen zijn uitgevoerd.
Waarom de week na het incident zo belangrijk is
Als de server weer draait en de patches zijn geïnstalleerd, is de verleiding groot snel terug te keren naar het dagelijks werk. Juist dan gaat de waardevolste kennis verloren: wie merkte wanneer wat op? Waar ontbrak informatie? Welke beslissing duurde te lang? Over een paar weken weet niemand dat nog precies.
De oktoberweek van 2026 is daarvan een goed voorbeeld. Veel bedrijven hebben PHP-servers gepatcht, hosters aangeschreven, websites preventief uitgeschakeld of logs veiliggesteld. Ook als er geen inbraak is vastgesteld, zit daarin veel leerstof. Hoe lang duurde het voordat vaststond welke systemen getroffen waren? Wie moest de uitschakeling goedkeuren, en was die persoon bereikbaar?
De technische stappen na een aanval zelf behandelt de checklist na een hack. Dit artikel sluit daar op aan: wat leren we ervan?
Lessons learned bij een IT-incident: basisregels voor de nabespreking
Een nabespreking is geen tribunaal. Wie vreest dat fouten persoonlijke gevolgen hebben, vertelt maar het halve verhaal. Daarom geldt het principe: we zoeken oorzaken in processen, hulpmiddelen en informatie, niet naar schuldigen. Mensen hebben gehandeld met de kennis die ze op dat moment hadden.
Nodig iedereen uit die erbij betrokken was, ook externen zoals hoster, bureau of dienstverlener, voor zover mogelijk. Plan twee uur in. Vraag vooraf om materiaal: tickets, chatverlopen, e-mails, notities, loguittreksels. Daaruit ontstaat de tijdlijn, de ruggengraat van de bespreking. Hoe u die zorgvuldig opbouwt, beschrijft De tijdlijn van een incident opstellen.
De moderatie moet niet worden overgenomen door de persoon die het incident operationeel heeft geleid. Die zou anders zijn eigen beslissingen beoordelen. Neutraal is bijvoorbeeld iemand van een andere afdeling of een externe partner.
Het verloop in zes stappen
- Tijdlijn presenteren: wat gebeurde wanneer, van de eerste melding tot de afronding? Lacunes in de tijdlijn markeren, niet raden.
- Wat ging goed? Begin bewust met het positieve. Dat laat zien wat behouden moet blijven en ontspant de ronde.
- Waar haperde het? Elke vertraging, elke ontbrekende informatie, elke onzekerheid wordt verzameld, eerst zonder discussie over oplossingen.
- Oorzaken ophelderen: voor de belangrijkste punten vraagt u herhaaldelijk naar het waarom. „De patch kwam laat“ is een bevinding, „niemand wist dat op de oude server nog PHP draait“ is een oorzaak.
- Maatregelen vastleggen: bij elke oorzaak een concrete maatregel, een verantwoordelijke persoon en een datum.
- Nacontrole afspreken: een afspraak over vier tot acht weken, waarop wordt gecontroleerd wat is uitgevoerd.
Typische vragen en maatregelen na een PHP-situatie
De volgende tabel toont vragen die zich na een situatie als PHP2Shell vaak voordoen, en mogelijke antwoorden in de vorm van maatregelen. Niet elke past bij elk bedrijf; ze is bedoeld om de blik te scherpen.
| Vraag in de nabespreking | Typische bevinding | Mogelijke maatregel |
|---|---|---|
| Hoe hoorden we van het lek? | Toevallig uit het nieuws | Beveiligingsmeldingen van php.net en BSI gericht abonneren |
| Wisten we welke systemen getroffen waren? | Lijst onvolledig, oud systeem vergeten | Inventaris van alle websites en servers met PHP-versie |
| Wie mocht over de uitschakeling beslissen? | Onduidelijk, beslissing vertraagd | Beslissingsbevoegdheid in het noodplan vastleggen |
| Heeft de hoster de patch bevestigd? | Alleen mondeling of helemaal niet | Schriftelijke bevestiging opvragen, contract aanvullen |
| Zijn alle PHP-processen herstart? | Niet gecontroleerd | Herstart en controle als vaste stap opnemen |
| Waren logs vanaf 20 oktober beschikbaar? | Deels al overschreven | Bewaartermijn verlengen, logs centraal veiligstellen |
| Hoe verliep de communicatie naar binnen en buiten? | Medewerkers hoorden het uit de pers | Interne eerste informatie voorbereiden |
Leg ook vast wat u bewust niet verandert. Soms is een bevinding bekend, maar zou de maatregel onevenredig zijn. Een gedocumenteerde beslissing is beter dan stilzwijgend vergeten.
Scheid in het verslag bewezen feiten, waarschijnlijke aannames en open vragen. Juist na PHP2Shell, waarvoor geen gepubliceerde, bevestigde Indicators of Compromise bestaan, is deze scheiding belangrijk.
Van verslag naar verandering
Het meest voorkomende falen van lessons learned is banaal: het verslag wordt verstuurd en dan gebeurt er niets. Drie gewoonten helpen daartegen. Ten eerste hoort elke maatregel in het systeem waarin toch al wordt gewerkt, dus ticketsysteem of takenlijst, niet in een afzonderlijk document. Ten tweede krijgt de nacontrole een vaste afspraak in de agenda van de directie. Ten derde vloeien de resultaten door in noodplan, contactlijst en oefeningen.
Wie de inzichten wil toetsen zonder op het volgende echte incident te wachten, kan ze doorspelen in een noodoefening aan tafel. En waar de nabespreking laat zien dat updates te veel van het toeval afhingen, loont de ombouw naar patchbeheer als proces.
Voor gegevensbescherming, verzekering en eventueel instanties is het eindverslag bovendien een belangrijk document. De juridische beoordeling, bijvoorbeeld of een melding volgens art. 33 AVG nodig was, hoort echter bij de functionaris voor gegevensbescherming of een advocaat, niet in de technische nabespreking.
Hoe helpt PHP SOS concreet?
- Wij stellen uit logs, tickets en notities een tijdlijn van het incident op en markeren lacunes.
- Wij modereren de nabespreking als neutrale partij en letten erop dat oorzaken in plaats van schuldigen worden gezocht.
- Wij vertalen technische bevindingen naar maatregelen met inspanningsraming en prioriteit.
- Wij begeleiden de nacontrole en voeren technische maatregelen op verzoek zelf door, zoals voorzien in onze incident response.
Conclusie
Een incident is al duur genoeg. Wie het niet evalueert, betaalt de volgende keer opnieuw. Een eerlijke nabespreking zonder schuldvraag, een nette tijdlijn en maatregelen met naam en datum maken van een moeilijke week een blijvende winst aan veiligheid.
Veelgestelde vragen
Wanneer moet de lessons-learned-bespreking plaatsvinden?
Wanneer het incident technisch is afgerond, maar de herinnering nog vers is. In de praktijk werkt een afspraak ongeveer een tot twee weken na afronding goed. Eerder ontbreekt vaak de afstand, later vervagen de details.
Moet er ook na een bijna-incident een nabespreking komen?
Het loont. Een situatie als PHP2Shell, waarbij uiteindelijk niets is gebeurd, laat toch zien waar processen haperden. Deze inzichten zijn bijzonder waardevol, omdat ze zonder schade zijn ontstaan.
Wie leidt de nabespreking?
Bij voorkeur iemand die het incident niet zelf operationeel heeft geleid. Zo blijft de moderatie neutraal en hoeft niemand zijn eigen beslissingen te verdedigen. Dat kan ook een externe dienstverlener zijn.
Wat gebeurt er met de resultaten?
Elk inzicht wordt een maatregel met een verantwoordelijke persoon en een datum. Noodplan, contactlijst en documentatie worden aangepast. Na enkele weken controleert iemand wat daadwerkelijk is uitgevoerd.