ISO 27001 mit 11 Leuten – und wie man kein AI-Slop-ISMS baut

Ich implementiere gerade ISO 27001 für unsere Firma. Wir sind elf Leute, und ich bin CISO, CTO und Teamlead in einem – und muss nebenbei noch operativ arbeiten und meine verrechenbaren Stunden reinholen. Eigentlich ein ziemlich beschissener Deal. ;-)

Für uns heisst das: ISO so pragmatisch wie möglich. Deshalb haben wir mit den Risiken angefangen, bevor wir uns mit den 93 Controls die Laune verdorben haben. Trotzdem ist es im KI-Zeitalter schwer, pragmatisch zu bleiben. Die Versuchung ist gross, ein AI-Slop-ISMS aufzubauen, das auf den ersten Blick schön aussieht, aber keine zwei Fragen eines Auditors übersteht, weil es reine Fassade ist.

Dieser Artikel ist mein Versuch, das Gegenteil zu bauen: ein ISMS, das klein ist, aber echt.

#Der Zwei-Fragen-Test

Jeder Baustein eines ISMS muss zwei Fragen überstehen. Genau diese zwei stellt ein Auditor früher oder später:

1. «Zeigen Sie mir, dass Sie das tun.» Nicht das Dokument, das es beschreibt – den Nachweis, dass es passiert ist. Das Protokoll, das Ticket, den Log-Eintrag, das Datum.
2. «Wer ist dafür verantwortlich – und weiss diese Person das?» Eine Rolle auf Papier reicht nicht. Die Person muss die Aufgabe kennen und erklären können.

Wenn ein Dokument diese zwei Fragen nicht übersteht, ist es Fassade. Egal, wie gut es formuliert ist.

Ein Beispiel aus unserem eigenen Aufbau. In unserem Risikomanagement-Prozess stand lange dieser Satz: «Risiken werden akzeptiert, wenn sie tolerierbar sind (z. B. ≤ 6)». Klingt nach einer Regel. Ist aber keine: ein Beispiel in Klammern, von niemandem beschlossen, und was mit einem Risiko von 9 passiert, stand nirgends. Frage 1 – «zeigen Sie mir den Entscheid» – wäre daran gescheitert.

Was wir geändert haben: Die Schwelle ist heute eine Zonenlogik mit klarer Handlungspflicht pro Zone (mehr dazu unten), und es gibt eine eigene Nachweisseite, auf der die Geschäftsleitung diese Akzeptanzkriterien mit Datum genehmigt hat. Ein Satz wurde zu einem Entscheid. Das ist der ganze Unterschied.

Dasselbe Muster bei den Rollen: In unserer SoA stand bei «Rollen und Verantwortlichkeiten» ehrlich, aber unbrauchbar: informell klar. Alle wussten, dass ich der ISMS-Verantwortliche bin. Belegt war es nirgends. Heute gibt es eine Rollenseite mit formaler Benennung durch die Geschäftsleitung.

#Warum KI das Problem verschärft

Früher war ein schlechtes ISMS wenigstens ehrlich schlecht: lückenhafte Word-Dokumente, offensichtlich kopierte Vorlagen. Heute schreibt eine KI in zehn Minuten eine Informationssicherheitsleitlinie, eine Backup-Policy und ein Rollenkonzept, die besser klingen als alles, was ein KMU je selbst formuliert hätte.

Das Problem: Dokumente sind billig geworden, Nachweise nicht. Die KI kann dir eine Policy schreiben, die einen vierteljährlichen Restore-Test vorschreibt. Den Restore-Test macht sie nicht. Und die erste Frage des Auditors wird sein: «Zeigen Sie mir den letzten.»

Typische Symptome eines AI-Slop-ISMS:

• Policies, die niemand im Team kennt – geschweige denn gelesen hat.
• Rollen und Gremien, die es in einer Firma mit elf Leuten gar nicht gibt («das Information Security Committee tagt quartalsweise»).
• Ein Risikoregister mit 150 generischen Risiken, die zur Hälfte nicht zur Firma passen.
• Prozesse, die perfekt beschrieben sind, aber noch nie durchlaufen wurden.
• Eine SoA, in der bei jedem Control «umgesetzt» steht – ohne einen einzigen Link auf einen Nachweis.

