Een hostingbedrijf kan melden dat PHP is bijgewerkt terwijl jij nog geen antwoord hebt op de belangrijkste bedrijfsvraag: kan mijn webshop, klantenportaal of reserveringssysteem verantwoord weer worden gebruikt? Daarvoor wil je weten welke omgeving is aangepakt, of de wijziging werkelijk actief is en welke onzekerheden nog openstaan. De melding dat een onderhoudstaak is uitgevoerd en het besluit om klanten weer toe te laten, verdienen ieder hun eigen aandacht.
De aanleiding is concreet. Op 21 oktober werden ook Nederlandse overheidswebsites preventief uitgezet vanwege twee ernstige kwetsbaarheden in PHP. De Rijksoverheid beschreef die voorzorgsmaatregel. Inmiddels zijn beveiligingsupdates beschikbaar. Het NCSC herhaalde op 22 oktober om 13.01 uur dat organisaties snel moeten bijwerken en kwetsbare systemen tot die tijd uit voorzorg offline moeten houden. Het centrum meldde op dat moment geen signalen van succesvol misbruik. Dat is een stand van het onderzoek op dat tijdstip.
Voor een kleine onderneming zit het lastige werk vaak tussen de betrokken partijen. De websitebouwer beheert de winkel, de hoster onderhoudt de server en de ondernemer moet ondertussen klanten helpen. Iedereen kan zijn eigen taak afronden, terwijl de aansluiting tussen die taken onduidelijk blijft. Juist die aansluiting bepaalt welke vraag je nu het beste stelt.
Begin met een eigenaar van de hele vraag
Wijs iemand aan die voor jouw bedrijf het overzicht houdt. Dat hoeft geen technisch specialist te zijn. Deze persoon verzamelt antwoorden, houdt de gevolgen voor klanten bij en zorgt dat een onbeantwoorde vraag bij een concrete beheerder terechtkomt. Bij een eenmanszaak ben je dat waarschijnlijk zelf. Bij een klein team kan één collega dit doen, zodat niet iedereen afzonderlijk met de helpdesk belt en verschillende versies van het verhaal terugkrijgt.
De technische uitvoering blijft bij de partij die de betreffende omgeving kan beheren. Vraag daarom wie verantwoordelijk is voor PHP op de echte productieomgeving. Een websitebouwer kan de inhoud, vormgeving en plug-ins beheren zonder toegang te hebben tot de onderliggende server. Een hostingbedrijf kan juist PHP beheren terwijl de bouwer moet controleren of maatwerk en koppelingen na de wijziging blijven werken. Een algemene onderhoudsafspraak maakt die taakverdeling niet vanzelf duidelijk.
Verbind aan ieder antwoord een systeemnaam en een verantwoordelijke. Een bericht over het hostingpakket is pas bruikbaar als duidelijk is dat jouw winkel, het klantenportaal en eventuele andere relevante onderdelen daaronder vallen. Zet ook de open punten op dezelfde plaats. Zo voorkom je dat de ondernemer uit een reeks geruststellende deelantwoorden een conclusie trekt die geen van de beheerders zelf heeft bevestigd.
Een WordPress-update is niet dezelfde handeling als PHP bijwerken
PHP verwerkt op de server opdrachten voor websites en andere toepassingen. De kwetsbaarheden kunnen daardoor ook spelen bij een website waarvan de zichtbare inhoud en het beheerscherm normaal functioneren. Welke technische inrichting je bedrijf gebruikt, moet je bij je beheerder vaststellen. Een bedrijfslogo op de website of een recente ontwerpwijziging zegt daar niets over.
WordPress licht in zijn eigen beveiligingsbericht toe dat voor deze problemen geen WordPress-update nodig of gepland is. Het gaat om de PHP-installatie. WordPress verwijst gebruikers naar hun hostingbedrijf en naar de PHP-versie die in de site-informatie staat. Die informatie kan het gesprek met de hoster helpen, maar vervangt diens bevestiging over de gebruikte serveromgeving niet.
Vraag daarom concreet welke beveiligingsupdate op welke omgeving is doorgevoerd. Een afgeronde update van een thema of plug-in beantwoordt die vraag niet. Andersom blijven gewone website-updates en onderhoud nodig; het oplossen van deze PHP-kwetsbaarheden maakt dat overige werk niet overbodig. Houd in het onderhoudsdossier herkenbaar welke wijziging bij welk probleem hoort. Dat scheelt later uitzoekwerk wanneer na een aanpassing bijvoorbeeld de betaalbevestiging of een koppeling uitvalt.
Vraag naar het toegepaste beveiligingspakket
Het PHP-project publiceerde op 21 oktober zijn beveiligingsadvies. Daarin staan PHP 8.5.12, 8.4.27, 8.3.36 en 8.2.35 als versies die de twee kwetsbaarheden verhelpen. De identificatienummers zijn CVE-2026-109618 en CVE-2026-109619. Daarmee kan je beheerder in zijn bevestiging precies aangeven om welke reparaties het gaat. Het advies betreft PHP-installaties die webverzoeken verwerken. Tijdelijke maatregelen beperken bepaalde aanvalsroutes, maar bieden volgens het project geen volledige oplossing.
Een beheerder kan ook een beveiligingspakket van een Linux-distributie of een leverancier met langdurige ondersteuning gebruiken. Daarin kunnen reparaties zijn teruggezet naar een bestaande pakketversie. Alleen een zichtbaar versienummer vergelijken met de vier genoemde PHP-versies is dan onvoldoende om te bepalen of een omgeving is bijgewerkt. Vraag de leverancier welk beveiligingspakket is toegepast en waaruit blijkt dat beide kwetsbaarheden daarmee zijn verholpen.
Voor oude installaties ontstaat een extra onderhoudsvraag. PHP 8.1 en ouder ontvangen geen reguliere ondersteuning meer van het PHP-project. Voor enkele oudere reeksen zijn vanwege deze situatie minimale broncodepatches beschikbaar gesteld. Dat betekent niet dat iedere oude hostingomgeving automatisch een normale, volledige update krijgt. Laat de beheerder uitleggen welke ondersteuning jouw installatie werkelijk heeft en wat het plan voor verdere migratie is. De ondernemer hoeft die broncode niet zelf te beoordelen.
Maak de omvang kleiner door hem eerst precies te benoemen
Begin bij de toepassingen waarmee klanten en medewerkers werken. Noteer de webshop, het portaal, de afspraakmodule en andere bedrijfskritische onderdelen. Vraag de beheerder vervolgens welke daarvan PHP gebruiken en welke overige omgevingen daarbij horen. Een ontwikkelomgeving, een oude website of een los beheerpaneel verdient een afzonderlijk antwoord wanneer die nog beschikbaar is. De naam van de onderneming is een te brede eenheid voor een technische bevestiging.
Deze inventarisatie hoeft geen ingewikkeld project te worden. Een kleine lijst met namen, beheerpartijen en actuele status helpt al om het gesprek te richten. Het technische bereik moet de beheerder aanvullen. Vermijd een zelf samengestelde veiligheidsverklaring op basis van wat jij toevallig in het controlepaneel kunt zien. Juist een vergeten nevensysteem kan buiten het gewone onderhoudsgesprek vallen.
Vraag bij een gedeeld hostingpakket hoe de bevestiging voor jouw toepassingen is afgebakend. Bij een beheerde webdienst kun je vragen welk onderdeel de leverancier zelf oplost en welke actie bij jou ligt. De juiste vervolgvraag hangt af van de afgesproken dienst. Zonder dat onderscheid kun je tijd verliezen aan instellingen die je niet kunt wijzigen, terwijl een opdracht aan de leverancier blijft liggen.
Heropeningskaart: welk antwoord ontbreekt nog?
Eigen redactionele werkkaart voor overleg met je beheerder. De kaart beantwoordt de vraag welke afspraken en onderbouwing een ondernemer vóór en na heropening verzamelt. Er worden geen onderzoeksresultaten, gemeten risico’s of automatische veiligheidsuitspraken gegeven.
Methode. Doorloop per toepassing de zes vragen. Noteer bij ieder punt de verantwoordelijke, diens bevestiging met datum en de eerstvolgende actie bij een open antwoord. Beoordeel het geheel met de beheerder; tel geen vinkjes op tot een veiligheidsscore.
| Vraag | Wie geeft antwoord? | Wat leg je vast? | Wat doe je bij een open punt? |
|---|---|---|---|
| Welke toepassingen en omgevingen vallen hieronder? | Hostingbeheerder, softwareleverancier of eigen systeembeheerder. | Namen van de toepassingen, productieomgeving en overige relevante PHP-onderdelen; betrokken beheerpartijen. | Laat de reikwijdte aanvullen. Trek uit één bijgewerkte website geen conclusie over alle andere systemen. |
| Welke beveiligingsupdate is werkelijk actief? | De partij die de PHP-installatie kan beheren. | Toegepaste PHP-release of leverancierpakket, bevestiging voor beide kwetsbaarheden, datum en betreffende omgeving. | Vraag een concrete uitvoerings- en terugkoppelafspraak. Volg de actuele NCSC-instructie voor nog kwetsbare systemen. |
| Welke vragen over de eerdere situatie zijn onderzocht? | De beheerder en zo nodig een aangewezen incidentonderzoeker. | Wie beoordeelt mogelijke eerdere toegang, welke informatie beschikbaar blijft en welke onzekerheden nog openstaan. | Laat de verantwoordelijke de vervolgstap en het gebruiksadvies toelichten; vul ontbrekend onderzoek niet zelf als afgerond in. |
| Werkt de afgesproken klantreis na de wijziging? | Websitebeheerder samen met de verantwoordelijke voor het bedrijfsproces. | Geteste functies en koppelingen, testmoment, uitkomst en afhandeling van testgegevens. | Laat fouten herstellen of bespreek een afgebakende vervolgstap. Een functionele test is geen beveiligingsonderzoek. |
| Wie neemt het besluit over gebruik en open punten? | De ondernemer of aangewezen beslisser, met technische toelichting van de beheerder. | Toepassing, besluitmoment, onderbouwing, eventuele voorwaarden en verantwoordelijke voor ieder open punt. | Bespreek expliciet of de toepassing nog gesloten moet blijven en wanneer een nieuw besluit volgt. |
| Wie controleert de hervatting en informeert klanten? | De eigenaar van het bedrijfsproces en de beheerder, ieder voor hun afgesproken deel. | Volgend controlemoment, klantboodschap, tijdelijke aanvragen en plek waar nieuwe problemen worden gemeld. | Wijs een eigenaar aan en werk tijdelijke routes bij; laat een open taak niet verdwijnen zodra de homepage bereikbaar is. |
De technische aanleiding en het updateadvies komen van het NCSC en het PHP-project. De selectie en ordening van deze zes overlegpunten zijn onze eigen uitwerking. De kaart bevat geen technische detectie, beoordeelt geen logbestanden en verklaart geen omgeving veilig. Gebruik haar om de antwoorden en verantwoordelijkheden zelf vast te leggen in je onderhoudsdossier.
Bewaar de bevestiging, niet alleen het vinkje in je takenlijst
Een bruikbaar antwoord blijft later terug te vinden. Bewaar het ticket, de datum en de naam van de betrokken omgeving. Laat vastleggen wat is uitgevoerd en wie eventuele vervolgvragen oppakt. Je hebt daarmee een dossier van afspraken en handelingen. Het dossier is geen certificaat dat alle risico’s zijn verdwenen; het helpt je wel om een vervolgbesluit op dezelfde informatie te baseren.
Vraag bijvoorbeeld of de genoemde update alleen is klaargezet of ook is toegepast op de omgeving die klanten daadwerkelijk gebruiken. De beheerder kan aangeven hoe dat is vastgesteld. Het heeft weinig zin om als ondernemer zelfstandig technische bewijsregels te verzinnen. Vraag om een begrijpelijke toelichting en, waar nodig, een verwijzing naar de leveranciersmelding waarop de beheerder zich baseert.
Beperk de gegevens die je hierbij rondstuurt. Een overzicht van systemen en hun status hoeft geen wachtwoorden, klantbestanden of geheime instellingen te bevatten. Gebruik de bestaande beveiligde contactroute van je leverancier voor gevoelige technische informatie. Een gedeelde notitie met verantwoordelijkheden kan eenvoudig blijven. Hoe minder zoekwerk er nodig is, hoe beter een collega het overzicht kan overnemen wanneer jij ondertussen klanten moet helpen.
Houd herstel en onderzoek als afzonderlijke werkzaamheden herkenbaar
Een update verhelpt de betreffende kwetsbaarheid in de installatie waarop zij goed is toegepast. Daarmee is nog niet onderzocht wat daarvoor met die omgeving is gebeurd. Bespreek met de beheerder welke beoordeling van de eerdere situatie nodig is, welke informatie beschikbaar is en welke vragen nog niet zijn beantwoord. De passende diepgang hangt af van de omgeving en wat er wordt aangetroffen.
Een kleine ondernemer kan dat onderzoek meestal niet zelf uitvoeren. Wel kun je vragen wie het doet, wanneer een eerste terugkoppeling volgt en wat een eventuele bevinding betekent voor het gebruik van het systeem. Spreek af hoe relevante informatie beschikbaar blijft voor degene die onderzoek uitvoert. Laat technische opruimacties en wijzigingen daarom met die persoon afstemmen, zodat er geen nuttige gegevens verdwijnen voordat iemand ze heeft beoordeeld.
Het NCSC meldde in de genoemde update geen signalen van succesvol misbruik. Dat betekent niet dat jouw afzonderlijke omgeving onderzocht is. Vermijd daarom zowel de conclusie dat iedere PHP-website is gehackt als de conclusie dat nader onderzoek nooit nodig kan zijn. Als er aanwijzingen voor onbevoegde toegang of betrokken persoonsgegevens naar voren komen, moeten de verantwoordelijken ook beoordelen welke verdere incident- en privacyreacties nodig zijn. De heropeningskaart voert die beoordeling niet uit.
Test de klantreis die je geld en afspraken oplevert
Na een technische aanpassing wil je weten of de toepassing nog doet waarvoor klanten haar gebruiken. Kies daarvoor samen met de beheerder een beperkt en herkenbaar testplan. Bij een webshop kunnen productkeuze, winkelmand, bestelling, betaalterugkoppeling en bevestiging bij elkaar horen. Bij een afsprakenbedrijf gaat het bijvoorbeeld om een reservering, het verwerken daarvan in de planning en de bevestiging aan de klant. Wat relevant is, volgt uit jouw eigen werkwijze.
Gebruik hiervoor passende testmogelijkheden en spreek af hoe je testgegevens herkenbaar houdt. Je wilt niet dat een proefbestelling als echte omzet wordt verwerkt of dat een testafspraak in de agenda blijft staan. Laat ook bepalen wie fouten opvangt en wie beslist of een afwijking de heropening tegenhoudt. Een algemene melding dat de homepage opent, laat nog veel van deze bedrijfshandelingen onbeantwoord.
Deze gebruikstest zegt iets over de geteste functies op dat moment. Het is geen test die bewijst dat een server niet is overgenomen of dat alle beveiligingsproblemen zijn opgelost. Leg daarom het resultaat naast de technische bevestiging en de open onderzoeksvragen. Als jouw bedrijf meerdere koppelingen gebruikt, kan iedere leverancier een eigen deel moeten bevestigen. Eén geslaagde handeling aan de voorkant maakt de hele keten nog niet beoordeeld.
Organiseer tijdelijk een werkbare route voor klanten
Een offline website raakt de onderneming op meer plaatsen dan alleen de omzetpagina. Klanten zoeken bestaande orders, medewerkers willen contactgegevens zien en een advertentie kan nog naar een niet-beschikbare dienst verwijzen. Maak daarom een kort overzicht van de werkzaamheden die tijdens de onderbreking aandacht vragen. Ons artikel over de herstelvolgorde bij een IT-storing helpt om die bedrijfsprocessen te ordenen.
Kies een tijdelijke klantboodschap die je werkelijk kunt waarmaken. Vermeld welke dienst beperkt beschikbaar is, hoe klanten een bestaande vraag kunnen stellen en wanneer je opnieuw informatie geeft. Beloof geen exacte heropeningstijd voordat de betrokken beheerder die onderbouwd kan aangeven. Je kunt ook een volgend informatiemoment afspreken als de technische eindtijd nog onzeker is. Dat maakt verwachtingen concreet zonder een herstelbelofte te verzinnen.
Voorkom dat de noodroute zelf een onoverzichtelijk systeem wordt. Wanneer je tijdelijk aanvragen per telefoon of e-mail ontvangt, leg dan vast wie die registreert en hoe ze later worden verwerkt. Vraag klanten geen betaalgegevens of gevoelige documenten via een onbeoordeelde omweg te sturen. Bij heropening moet het team weten welke tijdelijke aanvragen nog in de normale administratie moeten worden opgenomen. Anders kan technische beschikbaarheid worden gevolgd door dubbele afspraken en zoekgeraakte verzoeken.
Heropen met een benoemd besluit en een controle daarna
Spreek vooraf af wie het zakelijke besluit tot heropening neemt en welke informatie daarvoor nodig is. De ondernemer houdt zicht op klantverplichtingen en bedrijfsgevolgen; de beheerder geeft een technische toelichting op de aangepakte omgeving. Als er open punten zijn, moeten die herkenbaar bij dat besluit blijven staan. Een korte schriftelijke samenvatting voorkomt dat een voorbehoud uit een telefoongesprek later als definitieve bevestiging wordt doorgegeven.
Kies ook een moment na de heropening waarop je opnieuw controleert. Werken de belangrijkste functies onder normaal gebruik? Zijn tijdelijke meldingen aangepast? Kunnen medewerkers de achterstand op dezelfde manier verwerken? De eerste controle hoort bij de hervatting van de dienst. Eventuele verdere technische bewaking wordt door de beheerder ingericht en uitgelegd. Een ondernemer hoeft daarvoor geen eigen netwerkonderzoek te starten.
Wanneer een kritiek antwoord ontbreekt, laat dan expliciet bespreken of de betreffende toepassing nog gesloten moet blijven. De actuele NCSC-instructie over kwetsbare, niet bijgewerkte systemen hoort bij die afweging. Geef onzekerheid een eigenaar en een volgende stap. Een kwestie zonder verantwoordelijke wordt gemakkelijk meegenomen naar een later overleg, terwijl klanten er intussen al weer op vertrouwen dat de dienst volledig beschikbaar is.
Geef spoedwerk een duidelijke opdracht
Een urgente update kan extra werk vragen buiten het gewone onderhoud. Spreek dan af wie die opdracht mag geven en wat de beheerder daaronder verstaat. Gaat het om PHP bijwerken, de toepassing aanpassen, functies testen of onderzoek naar mogelijke eerdere toegang? Laat die werkzaamheden herkenbaar benoemen. Zo kan de ondernemer beoordelen welke kosten bij direct herstel horen en welke vervolgstappen nog afzonderlijk moeten worden besproken.
Vraag vooraf hoe de beheerder terugkoppelt wanneer de afgesproken inzet onvoldoende blijkt. Je kunt een bedrag of aantal uren afspreken waarvoor opnieuw overleg nodig is, zonder daarmee de technische omvang van het probleem kleiner te verklaren. Een budgetgrens geeft aanleiding tot een nieuw besluit; zij is geen bewijs dat de resterende werkzaamheden kunnen vervallen. Spreek ook af wie op dat moment bereikbaar is en kan beslissen over meerwerk of langer gesloten blijven.
Leg ten slotte vast wat je bij de terugkoppeling verwacht: de betreffende omgeving, de uitgevoerde handelingen, het resultaat en de open punten. Een factuur met alleen een algemene onderhoudsregel laat die informatie niet vanzelf zien. Deze afspraken zijn onze praktische aanbeveling voor het opdrachtgesprek. Wat al onder je bestaande overeenkomst valt, moet je met de betrokken leverancier nagaan.
Drie fictieve bedrijven, drie verschillende beheerafspraken
Neem als fictief voorbeeld een kleine webwinkel met een extern gebouwde WordPress-site. De bouwer onderhoudt de plug-ins, terwijl de hoster PHP beheert. De ondernemer vraagt de hoster om een bevestiging voor de productieomgeving en laat de bouwer daarna de afgesproken bestel- en bevestigingsroute testen. Een nog open koppeling met de voorraadadministratie krijgt een eigen verantwoordelijke. Zo komt het besluit over de winkel tot stand uit controleerbare deelantwoorden.
Stel in dit voorbeeld dat de hoster het gewone hostingpakket heeft bijgewerkt, maar dat de voorraadkoppeling op een afzonderlijke server van de bouwer draait. Het bericht dat het pakket klaar is, laat die server onbesproken. De ondernemer vraagt daarom om een apart antwoord voor de koppeling. Bij de functionele proef wordt ook nagegaan of een testbestelling precies één keer in de voorraadadministratie verschijnt. Dat is een controle op de werking van de koppeling; de beoordeling van de beveiligingsupdate blijft daarnaast bij de beheerder.
Een tweede fictief voorbeeld is een adviespraktijk die een klantenportaal als beheerde dienst afneemt. De praktijk kan de serverversie niet zelfstandig wijzigen. Zij vraagt de leverancier welke actie is uitgevoerd, voor welke onderdelen dat geldt en welk gebruiksadvies voor klanten overblijft. De praktijk legt vast hoe urgente vragen tijdens de onderbreking worden opgevangen. Een algemene statuspagina van de leverancier is een beginpunt; de toepasselijkheid op de afgenomen dienst moet wel duidelijk worden.
De praktijk besluit in dit voorbeeld om nieuwe gevoelige documenten nog niet via gewone e-mail op te vragen. Zij vertelt klanten hoe zij contact kunnen opnemen over spoed en houdt de verdere verwerking aan tot de afgesproken route beschikbaar is. De eigenaar registreert die verzoeken zonder de documenten zelf in een nieuwe noodadministratie te verzamelen. Daarmee blijft de tijdelijke afspraak uitvoerbaar zonder haastig een tweede klantendossier op te bouwen.
Een derde fictieve onderneming beheert zelf een oudere server voor een gespecialiseerde toepassing. Hier kan een snelle overstap naar een ondersteunde PHP-reeks aanpassing van de toepassing vragen. De onderneming moet met haar beheerder de beschikbare beveiligingsroute, de tijdelijke bereikbaarheid en het verdere migratiewerk bespreken. Het bestaan van een minimale broncodepatch voor een oude reeks geeft de ondernemer geen uitvoerbaar migratieplan. De heropeningskaart maakt zichtbaar welke beslissing nog voorbereiding nodig heeft.
Deze voorbeelden beschrijven verschillende taakverdelingen. Ze zeggen niets over de werkelijke staat van een specifieke hoster of een bepaald softwarepakket. Het bruikbare onderscheid is wie daadwerkelijk kan wijzigen, wie de werking beoordeelt en wie de gevolgen voor klanten beheert. Bij ieder bedrijf kunnen die rollen anders verdeeld zijn. Maak die verdeling daarom voor je eigen dienst herkenbaar voordat je de voorbeelden op jouw situatie toepast.
Maak van deze ronde een betere onderhoudsafspraak
Als de directe onderbreking is afgehandeld, kun je het overzicht gebruiken voor het volgende onderhoudsgesprek. Welke partij volgt beveiligingsmeldingen? Wie mag een spoedwijziging aanvragen? Wie neemt contact op wanneer een update invloed heeft op maatwerk? Dat zijn afspraken die ook buiten deze specifieke PHP-kwetsbaarheden waarde hebben. Leg ze zo vast dat een collega of vervanger kan zien wat er moet gebeuren.
Bespreek vooral de grens tussen het hostingpakket en het websiteonderhoud. De ene afspraak kan meer werkzaamheden omvatten dan de andere. Een onderneming die haar serverbeheer zelf heeft georganiseerd, heeft een andere taak dan een klant van een volledig beheerde dienst. Laat de leverancier uitleggen wat bij de bestaande overeenkomst hoort en wat afzonderlijk moet worden opgedragen. Uit een algemeen productlabel kun je die volledige taakverdeling moeilijk afleiden.
Gebruik het incident ook om verouderde onderdelen herkenbaar te maken. Wanneer blijkt dat een oude toepassing het normale onderhoud vertraagt, hoort daar een vervolgkeuze bij: aanpassen, vervangen of beëindigen. Geef die keuze een eigenaar en een datum voor overleg. De vertrekkaart voor clouddiensten kan helpen om de gevolgen van een eventuele overstap afzonderlijk te beoordelen. De acute beveiligingsupdate moet ondertussen een eigen, duidelijke voortgang houden.
Bronnen en verantwoording
Geraadpleegd op 22 oktober 2026, volgens de Nederlandse nieuwsdag. De oorspronkelijke PHP-waarschuwingen en beveiligingsrelease dateren van 21 oktober. Voor het actuele handelingsadvies is ook de NCSC-update van 22 oktober om 13.01 uur gelezen. Die latere wijziging wordt niet als een tweede oorspronkelijke nieuwsgebeurtenis geteld. De oorspronkelijke Rijksoverheidpagina bevat nog historische tekst over een toen verwachte update; de latere bevestiging dat patches beschikbaar zijn, is voor dit artikel gebruikt.
De heropeningskaart, werksituaties en aanbevelingen zijn eigen redactionele uitwerkingen. De drie bedrijfssituaties zijn fictief. Het onderdeel helpt verantwoordelijkheden, bewijs en vervolgstappen vast te leggen. Het vervangt geen onderzoek van een server, leveranciersbeoordeling of incidentonderzoek en geeft geen zelfstandige verklaring dat een systeem veilig is.