# Wenn Sicherheitsarbeit existiert – aber kein Sicherheitsvertrauen

> Der Beitrag von Swiss GRC erklärt, warum viele ISMS scheitern: Sicherheitsarbeit wird geleistet, aber nicht dauerhaft nachweisbar. Er richtet sich an Unternehmen und zeigt vier Anforderungen an ein ISMS, das Sicherheit kontinuierlich sichtbar macht.

- URL: https://swissgrc.com/wenn-informationssicherheit-sicherheitsarbeit-existiert-aber-kein-sicherheitsvertrauen/
- Herausgeber: SwissGRC®
- Veröffentlicht: 2026-05-05
- Zuletzt aktualisiert: 2026-08-20

## Kernaussagen

- Nach Darstellung von Swiss GRC scheitern viele Informationssicherheits-Managementsysteme (ISMS) an der Lücke zwischen der Durchführung von Sicherheitsmassnahmen und deren Nachweis.
- Als eigentliches Problem nennt der Beitrag fehlende Kontinuität: Sicherheit ist kontinuierlich, Dokumentation oft nur periodisch.
- Der Beitrag nennt vier Anforderungen an ein ISMS: Sicherheit folgt dem Asset, Nachweise entstehen als Nebenprodukt der Arbeit, das System bildet die bereichsübergreifende Zusammenarbeit ab, und Monitoring hat Vorrang vor Dokumentation.
- Informationssicherheit betrifft laut Beitrag mehrere Bereiche: HR steuert Identitäts- und Lifecycle-Prozesse, der Einkauf bringt Lieferantenrisiken ein, Fachbereiche klassifizieren Daten und das Recht definiert regulatorische Anforderungen.
- Das ISMS-Modul von Swiss GRC verknüpft Asset-Bewertungen (CIA-Klassifizierung), Risikobewertungen, Schwachstellen und Compliance-Prüfungen in einer workflowbasierten Umgebung.
- Der Unterschied zwischen Sicherheit als Dokumentation und Sicherheit als System zeigt sich laut Beitrag bei Audits, Sicherheitsvorfällen, Kundenprüfungen und regulatorischen Bewertungen.

