Es passiert nicht oft, dass ein technischer Katalog das Zeug zur gemeinsamen Sprache einer ganzen Branche hat. Die CIS Controls sind so ein Fall – und mit Version 8 haben sie sich neu sortiert, ohne ihre DNA zu verlieren. Aus 20 wurden 18 Controls, aus verstreuten Unterpunkten wurden präziser formulierte Safeguards, aus „Hardware“ und „Software“ wurden Enterprise Assets, aus höflichen Empfehlungen wurden umsetzbare Anforderungen für eine Welt, in der Workloads in die Cloud wandern, Mitarbeiter von überall arbeiten und Lieferketten zum größten Risiko werden können. v8 ist kein kosmetisches Update; es ist die Antwort auf die Frage: Wie priorisiert man Sicherheitsarbeit, wenn Infrastruktur, Identitäten und Daten längst über Rechenzentrum, SaaS und mobile Endpunkte verstreut sind – und wenn die Angreifer inzwischen Produktmanagement in eigener Sache betreiben?

Warum es eine Neuordnung brauchte

Die frühen Fassungen der Controls kamen aus einem ganz bestimmten Schmerz: Immer wieder öffentlich ausgenutzte Schwachstellen, vernachlässigte Baselines, keine Übersicht über Assets, zu breite Adminrechte, Protokolle, die niemand liest, Backups, die im Ernstfall nicht zurückspielen. Version 7 brachte diese Einsichten in eine klare, priorisierte Reihenfolge. Aber die Realität drehte schneller: Cloud wurde Standard, SaaS wurde Geschäftsgrundlage, Identitäten wurden zur neuen Perimeter-Kante, Remote Work wurde Alltagsbetrieb, und Drittparteirisiken wurden sichtbar – nicht nur regulatorisch, sondern operativ. Viele Unternehmen stellten fest, dass v7 zwar wirkt, aber Vokabular und Zuschnitt die neuen Infrastrukturen nur unzureichend abbildeten. v8 reagiert darauf, ohne den Kern (Priorisieren, Messen, Automatisieren) zu verwässern.

Es gibt in der Informationssicherheit diese seltenen Momente, in denen ein Konzept aus der Fachwelt heraustritt und in Vorstandsetagen, Einkaufsgesprächen und Projektplänen gleichzeitig landet. Die CIS Controls v7 haben genau diesen Sprung geschafft. Was jahrelang als Werkzeugkasten für Praktiker galt, wird zum gemeinsamen Nenner zwischen Security-Teams, Prüfern, Herstellern und Aufsichten. Plötzlich sprechen alle dieselbe Sprache: Inventarisierung, Härtung, Schwachstellenmanagement, Protokollierung, Privilegien – nicht als Schlagworte, sondern als handfeste Arbeitsanweisungen. Warum ausgerechnet diese 20 Maßnahmen? Warum jetzt? Und warum wirken sie so viel praxisnäher als manch anderes Regelwerk? Die Antworten liegen weniger in Marketing als in Mechanik: in der Art, wie Angriffe wirklich verlaufen – und wie sich Verteidigung im Alltag steuern lässt.

Vom Rahmenwerk zur Gebrauchsanweisung

Die Sicherheitswelt kennt Normen und Kataloge in Hülle und Fülle. Sie strukturieren Verantwortlichkeiten, definieren Prozesse, beschreiben Controls – oft umfassend, manchmal erschlagend. Die CIS Controls setzen anders an. Sie sind keine Theorie über Sicherheit, sondern eine nach Priorität sortierte Liste von Tätigkeiten, die Angriffe entlang ihrer typischen Pfade früh unterbrechen oder schnell sichtbar machen. Statt „alles ist wichtig“ behaupten sie: Einige Dinge sind sofort wichtig. Genau diese Frechheit macht sie so einflussreich. Wer mit knappen Mitteln schnelle Wirkung braucht, greift zuerst zu dem, was in der Praxis am häufigsten zwischen Vorfall und Beinahe-Vorfall entscheidet.