Ein Auditor erkennt das in der ersten Stunde. Er muss nur fragen.

#Wo KI wirklich hilft

Ich nutze KI beim ISMS-Aufbau intensiv – nur nicht als Autor der Wahrheit. Sinnvoll ist sie für:

• Struktur: Gliederung, Vorlagen für Dokumentköpfe, Konsistenz über viele Seiten.
• Formulierung: aus meinen Stichworten einen lesbaren Text machen – Stichworte, die beschreiben, was wir tatsächlich tun.
• Lückenanalyse: «Welche Anforderungen aus Kapitel 4–10 deckt diese Dokumentation nicht ab?»
• Auditor-Simulation: die KI als strengen Auditor einsetzen, der für jedes Control nach dem Nachweis fragt. Bei uns kamen die ersten beiden schwerwiegenden Befunde genau so: eine KI in der Rolle eines Lead Auditors, Stage-1-Dokumentenprüfung, kein Pardon. Befund 1: keine nachweisbare Freigabe der ISMS-Policy durch die Geschäftsleitung. Befund 2: kein Management-Review. Beides stimmte.
• Mapping: welche Risiken welche Controls begründen.

Meine Regel dafür: Die KI darf aufschreiben, was wir tun – nicht, was wir tun sollten. Sobald ein Text beschreibt, was in der Realität nicht passiert, ist er Fassade.

Konsequenterweise steht die KI-Nutzung selbst auch im ISMS: als eigener Eintrag im Verzeichnis der Verarbeitungstätigkeiten, mit Zweck, Datenkategorien und Auftragsverarbeitung. Wer KI fürs ISMS nutzt, sollte sie dort auch als Risiko und Verarbeitung führen.

#Risiken zuerst, Controls danach

ISO 27001 ist keine Liste von 93 Massnahmen, die man abarbeitet. Es ist ein Managementsystem: Kontext verstehen, Risiken finden, entscheiden, was man dagegen tut, und belegen, dass man es tut. Annex A ist eine Kontrollliste, damit man nichts vergessen hat – nicht der Startpunkt.

Wer mit Annex A anfängt, baut Controls für Risiken, die er gar nicht hat. Wer mit Risiken anfängt, für den wird Annex A zur Plausibilitätsprüfung, die einen Nachmittag dauert.

#Eine Risikomethode auf einer Seite

So sieht unsere aus:

• Eintrittswahrscheinlichkeit 1–5 und Auswirkung 1–5, mit einem Satz pro Stufe («mehrmals pro Jahr», «Meldepflicht nach nDSG möglich»), damit verschiedene Leute gleich bewerten.
• Risiko = Wahrscheinlichkeit × Auswirkung, also 1–25.
• Zonen statt einer einzigen Schwelle:

• Drei Stände pro Risiko: inhärent (ohne Kontrollen), aktuell (mit den umgesetzten) und Ziel (nach allen geplanten Massnahmen). Erst der Unterschied zwischen inhärent und aktuell zeigt, ob die Kontrollen etwas bringen.
• Jedes Risiko hat einen Eigner – eine Person, nicht «die IT».
• Überprüfung mindestens jährlich und nach jeder wesentlichen Änderung: neuer Dienst, neuer Lieferant, Vorfall.

Das Register selbst ist ein Jira-Projekt mit zwei Vorgangstypen: Risiko und Massnahme. Ein Risiko beschreibt, was passieren kann, eine Massnahme, was getan wird – mit eigenem Verantwortlichen und Fälligkeitsdatum. Score und Zone rechnet eine Automation aus. Die Methode steht auf einer Wiki-Seite, die Daten leben im Ticketsystem.

Das reicht. Aufwendige Methoden mit Schutzbedarf pro Asset haben ihre Berechtigung in grossen Organisationen. In einem KMU erzeugen sie vor allem Tabellen, die niemand pflegt.

#20 bis 30 echte Risiken statt 150 kopierter

Für eine kleine IT-Beratung sieht die Liste ungefähr so aus:

• Übernahme eines Mitarbeiterkontos durch Phishing (AiTM, MFA-Fatigue).
• Kompromittierung eines Admin-Kontos mit Auswirkung auf den ganzen Tenant.
• Datenabfluss über Kundenumgebungen, auf die wir zugreifen (VDI, VPN, Admin-Zugänge).
• Ransomware auf der Dateiablage – und die Backups gleich mit.
• Verlust oder Diebstahl eines Laptops oder Telefons mit Kundendaten.
• Kopfmonopol: nur eine Person kennt System X.
• Ausfall oder Sicherheitsvorfall bei einem kritischen SaaS-Anbieter.
• Nutzung von KI-Tools mit Kundendaten ohne Regeln.
• Unklares Offboarding: Ehemalige behalten Zugriffe.
• Fehlkonfiguration eines Cloud-Dienstes macht Daten öffentlich.

Jedes davon bekommt Bewertung, Eigner, bestehende Massnahmen und einen Behandlungsentscheid.

Bei uns sind es im Moment 15 Risiken und gut 50 Massnahmen. Weniger, als jede Vorlage vorschlagen würde – und das ist Absicht. Die ersten fünf stammen aus einem ersten Anlauf 2024 und waren entsprechend generisch («Datenverlust durch Malware»). Die interessanteren kamen später, aus der echten Arbeit:

• Die Zertifizierung selbst als Risiko. Wenn ein Kunde das Zertifikat erwartet und es sich verzögert, ist das ein Geschäftsrisiko – mit Wahrscheinlichkeit, Auswirkung und Eigner wie jedes andere.
• Single Point of Know-how in einem Infrastruktur-Stack, den genau eine Person wirklich versteht. Steht in keiner Vorlage, ist in jeder kleinen Firma Realität.
• Fehlende Trennung von Admin- und Alltagskonten. Kein Workshop hat das gefunden – der erste Access-Review hat es gefunden (siehe unten).

Das ist das Muster: Gute Risiken kommen aus Nachweisarbeit, nicht aus Brainstorming.

#Fassade oder echt? Die Gegenüberstellung

Der Kern dieses Artikels. Für jeden Baustein: wie die Fassade aussieht, und was dahinter stehen muss, damit er den Zwei-Fragen-Test besteht.

Die rechte Spalte lässt sich nicht generieren. Sie entsteht nur, wenn die Arbeit passiert. Genau deshalb ist sie das Einzige, was zählt.

#Ein Nachweis, der etwas gefunden hat

Unser erster Access-Review im Mai 2026 ist das beste Beispiel, warum sich die rechte Spalte lohnt. Exportiert aus Entra ID, Konto für Konto durchgegangen:

• 44 Konten für 9 aktive Mitarbeitende.
• 23 Konten ohne Anmeldung seit über 90 Tagen – oder noch nie.
• 16 aktive Konten ohne registrierte MFA, vor allem Test-, Demo- und Funktionskonten aus vergangenen Projekten.
• Zwei kritische Befunde: Global-Admin-Rechte auf einem täglich genutzten Konto und auf einem alten Service-Konto ohne starke MFA. Beide wurden in derselben Woche behoben – mit separaten Admin-Konten ohne Lizenz und ohne Postfach.

Kein Dokument hätte das gefunden. Eine Policy zur Zugriffsverwaltung hatten wir längst. Gefunden hat es erst die Frage «zeigen Sie mir, wer Zugriff hat».

#Die SoA ist das Herzstück

Die Erklärung zur Anwendbarkeit (Statement of Applicability) listet alle 93 Controls aus Annex A und sagt für jedes:

1. Anwendbar ja/nein.
2. Begründung – welches Risiko oder welche Anforderung es nötig macht, oder warum es ausgeschlossen ist.
3. Umsetzungsstand – umgesetzt, teilweise, geplant.
4. Wo der Nachweis liegt – ein Link, keine Beschreibung.

Die vierte Spalte entscheidet über das Audit. «Wir machen Backups» ist eine Behauptung. «Restore-Test vom 3. Juni, Protokoll verlinkt» ist ein Nachweis.

Ausschlüsse sind in Ordnung, wenn sie ehrlich sind. Wer kein eigenes Rechenzentrum betreibt, kann Teile der physischen Sicherheit für Serverräume ausschliessen – aber nicht den Zutritt zum Büro oder den Clean Desk.

