# ISO 27001 und TISAX: Was Webserver betrifft

> ISO 27001 und TISAX am Webserver: Welche Anforderungen Patches, Lieferanten und Vorfälle betreffen und welche Nachweise nach PHP2Shell in die Akte gehören.

Quelle: https://phpsos.de/blog/iso-27001-tisax-webserver/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** ISO 27001 und TISAX betreffen Webserver über drei Anforderungen besonders: Schwachstellen müssen erkannt und behandelt werden, Dienstleister wie Hoster und Agenturen müssen gesteuert werden, und Sicherheitsvorfälle brauchen einen geregelten Ablauf. Eine Lage wie PHP2Shell ist für jedes ISMS ein Praxistest. Wer Bewertung, Patch und Neustart nachvollziehbar dokumentiert, hat für das nächste Audit eine gute Grundlage. Ein Zertifikat oder Label ersetzt den Patch nicht.

## Was ISO 27001 und TISAX sind, in zwei Absätzen

ISO/IEC 27001 beschreibt die Anforderungen an ein Informationssicherheits-Managementsystem, kurz ISMS. Gemeint ist ein geordneter Kreislauf: Risiken bewerten, Maßnahmen festlegen, umsetzen, prüfen und verbessern. Die aktuelle Ausgabe von 2022 enthält im Anhang A einen Katalog von 93 Maßnahmen in vier Themen. Welche davon gelten, entscheidet das Unternehmen auf Grundlage seiner Risikobewertung und hält es in der Erklärung zur Anwendbarkeit fest.

TISAX ist der in der Automobilindustrie verbreitete Prüf- und Austauschmechanismus. Gesteuert wird er von der ENX Association, Grundlage ist der Anforderungskatalog ISA, den die ENX pflegt und der VDA veröffentlicht. Unabhängige Prüfdienstleister führen ein Assessment durch, dessen Umfang vom Schutzbedarf abhängt und von Dokumentenprüfungen bis zu Vor-Ort-Terminen reicht. Die Ergebnisse werden laut ENX als Labels vergeben, gelten drei Jahre und werden über das ENX-Portal nur mit ausgewählten Partnern geteilt.

## ISO 27001 am Webserver: Welche Anforderungen greifen?

Ein Webserver ist im ISMS selten ein eigenes Kapitel. Er taucht an mehreren Stellen auf, und genau dort entstehen Lücken. Die folgende Übersicht ordnet die wichtigsten Themen allgemein zu. Sie ersetzt nicht den Blick in Ihre eigene Erklärung zur Anwendbarkeit.

| Thema im ISMS | Was das beim Webserver heißt | Nachweis, der im Audit hilft |
|---|---|---|
| Inventar der Werte | Jede Website, jeder Server, jede PHP-Version ist erfasst | Aktuelle Liste mit Betreiber, Version, Verantwortlichem |
| Umgang mit technischen Schwachstellen | Meldungen wie PHP2Shell werden bewertet und behandelt | Ticket mit Bewertung, Entscheidung, Patch-Datum |
| Lieferantenbeziehungen | Hoster und Agentur haben klare Sicherheitspflichten | Vertrag, Aufgabenteilung, schriftliche Bestätigung des Patch-Stands |
| Protokollierung und Überwachung | Webserver-Logs werden aufbewahrt und ausgewertet | Aufbewahrungsregel, Beispiel einer Auswertung |
| Vorfallmanagement | Verdacht wird gemeldet, bewertet und abgeschlossen | Vorfallsprotokoll, Lessons Learned |
| Konfigurationsmanagement | PHP- und Webserver-Einstellungen sind festgelegt | Soll-Konfiguration und Abweichungsprüfung |

Bei TISAX greifen vergleichbare Themen, weil der ISA-Katalog mit anderen bedeutenden Standards abgestimmt ist. Zusätzlich verlangen manche Prüfziele, etwa der Prototypenschutz, besondere Sorgfalt bei Systemen, über die Partner Daten austauschen. Das können auch Portale auf PHP-Basis sein.

## PHP2Shell als Praxistest für das ISMS

Am 21.10.2026 hat das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr. Ein funktionierendes ISMS sollte in dieser Lage eine Kette auslösen, die sich später belegen lässt.

