Das Zertifikat hing noch an der Wand. Der Angreifer war trotzdem drin.
Ein mittelgroßes Pharmaunternehmen in Süddeutschland. ISO 27001 zertifiziert seit zwei Jahren, re-zertifiziert im Frühjahr. Das ISMS war sauber dokumentiert, die Checklisten vollständig ausgefüllt, der Auditor zufrieden. Der CISO präsentierte das Zertifikat beim Jahresgespräch mit der Geschäftsleitung als Beleg für die Reife ihrer Sicherheitsarchitektur.
Drei Monate später beauftragten sie ein Red Team. Das Ergebnis des Physical Pentests: Zugang zum Serverraum in 31 Minuten. Kein Exploit. Keine Zero-Day-Lücke. Ein gefälschter Termin, ein Badge ohne Foto und eine Dachluke, die im letzten Audit als „baulich abgesichert" dokumentiert worden war – tatsächlich aber mit einem handelsüblichen Vorhängeschloss gesichert war, das in zwei Minuten geöffnet ist.
Der Auditor hatte die Dachluke nicht angeschaut. Er hatte das Dokument geprüft, das sie beschrieb.
Ein ISO-27001-Audit ist kein Beweis dafür, dass Angriffe scheitern. Es ist ein Beweis dafür, dass Prozesse dokumentiert und Policies verabschiedet wurden. Das ist nicht dasselbe – und der Unterschied kann existenzbedrohend sein.
Was ISO 27001 leistet – und was es strukturell nicht leisten kann
ISO 27001 ist kein schlechter Standard. Er ist ein falsches Versprechen – nicht weil der Standard selbst lügt, sondern weil er systematisch missverstanden wird. Von Geschäftsleitungen, die ein Zertifikat als Sicherheitsbeweis interpretieren. Von CISOs, die Compliance-Budgets mit Sicherheitsbudgets gleichsetzen. Und manchmal von Auditoren, die Systeme prüfen, die sie nie selbst angreifen würden.
Was ISO 27001 tatsächlich prüft: ob ein Informationssicherheits-Managementsystem (ISMS) existiert, ob Risiken dokumentiert sind, ob Maßnahmen beschlossen wurden und ob ein Prozess zur Verbesserung definiert ist. Was der Standard explizit nicht prüft: ob diese Maßnahmen unter echten Angriffsbedingungen halten.
Der strukturelle Unterschied: Dokumentenprüfung vs. empirischer Test
Das ist kein Widerspruch, der eine Methode überflüssig macht. ISO 27001 und ein Physical Pentest beantworten schlicht unterschiedliche Fragen. Das Problem entsteht, wenn ein CISO nur die erste Frage stellt – und die zweite für beantwortet hält.
Ein Zertifikat zeigt, dass du einen Prozess gebaut hast. Ein Pentest zeigt, ob der Prozess funktioniert. Kein noch so detailliertes Risikoregister hat je eine offene Dachluke gefunden.
Die fünf Lücken, die jeder Auditor übersieht – und jeder Angreifer findet
Das liegt nicht am Versagen einzelner Auditoren. Es liegt am methodischen Rahmen. Ein ISO-Auditor ist darauf ausgelegt, Systeme und Dokumente zu prüfen – nicht, Gebäude zu kompromittieren. Die folgenden fünf Kategorien tauchen deshalb regelmäßig in Physical-Pentest-Berichten auf, obwohl das ISMS der Kunden „vollständig" war.
1. Die bauliche Realität entspricht nicht der Dokumentation
Grundrisspläne und Sicherheitskonzepte werden einmalig erstellt – und dann selten aktualisiert. Umbauten, neue Mietbereiche, temporäre Zugänge oder Wartungsöffnungen finden ihren Weg nicht ins ISMS. Ein Auditor, der den Grundriss prüft, sieht das Gebäude von vor drei Jahren. Ein Angreifer sieht das Gebäude von heute.
Typische Lücken: Dachluken, die für Klimaanlagen geöffnet wurden und nie wieder gesichert wurden. Zwischenwände, die Sicherheitszonen verbinden, die laut Dokumentation getrennt sind. Lieferanteneingänge, die ursprünglich temporär waren und sich in dauerhafte Zugänge verwandelt haben.
2. Technische Maßnahmen werden nicht auf Umgehbarkeit geprüft
Ein RFID-Lesegerät am Serverraum steht im ISMS als „physische Zutrittskontrolle – umgesetzt". Ob das Lesegerät über das veraltete Wiegand-Protokoll kommuniziert und damit in Sekunden klonbar ist, steht nicht in der Dokumentation. Ob die dahinterliegende Tür bei Stromausfall fail-safe öffnet, auch nicht. Ein Auditor prüft die Existenz der Maßnahme. Ein Angreifer prüft ihre Wirksamkeit.
3. Der menschliche Faktor wird mit Policies abgehandelt
„Mitarbeiter sind zur Einhaltung der Clean-Desk-Policy verpflichtet" – Punkt, abgehakt. Ob die Policy gelebt wird, ob Escort-Pflichten im Alltag durchgesetzt werden, ob das Empfangspersonal einen Pretext-Angriff erkennt: Das steht nicht in einer Checkbox. Ein Visitor-Management-Angriff funktioniert nicht trotz ISMS – er funktioniert, weil ISMS und gelebte Realität auseinanderdriften.
4. REX-Sensoren, Notausgänge und Blind Spots sind Systemkenntnisse
Einen REX-Sensor-Angriff oder das Tailgating durch einen Notausgang findet kein Auditor mit einer Checkliste. Diese Vektoren erfordern Systemkenntnisse über Zutrittskontrollarchitekturen und die Bereitschaft, sie aktiv auszuprobieren. Auditoren haben weder das Mandat noch die Erwartungshaltung, dies zu tun.
5. OSINT-Exposition wird unterschätzt
Grundrisspläne auf Behördenseiten, Stellenanzeigen die Zutrittssysteme nennen, LinkedIn-Profile die Wartungsdienstleister verraten: Diese Informationen liegen offen, sind aber kein Teil einer typischen ISO-Prüfung. Ein Angreifer verbringt 48 Stunden mit OSINT, bevor er das Gebäude betritt. Ein Auditor verbringt diese Zeit mit Dokumentenprüfung.
Die gefährlichste Aussage nach einem ISO-Audit lautet: „Wir haben alles geprüft." Tatsächlich wurde alles dokumentiert. Das ist eine andere Aussage – mit potenziell erheblichen Konsequenzen.
Was passiert, wenn ein Angreifer das ISMS gelesen hat
Ein gut dokumentiertes ISMS liefert einem Angreifer bei Exfiltration präzise Informationen: Welche Zonen als kritisch eingestuft sind. Welche Maßnahmen umgesetzt wurden. Welche Risiken bewusst akzeptiert wurden. Das Dokument, das Compliance nachweist, beschreibt gleichzeitig die Architektur, die umgangen werden soll.
Das ist kein Argument gegen Dokumentation. Es ist ein Argument dafür, Dokumentation und empirischen Test als komplementäre Methoden zu behandeln – nicht als Alternativen.
Die wirtschaftliche Argumentation: Was kostet ein Test im Vergleich zum Risiko?
Die häufigste Einwand, den CISOs gegenüber Physical Pentests bringen: „Wir haben gerade erst das ISO-Audit absolviert, das Budget ist ausgeschöpft." Das ist eine nachvollziehbare Prioritätsentscheidung – aber sie beruht auf einer falschen Prämisse: dass Compliance-Kosten und Sicherheitskosten dasselbe Budget adressieren.
Ein ISO-Audit kostet typischerweise zwischen 15.000 und 50.000 Euro. Es weist nach, dass ein Managementsystem existiert – ein Nachweis, der für Versicherungen, Geschäftspartner und Behörden relevant ist. Ein Physical Pentest kostet deutlich weniger und weist nach, ob das Managementsystem unter Angriffsbedingungen hält. Beide haben ihre Berechtigung. Keiner ersetzt den anderen.
Ein Physical Pentest kostet einen Bruchteil eines ISO-Audits – und findet Schwachstellen, die kein Auditor je dokumentieren würde. Die Frage ist nicht ob man sich einen Test leisten kann. Die Frage ist, ob man sich einen Breach leisten kann.
Was NIS2 und das KRITIS-Dachgesetz dazu sagen
Mit NIS2 (gültig seit Dezember 2025) und dem KRITIS-Dachgesetz (Januar 2026) hat sich die regulatorische Ausgangslage verändert. Beide Regelwerke fordern nachweisbare Wirksamkeit von Sicherheitsmaßnahmen – nicht nur deren Dokumentation. Artikel 21 NIS2 verlangt ausdrücklich „physische Sicherheit" als Maßnahmenbereich. Das KRITIS-Dachgesetz fordert Resilienzkonzepte, die auch physische Angriffsvektoren adressieren.
Ein ISO-Zertifikat erfüllt diese Anforderungen teilweise – aber ein Zertifikat allein ist kein Nachweis der Wirksamkeit physischer Schutzmaßnahmen. Mehr dazu im Post zu NIS2 und KRITIS-physische Compliance.
Die Scope-Frage: Wo fängt ein physischer Test an?
Die zweite häufige Frage von CISOs: „Was wird eigentlich getestet?" Viele assoziieren Physical Pentests mit dem Versuch, in den Serverraum einzubrechen – und sehen darin wenig Relevanz für ihr Threat Model. Der tatsächliche Scope ist weiter:
| Testbereich | Was geprüft wird | Typischer Fund |
|---|---|---|
| Perimeter | Zäune, Zugänge, Parkplätze, Lieferbereiche | Ungesicherte Nebeneingänge, Tailgating-Möglichkeiten |
| Empfang & Besuchermanagement | Anmeldeprozess, Badge-Ausgabe, Escort-Durchsetzung | Kein Ausweis verlangt, kein Foto auf Badge, keine Escort |
| Innenbereich | Zonentrennung, REX-Sensoren, Türkonfiguration | Fail-Safe-Türen ohne USV, klonbare RFID-Tokens |
| Kritische Zonen | Serverraum, Technikräume, Archiv, Vorstandsbereich | Badge-Zugang reicht, keine 2FA, kein Kamerasystem |
| Social Engineering | Mitarbeiterreaktionen auf Pretexts, Awareness-Level | Türen aufgehalten, Zugangsdaten telefonisch genannt |
| OSINT-Exposition | Öffentlich verfügbare Informationen über das Gebäude | Grundrisspläne, Dienstleister-Namen, Mitarbeiterstrukturen |
Scope-Checkliste: So bereitest du einen Physical Pentest vor
Ein Physical Pentest liefert nur dann verwertbare Ergebnisse, wenn der Scope sauber definiert ist. Diese Checkliste hilft CISOs, die wichtigsten Vorbereitungsschritte zu strukturieren – unabhängig davon, welches Unternehmen den Test durchführt.
Physical Pentest vorbereiten: 20 Punkte vor dem ersten Briefing
Für den internen Gebrauch – vor dem Erstgespräch mit dem Pentesting-Anbieter ausfüllen.
- Zieldefinition: Was soll der Test primär nachweisen – Zugangsresilienz, Social-Engineering-Anfälligkeit, technische Schwachstellen oder alle drei?
- Standorte: Welche Gebäude und Standorte sind im Scope? Gibt es explizit ausgeschlossene Bereiche (z.B. Produktionshallen mit laufendem Betrieb)?
- Kritische Zonen: Welche Bereiche gelten als besonders schützenswert – Serverraum, Rechenzentrum, Archiv, Vorstandsbereich, Labore?
- Black Box vs. Grey Box: Erhält das Red Team vorab Informationen (Grundriss, Dienstleisterliste, Mitarbeiterstruktur) oder wird vollständig blind getestet?
- Zeitfenster: Soll der Test zu Geschäftszeiten, außerhalb oder beides stattfinden? Nachteinbrüche testen andere Vektoren als Besuchszeiten-Angriffe.
- Eskalationsstufen: Welche Handlungen sind explizit erlaubt? Badge-Klonen, Lock Picking, Social Engineering am Telefon, USB-Drop?
- Safe Word / Abbruchprotokoll: Wie bricht das Red Team den Test ab, wenn es zur Konfrontation kommt? Wer ist 24/7 erreichbar?
- Benachrichtigungskreis: Wer im Unternehmen weiß von dem Test? Typischerweise: CISO, CFO, ggf. ein Sicherheitsbeauftragter – nicht das Empfangspersonal.
- Dokumentation des Ist-Zustands: Liegt ein aktuelles Türtyp-Inventar vor? Sind alle RFID-Systeme dokumentiert? Gibt es eine Übersicht über Sicherungskreise?
- Letzte bauliche Änderungen: Welche Umbauten, Umzüge oder neuen Zugänge gab es in den letzten 12 Monaten, die noch nicht im ISMS erfasst sind?
- Besuchermanagement-Prozess: Wer empfängt Besucher? Gibt es eine Ausweispflicht? Werden Escorts dokumentiert?
- Aktive Dienstleister: Welche externen Techniker, Reinigungsdienste oder Wartungsunternehmen haben regulären Zugang – und sind dem Empfangspersonal bekannt?
- Badge-System: Welches Zutrittssystem ist im Einsatz (RFID-Protokoll, Hersteller)? Wann wurde es zuletzt auf Schwachstellen geprüft?
- Fail-Safe-Konfiguration: Ist bekannt, welche Türen bei Stromausfall öffnen? Sind diese Türen über eine USV abgesichert?
- Kamerasystem: Wo gibt es Kameraüberwachung, wo nicht? Werden Aufzeichnungen aktiv ausgewertet oder nur im Nachgang genutzt?
- Alarmanlage & SOC: Gibt es ein SOC oder eine Leitstelle, die physische Alarme verarbeitet? Wie lange ist die durchschnittliche Reaktionszeit?
- OSINT-Selbstcheck: Google-Dork auf eigene Standorte, Stellenanzeigen und LinkedIn-Profile: Welche Informationen sind öffentlich zugänglich?
- Regulatorischer Kontext: Gilt NIS2, KRITIS-Dachgesetz oder CER für das Unternehmen? Welche Nachweispflichten müssen durch den Test erfüllt werden?
- Erwartetes Ergebnis: Was soll mit dem Bericht passiert – interne Härtung, Vorlage für Versicherung, Nachweis gegenüber Regulatoren, Boardpräsentation?
- Folge-Commitment: Ist das Budget für die Umsetzung gefundener Schwachstellen bereits eingeplant? Ein Pentest ohne Remediation-Budget ist eine Risikobestätigung ohne Risikominderung.
Fazit: Compliance ist der Beweis, dass du Hausaufgaben gemacht hast. Ein Pentest ist der Beweis, dass sie richtig waren.
ISO 27001 ist kein Fehler. Es ist ein gutes Fundament. Aber ein Fundament ist kein Gebäude – und ein Managementsystem ist keine Garantie für Resilienz. Der entscheidende Schritt, den die meisten Unternehmen nicht gehen, ist die empirische Überprüfung: Funktioniert das, was wir dokumentiert haben, auch unter echten Angriffsbedingungen?
Die Antwort darauf kann nur ein Test liefern. Kein Auditor, keine Checkliste, kein noch so detailliertes Risikoregister. Ein Angreifer interessiert sich nicht für dein Zertifikat. Er interessiert sich für die Lücke zwischen dem, was dokumentiert ist – und dem, was wirklich passiert, wenn jemand die Tür aufmacht, ohne gefragt zu werden.
Weiterführend: Was ein Angreifer vor dem ersten Schritt ins Gebäude bereits weiß, erklärt der Post zu Remote Recon to Physical Breach. Wie ein Visitor-Management-Prozess zum Einfallstor wird, zeigt der Post zum Besuchermanagement-Angriff. Und was NIS2 und KRITIS-Dachgesetz konkret von euch fordern, steht im Post zur physischen Compliance.
Wie weit klafft bei euch die Lücke zwischen Dokumentation und Realität?
Wir testen eure physische Sicherheit empirisch – mit echten Angriffstechniken, vollständiger Dokumentation und konkreten Handlungsempfehlungen. Kostenloses Erstgespräch.
Physical Pentest anfragen →