Die meisten Unternehmen betreiben heute bereits [Informationssicherheit](https://swissgrc.com/informationssicherheit-isms-software/).

Sie führen Asset-Listen. Sie führen Schwachstellenscans durch. Sie überprüfen Zugriffsrechte. Sie erstellen Richtlinien.

Und dennoch kommt dieser unangenehme Moment immer wieder:

„Können wir nachweisen, dass dies im letzten Quartal kontrolliert wurde?“

Stille.

Nicht, weil die Arbeit nicht erledigt wurde – sondern weil sie an unterschiedlichen Orten stattfindet.

Sicherheitsrelevante E-Mails liegen in Postfächern. Risikoregister in Tabellen. Kontrollen in Dokumenten. Verantwortlichkeiten in den Köpfen der Mitarbeitenden.

Wenn dann ein Audit, ein Vorfall oder eine Kundenanfrage eintritt, prüfen Teams die Sicherheit nicht – sie rekonstruieren sie.

Genau diese Lücke zwischen der Durchführung von Sicherheitsmaßnahmen und deren Nachweis ist der Punkt, an dem viele Informationssicherheits-Managementsysteme (ISMS) in der Praxis scheitern.

Das eigentliche Problem sind nicht fehlende Kontrollen

**Sondern fehlende Kontinuität**

Theoretisch ist ein ISMS einfach: Assets identifizieren, Risiken bewerten, Kontrollen anwenden, regelmäßig überprüfen.

Sicherheit ist kontinuierlich – Dokumentation hingegen oft periodisch.

Teams bewerten Risiken zu Projektbeginn, aber nicht bei Veränderungen der Umgebung. Assets werden beim Onboarding erfasst, jedoch nicht beim Wachstum von Shadow IT. Kontrollen werden definiert, aber ihre Wirksamkeit ist über die Zeit hinweg nicht sichtbar.

Das Ergebnis: Unternehmen sind punktuell compliant – aber nicht dauerhaft sicher.

ISMS-Software hilft nur dann, wenn sie verändert, wie Sicherheitsarbeit täglich stattfindet – nicht nur während Audits.

Was ein ISMS tatsächlich leisten sollte

**1. Sicherheit sollte dem Asset folgen – nicht der Tabelle**

Wenn eine Schwachstelle auftritt, sind die entscheidenden Fragen immer operativ:

- Welches System ist betroffen?
- Wer ist verantwortlich?
- Welche Daten werden verarbeitet?
- Welches Risiko entsteht daraus?

Wenn die Antworten drei Meetings und zwei Exporte erfordern, ist das ISMS Dokumentation – kein Management.

Ein praxisnahes ISMS verknüpft Assets, Risiken, Kontrollen und Verantwortlichkeiten, sodass Auswirkungen sofort sichtbar sind – und nicht erst nachträglich zusammengestellt werden müssen.

**2. Nachweise sollten ein Nebenprodukt der Arbeit sein**

Sicherheitsteams verbringen oft mehr Zeit damit, Maßnahmen nachzuweisen, als sie umzusetzen.

Ein reifer ISMS-Ansatz bedeutet:

Nachweise müssen nicht vorbereitet werden – sie entstehen automatisch im Arbeitsprozess.

Reviews, Freigaben, Risikobewertungen und Kontrollprüfungen hinterlassen Spuren, ohne dass jemand aktiv „Audit-Nachweise“ erstellen muss.

**3. Sicherheit ist bereichsübergreifend – das System sollte dies widerspiegeln**

Informationssicherheit ist nicht allein Aufgabe der IT:

- HR steuert Identitäts- und Lifecycle-Prozesse
- Einkauf bringt Lieferantenrisiken ein
- Fachbereiche klassifizieren Daten
- Recht definiert regulatorische Anforderungen

Wenn Sicherheit davon abhängt, dass eine Abteilung Informationen von anderen sammelt, bleibt sie periodisch. Wenn alle Teams innerhalb einer gemeinsamen Struktur arbeiten, wird sie kontinuierlich.

**4. Monitoring ist wichtiger als Dokumentation**

Viele Unternehmen verfügen über perfekt formulierte Richtlinien – und erleben dennoch Vorfälle.

Denn die entscheidende Frage ist nicht:

„Wurde die Kontrolle definiert?“

Sondern:

„Hat die Kontrolle letzten Dienstag funktioniert?“

Kontinuierliche Transparenz – nicht vollständige Dokumentation – bestimmt den Reifegrad operativer Sicherheit.

Wo Lösungen wie Swiss GRC ansetzen

Plattformen wie das ISMS-Modul von Swiss GRC schaffen Struktur, indem sie Asset-Bewertungen (CIA-Klassifizierung), Risikobewertungen, Schwachstellen und Compliance-Prüfungen in einer workflowbasierten Umgebung miteinander verknüpfen. Der Fokus liegt weniger auf der Speicherung von Richtlinien als auf der Sicherstellung von Nachvollziehbarkeit über alle Sicherheitsaktivitäten hinweg.

Der eigentliche Mehrwert liegt nicht im Tool selbst, sondern im Übergang von periodischen Sicherheitsaktivitäten zu kontinuierlicher operativer Transparenz.

Das praktische Ergebnis

Wenn Sicherheit nur als Dokumentation existiert, basiert Vertrauen auf Erinnerung. Wenn sie als System existiert, basiert Vertrauen auf Fakten.

Dieser Unterschied zeigt sich insbesondere bei:

- Audits
- Sicherheitsvorfällen
- Kundenprüfungen
- regulatorischen Bewertungen

Organisationen scheitern nicht daran, dass sie keine Sicherheitsarbeit leisten. Sie scheitern daran, dass sie diese Arbeit über die Zeit hinweg nicht sichtbar machen können.

Ein effektives ISMS macht ein Unternehmen nicht über Nacht „sicherer“. Es macht Sicherheit sichtbar – und was sichtbar ist, wird steuerbar.

Und genau an diesem Punkt hört Sicherheit auf, ein jährliches Projekt zu sein – und wird zu einem festen Bestandteil des täglichen Betriebs.

## Häufige Fragen

### Warum scheitern viele ISMS in der Praxis?

Laut Swiss GRC scheitern sie an der Lücke zwischen der Durchführung von Sicherheitsmassnahmen und deren Nachweis. Die Arbeit findet an verschiedenen Orten statt, etwa in Postfächern, Tabellen und Dokumenten, und wird bei Audits oder Vorfällen erst rekonstruiert.

### Was bedeutet es, dass Nachweise ein Nebenprodukt der Arbeit sein sollten?

Nachweise müssen nicht gesondert vorbereitet werden, sondern entstehen im Arbeitsprozess. Reviews, Freigaben, Risikobewertungen und Kontrollprüfungen hinterlassen Spuren, ohne dass jemand Audit-Nachweise erstellen muss.

### Warum ist Monitoring wichtiger als Dokumentation?

Gute Richtlinien verhindern Vorfälle nicht zwingend. Entscheidend ist laut Beitrag, ob eine Kontrolle tatsächlich funktioniert hat, nicht ob sie definiert wurde. Kontinuierliche Transparenz bestimmt den Reifegrad operativer Sicherheit.

### Was leistet das ISMS-Modul von Swiss GRC?

Es verknüpft Asset-Bewertungen (CIA-Klassifizierung), Risikobewertungen, Schwachstellen und Compliance-Prüfungen in einer workflowbasierten Umgebung. Der Fokus liegt auf der Nachvollziehbarkeit aller Sicherheitsaktivitäten, weniger auf der Ablage von Richtlinien.

### Warum ist Informationssicherheit nicht nur Aufgabe der IT?

Mehrere Bereiche tragen dazu bei: HR steuert Identitäts- und Lifecycle-Prozesse, der Einkauf bringt Lieferantenrisiken ein, Fachbereiche klassifizieren Daten und das Recht definiert regulatorische Anforderungen.
