Einordnung zum Veröffentlichungszeitpunkt: Mit dem am 27. Juli 2026 in Kraft getretenen AI Omnibus wurden unter anderem die Anwendungsfristen für Hochrisiko-KI angepasst: für Fälle nach Anhang III auf den 2. Dezember 2027, für entsprechende produktbezogene Systeme nach Anhang I auf den 2. August 2028. Die organisatorische Steuerung vorhandener KI-Nutzung bleibt davon als betriebliche Aufgabe unberührt. Quelle

Es beginnt selten mit einer strategischen Entscheidung. Eher mit einem Link im Chat, einer Browser-Erweiterung, einem „Nur mal ausprobieren“ in der Mittagspause. Eine Kollegin lädt ein PDF in einen Online-Assistenten, um eine Zusammenfassung für das Weekly zu bekommen. Jemand anders installiert ein Add-on, das E-Mails „schnell in gut“ umformuliert. Ein drittes Team lässt eine automatisch generierte Präsentation gegen ein paar Stichpunkte entstehen. Und ehe man sich versieht, arbeitet ein Unternehmen mit einem unsichtbaren, wachsenden Geflecht aus generativen KI-Diensten, Prompt-Sammlungen, Agenten, Plugins, mobilen Apps, Browser-Extensions und eingebauten „Assistenz-Features“ in bestehender Software. Was als Bequemlichkeit begann, ist plötzlich ein Sicherheits-, Compliance- und Governance-Thema ersten Ranges: Schatten-IT 2.0.

NIS2 bringt viele Organisationen dazu, Sicherheitsmaßnahmen zu „listen“: man schaut auf Kataloge, orientiert sich an Standards, erstellt Maßnahmenpläne. Das ist grundsätzlich sinnvoll. Die unangenehme Wahrheit ist aber: Nicht jede Maßnahme, die auf dem Papier gut aussieht, trägt im Ernstfall wirklich. Und umgekehrt sind es oft ein paar Basics, die darüber entscheiden, ob ein Vorfall kontrollierbar bleibt – oder ob er sich in Chaos, Stillstand und Nacharbeit übersetzt.

Wenn man über „Basics“ spricht, klingt das schnell nach Allgemeinplätzen. In der Praxis ist es deutlich konkreter. „Basics, die tragen“ sind Maßnahmen, die in kritischen Momenten zwei Dinge gleichzeitig ermöglichen: schnelle Entscheidungen und stabile Abläufe. Genau das erwartet NIS2 im Kern: nicht Perfektion, sondern Betriebsfähigkeit.

Sicherheit riecht nach Serverraum, nach kalter Luft und blau blinkenden LEDs. Sicherheit klingt nach Alarmen, Logfiles, SIEM-Dashboards und Patches. Und Sicherheit sieht aus wie ein Login-Bildschirm, der nach Multi-Factor fragt. Das alles ist richtig – und doch gefährlich unvollständig. Denn die meisten Vorfälle beginnen nicht am Bildschirm. Sie beginnen an Türen, Drehkreuzen, in Aufzügen, an Lieferzonen, in Abstellräumen, bei Paketannahmen, in Parkhäusern, auf Flughäfen, an Hotelrezeptionen – und in Koffern. Wer heute über Resilienz spricht, muss Sicherheit von außen nach innen denken: vom Gehweg bis zum Kernel, von Kabeln bis Koffern. Physische Sicherheit ist nicht das Nebenfach der Cyber-Disziplin, sondern ihre erste Grenze und ihr letzter Beweis. Sie entscheidet darüber, ob Ihre kryptographisch perfekte Welt der Zugangscodes und Zertifikate in der Wirklichkeit standhält – wenn jemand die Tür offenhält, den Patchschrank aufhebelt, den Koffer stiehlt oder die falsche Person mit Warnweste durchwinkt.

Der alte Perimeter – Zäune, Pförtner, Zutrittskarten – war für eine Welt gemacht, in der Menschen fünf Tage die Woche in ein Büro kamen, Akten in einem Archiv lagen, Server in einem Raum brummten. Diese Welt gibt es nicht mehr. Heute entstehen dynamische Perimeter: Co-Working-Flächen neben dem Stammhaus, Außenlager in Drittländern, Field-Service im Kundenwerk, Homeoffice in Mietwohnungen, Meetings im Flughafenhotel, Notebooks im Bordgepäck. Gebäude sind vernetzte Maschinen – mit Aufzugsteuerungen, Video-Management, Zutrittskontrolle, Heizung, Klima, Beleuchtung. Jedes System hat eine IP, ein Update-Fenster, Protokolle, Passwörter. Wer physische Sicherheit weiter als „Schloss und Riegel“ betrachtet, übersieht die Konvergenz: Gebäudetechnik, Menschen, Prozesse und IT sind heute ein einziges, zusammenhängendes System. Und genau so muss man es steuern.

Manche Sicherheitsgeschichten beginnen mit einem Genie an der Kommandozeile, einem Domain-Admin im Mantel der Nacht, einem perfekt orchestrierten Angriff auf Kerberos oder KMS. Die meisten beginnen anders: mit alltäglichen Rechten, die niemand für gefährlich hält. Ein „Viewer“ in der Doku-Plattform. Ein „Reporting“-Zugang im CRM. Ein „Guest“ im Kollaborationstool. Ein Servicekonto mit Leserechten auf Logdateien. Ein Praktikanten-Account, der nur Tickets lesen darf. Diese scheinbar harmlosen Berechtigungen sind die Welt des Insider light – Personen und Prozesse innerhalb (oder knapp außerhalb) der Organisation, die keine „großen“ Rechte brauchen, um große Lücken zu reißen. Nicht, weil sie Superhacker wären, sondern weil unsere Systeme Informationen großzügig streuen, Workflows automatisch auslösen und Meta­daten verräterischer sind, als uns lieb ist. Wer Sicherheit heute ernst meint, darf das kleine Licht nicht unterschätzen, denn es beleuchtet überraschend viele Wege bis ins Herz der Organisation.

Was genau ist „Insider light“?

„Insider“ weckt oft das Bild des böswilligen Mitarbeiters mit Vollzugriff. „Light“ verschiebt die Perspektive: Es geht um Akteure mit begrenzten, formal unkritischen Rechten, die dennoch kritische Wirkung entfalten – absichtlich, fahrlässig oder weil sie selbst zum Opfer werden. Das Spektrum ist breit:

Die Cloud ist längst kein Zukunftsthema mehr, sondern Alltag. Unternehmen aller Größenordnungen verlagern Daten, Anwendungen und ganze Infrastrukturen in die Cloud – aus guten Gründen: Flexibilität, Skalierbarkeit, schnellere Time-to-Market und planbarere Kosten. Doch wo Geschwindigkeit und Dynamik steigen, wachsen auch die Risiken. Viele Organisationen gehen Cloud Security noch immer zu intuitiv an – ohne eindeutige Ziele, ohne messbare Kontrollen, ohne gelebte Verantwortlichkeiten. Die Folge: Fehlkonfigurationen bleiben unentdeckt, Identitäten sind überprivilegiert, Protokolle fehlen, Nachweise für Compliance sind lückenhaft. Wer Cloud Security ernst nimmt, braucht mehr als Tools – er braucht einen Plan: klar, wiederholbar, auditierbar.

Ziele und Schutzbedarfe: Was wirklich geschützt werden muss

Der wirksamste erste Schritt ist eine Schutzbedarfsanalyse mit eindeutiger Priorisierung. Typische Klassen sind: