Controls als Antwort auf Risiken

Problem in der Praxis

In vielen Unternehmen wachsen Controls historisch. Ein Tool wird eingeführt, weil es ein Vorfall nahelegt. Eine Richtlinie entsteht, weil ein Kunde sie verlangt. Ein Prozess wird dokumentiert, weil ein Audit danach fragt. Das kann kurzfristig helfen, führt aber oft zu einer Maßnahmenlandschaft ohne klare Priorität.

Typische Symptome sind doppelte Kontrollen, unklare Owner, fehlende Wirksamkeitsnachweise und Maßnahmen, deren Zweck niemand mehr erklären kann. Gleichzeitig bleiben wesentliche Risiken unbehandelt, weil die Organisation mit Pflege bestehender Controls ausgelastet ist.

Ein CISO muss diese Lage aufräumen, ohne in eine normnahe Control-Rekonstruktion zu verfallen. Die Leitfrage lautet nicht: "Welche Controls gibt es?" Sondern: "Welche Risiken behandeln wir wie, und ist das angemessen?"

CISO-Einordnung

Controls können technisch, organisatorisch, personell oder vertraglich wirken. Sie können vorbeugen, erkennen, reagieren oder wiederherstellen helfen. In der Praxis wirken viele Controls nur im Zusammenspiel.

Beispiel: Zugriffsschutz ist nicht nur eine technische Einstellung. Er braucht Rollenverständnis, Genehmigungsprozesse, regelmäßige Prüfungen, Protokollierung, Schulung und Eskalation. Wenn eine dieser Komponenten fehlt, kann das Control formal vorhanden, aber praktisch schwach sein.

Controls sollten daher immer mit vier Fragen betrachtet werden:

• Welches Risiko soll reduziert werden?
• Welche Wirkung soll das Control haben?
• Wer ist für Betrieb und Nachweis verantwortlich?
• Woran erkennen wir, dass es funktioniert oder versagt?

Diese Fragen bleiben bewusst generisch. Sie ersetzen keine Control-Kataloge und keine Originalnorm.

Umsetzungsperspektive

Ein pragmatischer Ansatz beginnt mit den Top-Risiken. Für jedes wesentliche Risiko werden bestehende Controls identifiziert und auf Plausibilität geprüft. Danach entscheidet das Unternehmen, ob Risiken akzeptiert, weiter reduziert, transferiert oder vermieden werden sollen. Der Zusammenhang zwischen Risikobehandlung und gewählten Controls wird im Statement of Applicability (SoA) nachvollziehbar festgehalten, inklusive Begründung, warum ein Control aufgenommen oder bewusst weggelassen wird. Das SoA ist ein zentrales Artefakt für die Zertifizierung und wird in der Dokumentenprüfung (Stage 1) erwartet. Die Dokumentenprüfung (Stage 1) ist dabei anerkannte Zertifizierungspraxis (Referenzrahmen ISO/IEC 17021-1 / ISO/IEC 27006) und kein Inhalt der Anforderungsnorm ISO/IEC 27001. Ergänzend dient der Referenz-Controlsatz aus Annex A als Vollständigkeits-Abgleich, damit kein wesentliches Control übersehen wird. Er ersetzt aber nicht das Denken vom Risiko her. Verbindliche Detailanforderungen zu SoA und Risikobehandlung regelt die Originalnorm.

Hilfreich ist eine einfache Control-Karte pro wesentlichem Control:

• Zweck des Controls.
• Bezogenes Risiko oder Szenario.
• Owner.
• Betriebsfrequenz oder Auslöser.
• Erwarteter Nachweis.
• Bekannte Grenzen.
• Nächste Verbesserung.

Diese Karte ist kein Normauszug. Sie ist ein eigenes Managementartefakt, das den Betrieb erleichtert.

Typische Fehler

1. Controls werden eingeführt, ohne das zu behandelnde Risiko zu benennen.
2. Technische Controls werden gekauft, aber nicht in Prozesse eingebettet.
3. Control Owner sind unklar oder liegen pauschal bei der IT.
4. Wirksamkeit wird mit Existenz verwechselt.
5. Auditfähigkeit wird über Sicherheitswirkung gestellt.

Risiken und Trade-offs

Mehr Controls bedeuten nicht automatisch mehr Sicherheit. Jedes Control verursacht Betriebskosten, Reibung, Pflegeaufwand und mögliche Fehlalarme. Ein zu komplexes Kontrollsystem kann die Organisation lähmen und Umgehungsverhalten erzeugen.

Umgekehrt kann ein zu schlankes Kontrollset kritische Risiken offenlassen. Besonders gefährlich sind Controls, die auf dem Papier stark wirken, aber im Alltag nicht betrieben werden.

Ein weiterer Trade-off betrifft Automatisierung. Automatisierte Controls können konsistenter sein, brauchen aber saubere Daten, Konfiguration und Monitoring. Manuelle Controls sind flexibel, aber anfällig für Auslassungen und Personalwechsel.

Entscheidungspunkte

• Welche Top-Risiken haben keine ausreichende Control-Abdeckung?
• Welche bestehenden Controls erzeugen Aufwand ohne erkennbare Risikowirkung?
• Welche Controls brauchen klare fachliche Owner statt rein technischer Verantwortung?
• Wo ist Automatisierung sinnvoll, und wo braucht es bewusste menschliche Entscheidung?
• Welche Nachweise zeigen Betrieb und Wirksamkeit, ohne künstliche Auditdokumentation zu erzeugen?

Praktische Empfehlungen

1. Starten Sie Control-Design immer beim Risiko, nicht beim Katalog.
2. Dokumentieren Sie pro wesentlichem Control Zweck, Owner, Nachweis und Grenzen.
3. Prüfen Sie regelmäßig, ob Controls noch zum Risiko und zur Systemlandschaft passen.
4. Messen Sie nicht nur Existenz, sondern auch Betrieb und Wirkung.
5. Entfernen oder vereinfachen Sie Controls, die keinen sinnvollen Beitrag mehr leisten.

Relevante Normreferenzen

• ISO/IEC 27002: Referenz für Leitlinien zu Informationssicherheits-Controls.
• ISO/IEC 27005: Referenz für Informationssicherheitsrisikomanagement und Risikobehandlung.
• ISO/IEC 27001: Referenzrahmen für die risikobasierte Auswahl von Controls und das Statement of Applicability (SoA) als Teil der Risikobehandlung; verbindliche Anforderungen ausschließlich der Originalnorm entnehmen.