Zum Vergleich unser aktueller Stand: rund ein Drittel der Controls ist umgesetzt und belegt, knapp zwei Drittel stehen auf «teilweise», ausgeschlossen ist ein einziges. Das sieht auf den ersten Blick schlechter aus als eine SoA voller grüner Haken. Es ist aber die einzige Version, die ein Auditor glaubt. Und es ist die nützlichere: Jedes «teilweise» ist eine Arbeitsliste.

Übrigens haben wir mehrere Ausschlüsse wieder zurückgenommen. «Nicht anwendbar» bei Informationslöschung, Schutz von Aufzeichnungen und Beweissicherung widersprach unseren eigenen Datenschutz- und Incident-Dokumenten. Ein Ausschluss, der einem anderen Dokument widerspricht, fällt beim ersten Querlesen auf.

#Das minimale Policy-Set

Ein KMU braucht weniger Richtlinien, als die KI vorschlägt. Diese acht decken einen Grossteil von Annex A ab:

1. Informationssicherheitsleitlinie – ein, zwei Seiten, von der Geschäftsleitung unterschrieben.
2. Nutzungsrichtlinie – Geräte, E-Mail, Internet, Cloud-Dienste, KI-Tools, was verboten ist.
3. Zugriffsverwaltung – Joiner/Mover/Leaver, MFA, Admin-Konten, Reviews.
4. Lieferantensicherheit – Auswahl und Überprüfung von Anbietern, Vertragsinhalte.
5. Incident-Management – melden, entscheiden, wann Kunden und Behörden informiert werden.
6. Backup und Wiederherstellung – was, wie oft, wo, wie getestet.
7. Mobile Geräte und Remote-Arbeit – BYOD, Verschlüsselung, verlorene Geräte.
8. Kryptografie und Geheimnisse – wo Schlüssel und Passwörter liegen (im Passwortmanager, nicht im Wiki).

Jede Richtlinie bekommt einen Dokumentkopf mit Eigner, Version, Freigabedatum und nächstem Review. Richtlinien ohne Eigner und Review-Datum veralten still – das ist der erste Befund in fast jedem internen Audit.

#Zeit ist der eigentliche Engpass

Bei elf Leuten gibt es niemanden, der Vollzeit ISMS macht. Das ISMS muss neben verrechenbarer Arbeit laufen. Was dabei hilft:

• Das ISMS lebt in den Tools, die ihr sowieso nutzt. Dokumentation im Wiki, Massnahmen und wiederkehrende Aufgaben als Tickets im normalen Board. Ein separates ISMS-Tool ist ein weiterer Ort, den niemand besucht.
• Nachweise beim Arbeiten sammeln, nicht vor dem Audit. Der Restore-Test bekommt sein Protokoll am Tag des Tests, nicht drei Monate später aus der Erinnerung.
• Wiederkehrendes automatisieren: Erinnerungen für Reviews, Berichte zur Awareness-Quote, Exporte von Berechtigungen. Was automatisch läuft, wird nicht vergessen.
• Kleine Schritte, fester Rhythmus. Lieber jede Woche eine Stunde als einmal im Quartal einen panischen Tag.

So sieht das bei uns aus: ein Dashboard im Wiki als Einstieg, darunter Jira-Abfragen für offene Risiken und überfällige Massnahmen. Und eine Übersicht aller ISMS-Dokumente mit Version und nächstem Review-Datum, die sich selbst aktualisiert – jedes Dokument hat denselben Kopf, ein Bericht sammelt die Kopfzeilen ein. Niemand pflegt diese Liste von Hand.

Bei mir ist es etwa ein halber Tag pro Woche. Das ist bei einem 80-%-Pensum gut ein Achtel meiner Zeit – Zeit, die nicht verrechenbar ist und trotzdem irgendwo herkommen muss. Ohne festen Block im Kalender wäre es weniger, und dann wird das ISMS genau das, was es nicht sein soll: ein Projekt, das vor dem Audit hektisch nachgeholt wird.

#Awareness, die man auch abschliesst

Hier können kleine Firmen besser sein als grosse, weil man alle beim Namen kennt. Unsere Awareness-Schulung 2026 sieht so aus:

• Sieben kurze Module im Wiki, zusammen 50–60 Minuten: Phishing und Social Engineering, Datenschutz nach nDSG/DSGVO, Passwort und MFA, Vorfallmeldung, sichere Cloud-Nutzung, mobiles Arbeiten – und seit diesem Jahr sicherer Umgang mit KI.
• Ein Wissens-Check in Microsoft Forms, Bestehensgrenze 80 %, beliebig wiederholbar. Der bestandene Quiz ist der Nachweis.
• Im Quiz wird gleichzeitig die Kenntnisnahme der ISMS-Policy bestätigt. Damit ist eine zweite Auditfrage – «wissen die Mitarbeitenden, dass es die Policy gibt?» – nebenbei belegt.
• Ergebnis: Ende August hatten alle Mitarbeitenden bestanden. Die Quote steht mit Datum auf der Nachweisseite.
• Phishing-Simulationen halbjährlich. Gemessen wird die Klickrate (Ziel ≤ 10 %), aber genauso die Melderate. Wer klickt, bekommt eine vertrauliche Lern-Mail, keinen Pranger.
• Melden wird nie bestraft – auch wenn die Mail am Ende harmlos war. Das steht in jedem Modul, wo es passt.

#Internes Audit und Management-Review

Beide sind Pflicht und werden oft als Papierkram behandelt. Besser:

• Internes Audit: mindestens einmal vor der Zertifizierung, durch jemanden, der den geprüften Teil nicht selbst gebaut hat. In einem KMU heisst das: mit einer Partnerfirma tauschen oder jemanden für zwei Tage holen. Wir lösen es mit einem Kreuz-Audit: Wir haben auch ein Qualitätsmanagement nach ISO 9001. Unser Qualitätsmanager auditiert das ISMS, ich auditiere das QMS. Niemand prüft seine eigene Arbeit.
• Simuliertes Stage-2-Audit: Control für Control durch die SoA, und bei jedem die Frage «Zeigen Sie mir den Nachweis». Unser Ergebnis im Mai 2026 war deutlich: Stage 2 derzeit nicht bestanden. Sechs schwerwiegende Befunde, und der wichtigste davon in einem Satz: Die Nachweis-Ebene war leer. Gute Policies, sauberes Risikomanagement – aber unter «Nachweise» nur leere Seiten. Genau das Problem, um das es in diesem Artikel geht, bei uns selbst.
• Management-Review: einmal im Jahr, eine Stunde, feste Agenda – Zielerreichung, Vorfälle, Auditergebnisse, Risiken, Ressourcen, Entscheide. Die Entscheide werden protokolliert. Dieses Protokoll belegt, dass die Geschäftsleitung das ISMS führt – was die Norm ausdrücklich verlangt.

Wo wir stehen: zwei simulierte Audits hinter uns, eine Roadmap in drei Phasen (Audit-Blocker, Substanz, Reife), und die Nachweis-Ebene füllt sich – Access-Review, Awareness-Quote, Akzeptanzkriterien, Kommunikationsnachweise. Das Stage-2-Audit ist Mitte Dezember. Ob der Zwei-Fragen-Test hält, zeigt sich dann. Ich schreibe danach, wie es gelaufen ist – auch wenn es nicht gut läuft.

#Checkliste

1. Mit Risiken anfangen, nicht mit Annex A.
2. Eine Risikomethode auf einer Seite, 20–30 echte Risiken mit Eignern.
3. SoA mit Nachweis-Links – ehrlich bei «teilweise» und «geplant».
4. Acht Richtlinien, jede mit Eigner und Review-Datum.
5. Jeden Baustein durch den Zwei-Fragen-Test schicken.
6. KI für Struktur, Formulierung und Auditor-Simulation nutzen – nie als Quelle für das, was ihr angeblich tut.
7. Nachweise beim Arbeiten sammeln.
8. Internes Audit und Management-Review wirklich durchführen und protokollieren.

Ein ISMS, das zu 80 Prozent fertig ist und gelebt wird, schlägt eines, das zu 100 Prozent dokumentiert ist und ignoriert wird. Auditoren merken den Unterschied. Angreifer übrigens auch.