Es fängt – wie vieles in der Informationssicherheit – nicht mit einem großen Plan an, sondern mit Frust. Frust darüber, dass Unternehmen immer wieder an denselben Stellen getroffen werden. Frust darüber, dass dicke Ordner voller Richtlinien kaum helfen, wenn ein Angreifer mit banalen Mitteln durch eine unentdeckte Fernwartungsschnittstelle spaziert. Frust darüber, dass jede Organisation aufwendig eigene Kataloge schreibt, während die Kriminellen längst arbeitsteilig, wiederholbar und effizient vorgehen. Aus diesem Frust entsteht eine Idee, die zunächst beinahe unverschämt schlicht wirkt: Statt noch ein Rahmenwerk, noch eine Norm, noch eine Auslegungshilfe zu veröffentlichen, bündeln wir das, was wirklich wirkt, und bringen es in eine priorisierte Reihenfolge. Keine Theorielehre, sondern ein Programm. Kein schönes Plakat, sondern eine Handlungsanweisung. Aus dieser Idee wurden erst die „Top 20 Critical Security Controls“ – und im nächsten Schritt das, was wir heute als CIS Controls kennen.

Die Ausgangslage: Zu viel Theorie, zu wenig Wirkung

Die frühen 2000er-Jahre sind eine Zeit des Aufbruchs – und der Ernüchterung. Die Sicherheitsgemeinde verfügt über Rahmenwerke en masse: ISO/IEC 27001 mit seinem Managementansatz, NIST SP 800-53 mit seinem umfassenden Kontrollkatalog, COBIT für Governance, ITIL für Serviceprozesse. All das ist wertvoll. Doch im Maschinenraum der Unternehmen bleiben immer wieder dieselben Lücken offen: nicht inventarisierte Systeme, veraltete Software, grob fahrlässige Standardkonfigurationen, allzu großzügige Administratorrechte, schwache Protokollierung, zu seltene Auswertung. Wer ein Incident-Response-Team begleitet, erkennt Muster. Wer viele Reaktionen begleitet, erkennt immer dieselben Muster.

Es gibt Momente, in denen Regulierung nicht nur Regeln setzt, sondern eine ganze Organisation in den Spiegel schauen lässt. DORA und NIS2 sind genau solche Momente. Die eine Verordnung richtet sich mitten ins Herz der Finanzwelt und macht digitale Resilienz zur Chefsache. Die andere spannt den Bogen über große Teile der europäischen Wirtschaft und hebt Cybersicherheit auf ein neues, sektorübergreifendes Niveau. Zusammen erzeugen sie einen Druck, der weit über Checklisten hinausreicht: Governance wird zur Bewährungsprobe. Nicht mehr die Frage, ob Richtlinien existieren, sondern ob Steuerung messbar wirkt, entscheidet darüber, wie belastbar ein Unternehmen wirklich ist.

Der Doppeldruck: Zwei Wellen, ein Kernproblem

Viele Häuser erleben gerade zwei Wellen gleichzeitig. Von DORA her rollt die Erwartung, digitale Betriebsfähigkeit selbst unter Störung nachweislich zu sichern – mit Risikomanagement, Meldung, Tests und streng geführter Lieferkette. Von NIS2 her wächst der Anspruch, Cyberrisiken querschnittlich zu beherrschen – vom Vorstand über Technik bis hin zu Partnern und Dienstleistern. Auf den ersten Blick zwei Welten; in Wahrheit ein Kernproblem: Führung unter Unsicherheit. Wer beide Rahmen ernst nimmt, erkennt schnell: Governance ist nicht die Summe von Einzelanforderungen, sondern ein lebendes System, das Ziele, Risiken, Kontrollen, Daten und Entscheidungen miteinander verzahnt – und zwar so, dass man es jederzeit belegen kann.

Wer digitale Produkte in Europa verkaufen will, kennt das Spiel mit der CE-Kennzeichnung: technische Unterlagen zusammenstellen, Konformität erklären, Label aufkleben, fertig. Zumindest war es lange so. Mit dem Cyber Resilience Act (CRA) beginnt eine neue Ära. Das CE-Zeichen bleibt, doch sein Inhalt wandelt sich grundlegend. Neben elektrischer Sicherheit, EMV und Produkthaftung rückt nun Cybersicherheit in den Mittelpunkt – nicht als freiwillige Beigabe, sondern als zwingende Marktzutrittsbedingung.

Dieser Text erklärt – ohne Angst, aber ohne Beschönigung – was das praktisch bedeutet. Er richtet sich an Produktmanager, CTOs, Compliance-Verantwortliche, Gründerinnen und Gründer, Einkäufer und Integratoren. Er erzählt, wie man vom ersten Architekturentwurf bis zur letzten Seriennummer CE-fähig bleibt, warum die Dokumentation plötzlich strategisch wird, wieso Vulnerability-Handling und Meldepflichten zu einem neuen „Betriebssystem“ für Hersteller werden – und an welchen Stellen Unternehmen erfahrungsgemäß stolpern. Alles in flüssigem Text, mit punktuellen Einschüben dort, wo es das Verständnis erleichtert.