1. **Eingang:** Wer hat die Meldung wann erhalten, und wo ist sie erfasst?
2. **Bewertung:** Welche Systeme sind betroffen? Das setzt ein aktuelles Inventar voraus, siehe [Wissen, was läuft](https://phpsos.de/blog/inventar-websites-server/).
3. **Entscheidung:** Patch, Übergangsmaßnahme oder vorübergehende Abschaltung, mit Begründung und Namen der entscheidenden Person.
4. **Umsetzung:** Paketstand, Neustart aller PHP-Prozesse, Kontrolle. Bei Backports der Distribution zählt der Paket-Changelog, nicht die angezeigte Versionsnummer; wie man das belegt, zeigt [PHP-Version und Patchstand richtig prüfen](https://phpsos.de/php2shell/php-version-pruefen/).
5. **Lieferanten:** Schriftliche Bestätigung des Hosters, dass gepatcht und neu gestartet wurde.
6. **Nachkontrolle:** Prüfung auf Anzeichen einer Kompromittierung seit dem 17.10.2026, weil ein Patch vorherige Einbrüche nicht ungeschehen macht.

Wie Sie aus dieser einmaligen Kette einen dauerhaften Ablauf machen, beschreiben [Schwachstellenmanagement für den Mittelstand](https://phpsos.de/blog/schwachstellenmanagement-mittelstand/) und [Patch-Management als Prozess](https://phpsos.de/blog/patch-management-prozess/).

## Häufige Schwachstellen in der Dokumentation

In der Praxis scheitert der Nachweis selten an der Technik, sondern an Lücken in der Kette. Typisch ist eine Website, die eine Fachabteilung mit einer Agentur betreibt und die im Inventar fehlt. Ebenso häufig sind Hosterverträge ohne Aussage dazu, wie schnell Sicherheitsupdates eingespielt und ob Kunden informiert werden.

Ein weiterer Klassiker: Das Patch-Ticket ist geschlossen, aber niemand hat die PHP-Prozesse neu gestartet. Formal ist der Punkt erledigt, technisch läuft der alte Code weiter. Ein guter Nachweis enthält deshalb nicht nur „Update eingespielt“, sondern auch den Neustart und eine Kontrolle danach.

Schwierig wird es auch bei Systemen, die sich nicht sofort patchen lassen, etwa eine Anwendung auf PHP 8.1. Hier verlangt ein ISMS keine Wunder, aber eine bewusste Entscheidung: Welche Übergangsmaßnahmen gelten, wer hat das verbleibende Risiko akzeptiert, und bis wann ist der Umstieg geplant? Eine schriftliche Risikoakzeptanz mit Ablaufdatum ist im Audit deutlich besser als ein stillschweigend weiterlaufendes Altsystem. Ähnlich wichtig sind die Logs. Fachpresse und Fachautoren rieten nach PHP2Shell, Server-Logs ab dem 20.10.2026 aufzubewahren. Ob Ihre Aufbewahrungsregel das hergibt und ob die Logs beim Hoster liegen oder bei Ihnen, sollte vor dem nächsten Vorfall geklärt sein, nicht währenddessen.

Wenn Ihr Unternehmen zusätzlich unter NIS2 fällt, verstärken sich diese Anforderungen. Die Grundzüge stehen unter [NIS2 und Webserver-Sicherheit](https://phpsos.de/compliance/nis2/). Das ist allgemeine Information, keine Rechtsberatung.

> **Wichtig:**
> Ein Zertifikat oder Label beschreibt den Zustand eines Managementsystems zum Prüfzeitpunkt. Es schützt keinen einzelnen Server vor einer neuen Lücke. Entscheidend ist, dass der Ablauf im Ernstfall tatsächlich greift.

## Wie hilft PHP SOS konkret?

- Wir erfassen Ihre Webserver und PHP-Installationen so, dass sie ins Inventar Ihres ISMS passen.
- Wir patchen und dokumentieren mit unserem [PHP-Patch-Service](https://phpsos.de/leistungen/php-patch-service/): Paketstand, Neustart, Kontrolle, mit Datum und Belegen.
- Wir formulieren die Fragen an Hoster und Agenturen und bewerten deren Antworten für Ihr Lieferantenmanagement.
- Wir liefern Ihrer ISMS-Verantwortlichen die technischen Fakten. Die Bewertung im Managementsystem und das Audit bleiben bei Ihnen und Ihrer Prüfstelle.

## Fazit

ISO 27001 und TISAX verlangen keinen bestimmten Webserver, aber einen nachvollziehbaren Umgang mit ihm. PHP2Shell zeigt, ob Inventar, Schwachstellenbehandlung und Lieferantensteuerung zusammenspielen. Wer die Kette aus Eingang, Bewertung, Patch, Neustart und Nachkontrolle sauber belegt, hat nicht nur das Audit, sondern vor allem den Server im Griff.


## Häufige Fragen

**Gehört die Unternehmenswebsite in den Anwendungsbereich einer ISO 27001?**  
Das hängt davon ab, wie Ihr Unternehmen den Anwendungsbereich festgelegt hat. Verarbeitet die Website Kundendaten, ist sie mit internen Systemen verbunden oder wird sie von einem Dienstleister betrieben, spricht viel dafür, sie einzubeziehen oder zumindest über das Lieferantenmanagement zu erfassen.

**Ist TISAX ein Zertifikat?**  
Die ENX Association spricht von einem Assessment durch unabhängige Prüfdienstleister, dessen Ergebnisse als TISAX-Labels vergeben werden. Die Labels gelten laut ENX drei Jahre und werden über das ENX-Portal gezielt mit Partnern geteilt, sie sind nicht öffentlich.

**Muss ich nach PHP2Shell meine Auditorin informieren?**  
Eine allgemeine Pflicht dazu gibt es nicht. Ihr ISMS sollte aber dokumentieren, wie Sie die Schwachstelle bewertet und behandelt haben. Diese Unterlagen werden im nächsten Audit typischerweise angesehen.

**Welche Version der ISO 27001 ist aktuell?**  
Maßgeblich ist die Ausgabe ISO/IEC 27001:2022. Ihr Anhang A ordnet die Maßnahmen in vier Themen: organisatorisch, personenbezogen, physisch und technologisch.

## Quellen

- [ENX Association: TISAX](https://www.enx.com/de-DE/TISAX/)
- [BSI: IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [PHP: Unterstützte Versionen](https://www.php.net/supported-versions.php)