Kort gezegd: ISO 27001 en TISAX raken webservers vooral via drie eisen: kwetsbaarheden moeten worden herkend en behandeld, dienstverleners zoals hosters en bureaus moeten worden aangestuurd en beveiligingsincidenten hebben een geregeld verloop nodig. Een situatie als PHP2Shell is voor elk ISMS een praktijktest. Wie beoordeling, patch en herstart controleerbaar documenteert, heeft voor de volgende audit een goede basis. Een certificaat of label vervangt de patch niet.
Wat ISO 27001 en TISAX zijn, in twee alinea's
ISO/IEC 27001 beschrijft de eisen aan een managementsysteem voor informatiebeveiliging, kortweg ISMS. Bedoeld is een geordend circuit: risico's beoordelen, maatregelen vastleggen, uitvoeren, controleren en verbeteren. De actuele uitgave van 2022 bevat in Bijlage A een catalogus van 93 maatregelen in vier thema's. Welke daarvan gelden, beslist het bedrijf op basis van zijn risicobeoordeling en legt het vast in de verklaring van toepasselijkheid.
TISAX is het in de auto-industrie gangbare toets- en uitwisselingsmechanisme. Het wordt aangestuurd door de ENX Association; de basis is de eisencatalogus ISA, die ENX onderhoudt en de VDA publiceert. Onafhankelijke auditdienstverleners voeren een assessment uit, waarvan de omvang afhangt van de beschermingsbehoefte en dat loopt van documentcontroles tot bezoeken ter plaatse. De resultaten worden volgens ENX als labels toegekend, gelden drie jaar en worden via het ENX-portaal alleen met geselecteerde partners gedeeld.
ISO 27001 bij de webserver: welke eisen gelden?
Een webserver is in het ISMS zelden een eigen hoofdstuk. Hij komt op meerdere plaatsen voor, en juist daar ontstaan lacunes. Het volgende overzicht ordent de belangrijkste thema's in algemene zin. Het vervangt niet de blik in uw eigen verklaring van toepasselijkheid.
| Thema in het ISMS | Wat dat bij de webserver betekent | Bewijs dat bij de audit helpt |
|---|---|---|
| Inventaris van bedrijfsmiddelen | Elke website, elke server, elke PHP-versie is vastgelegd | Actuele lijst met beheerder, versie, verantwoordelijke |
| Omgang met technische kwetsbaarheden | Meldingen zoals PHP2Shell worden beoordeeld en behandeld | Ticket met beoordeling, besluit, patchdatum |
| Leveranciersrelaties | Hoster en bureau hebben duidelijke beveiligingsplichten | Contract, taakverdeling, schriftelijke bevestiging van de patchstatus |
| Logging en bewaking | Weblogs worden bewaard en geanalyseerd | Bewaarregel, voorbeeld van een analyse |
| Incidentbeheer | Vermoedens worden gemeld, beoordeeld en afgesloten | Incidentverslag, lessons learned |
| Configuratiebeheer | PHP- en webserverinstellingen zijn vastgelegd | Doelconfiguratie en controle op afwijkingen |
Bij TISAX gelden vergelijkbare thema's, omdat de ISA-catalogus is afgestemd op andere belangrijke standaarden. Daarnaast vragen sommige toetsdoelen, zoals prototypebescherming, bijzondere zorg bij systemen waarover partners gegevens uitwisselen. Dat kunnen ook portalen op PHP-basis zijn.
PHP2Shell als praktijktest voor het ISMS
Op 21 oktober 2026 heeft het PHP-project de versies 8.5.12, 8.4.27, 8.3.36 en 8.2.35 gepubliceerd. Voor PHP 8.1 en ouder bestaan geen officiële updates meer. Een functionerend ISMS moet in deze situatie een keten in gang zetten die later te bewijzen is.
- Binnenkomst: wie heeft de melding wanneer ontvangen, en waar is ze vastgelegd?
- Beoordeling: welke systemen zijn getroffen? Dat vereist een actuele inventaris, zie Weten wat er draait.
- Besluit: patch, overbruggende maatregel of tijdelijke uitschakeling, met motivering en naam van de beslissende persoon.
- Uitvoering: pakketstatus, herstart van alle PHP-processen, controle. Bij backports van de distributie telt de pakket-changelog, niet het getoonde versienummer; hoe u dat aantoont, ziet u onder PHP-versie en patchstatus juist controleren.
- Leveranciers: schriftelijke bevestiging van de hoster dat is gepatcht en herstart.
- Nacontrole: controle op tekenen van compromittering sinds 17 oktober 2026, omdat een patch eerdere inbraken niet ongedaan maakt.
Hoe u van deze eenmalige keten een duurzaam proces maakt, beschrijven Kwetsbaarhedenbeheer voor het mkb en Patchbeheer als proces.
Veelvoorkomende zwakke plekken in de documentatie
In de praktijk faalt het bewijs zelden door techniek, maar door lacunes in de keten. Typisch is een website die een vakafdeling met een bureau beheert en die in de inventaris ontbreekt. Even vaak komen hostercontracten voor zonder uitspraak over hoe snel beveiligingsupdates worden geïnstalleerd en of klanten worden geïnformeerd.
Nog een klassieker: het patchticket is gesloten, maar niemand heeft de PHP-processen herstart. Formeel is het punt afgehandeld, technisch draait de oude code door. Een goed bewijsstuk bevat daarom niet alleen „update geïnstalleerd“, maar ook de herstart en een controle daarna.
Lastig wordt het ook bij systemen die niet direct te patchen zijn, bijvoorbeeld een toepassing op PHP 8.1. Hier vraagt een ISMS geen wonderen, maar wel een bewuste beslissing: welke overbruggende maatregelen gelden, wie heeft het resterende risico geaccepteerd en tegen wanneer is de overstap gepland? Een schriftelijke risicoacceptatie met einddatum is bij de audit duidelijk beter dan een stilzwijgend doordraaiend oud systeem. Even belangrijk zijn de logs. Vakpers en vakauteurs adviseerden na PHP2Shell serverlogs vanaf 20 oktober 2026 te bewaren. Of uw bewaarregel dat toelaat en of de logs bij de hoster liggen of bij u, moet vóór het volgende incident zijn uitgezocht, niet tijdens.
Valt uw bedrijf bovendien onder NIS2, dan versterken deze eisen elkaar. De hoofdlijnen staan onder NIS2 en webserverbeveiliging. Dit is algemene informatie, geen juridisch advies.
Een certificaat of label beschrijft de toestand van een managementsysteem op het moment van toetsing. Het beschermt geen enkele afzonderlijke server tegen een nieuw lek. Beslissend is dat het proces in een noodgeval daadwerkelijk werkt.
Hoe helpt PHP SOS concreet?
- Wij leggen uw webservers en PHP-installaties zo vast dat ze in de inventaris van uw ISMS passen.
- Wij patchen en documenteren met onze PHP-patchservice: pakketstatus, herstart, controle, met datum en bewijsstukken.
- Wij formuleren de vragen aan hosters en bureaus en beoordelen hun antwoorden voor uw leveranciersbeheer.
- Wij leveren uw ISMS-verantwoordelijke de technische feiten. De beoordeling in het managementsysteem en de audit blijven bij u en uw toetsingsinstantie.
Conclusie
ISO 27001 en TISAX vereisen geen bepaalde webserver, maar wel een navolgbare omgang ermee. PHP2Shell laat zien of inventaris, kwetsbaarhedenbehandeling en leveranciersbeheer samenwerken. Wie de keten van binnenkomst, beoordeling, patch, herstart en nacontrole netjes aantoont, heeft niet alleen de audit, maar vooral de server onder controle.
Veelgestelde vragen
Valt de bedrijfswebsite binnen de reikwijdte van een ISO 27001?
Dat hangt ervan af hoe uw bedrijf de reikwijdte heeft vastgelegd. Verwerkt de website klantgegevens, is ze gekoppeld aan interne systemen of wordt ze door een dienstverlener beheerd, dan pleit veel voor opname of in elk geval vastlegging via het leveranciersbeheer.
Is TISAX een certificaat?
De ENX Association spreekt van een assessment door onafhankelijke auditdienstverleners, waarvan de resultaten als TISAX-labels worden toegekend. De labels gelden volgens ENX drie jaar en worden via het ENX-portaal gericht met partners gedeeld; ze zijn niet openbaar.
Moet ik na PHP2Shell mijn auditor informeren?
Een algemene plicht daartoe bestaat niet. Uw ISMS moet echter vastleggen hoe u het kwetsbaarheidsrisico hebt beoordeeld en behandeld. Deze documenten worden bij de volgende audit doorgaans bekeken.
Welke versie van ISO 27001 is actueel?
Maatgevend is de uitgave ISO/IEC 27001:2022. Bijlage A ordent de maatregelen in vier thema's: organisatorisch, persoonsgebonden, fysiek en technologisch.