Wer heute über 5G spricht, landet oft reflexartig bei Messwerten: Gigabit-Downloads, einstellige Millisekunden, funkelnde Balkendiagramme im Smartphone. Doch genau diese Fixierung auf die Zahl rechts unten im Speedtest verdeckt den eigentlichen Umbruch. 5G ist weniger ein schnelleres Funkprotokoll als vielmehr ein modularer Baukasten für verlässliche, planbare und differenzierte Konnektivität. Die ersten produktiven Use-Cases im Business zeigen das sehr konkret: autonome Transportfahrzeuge in Fabriken, die ohne Kabelzug und Funkabbrüche funktionieren; Häfen, die Kräne, Sensoren und Kameras in einem einzigen privaten 5G-Campusnetz orchestrieren; Kliniken, die Bilddaten nahezu verzögerungsfrei an Befund-Workflows weitergeben; Energieversorger, die Fleckennetze (Edge) für Netzzustand und Lastverteilung aufbauen; Event-Veranstalter, die Besucherströme, Kassen- und Zutrittssysteme ohne Überlastungen in temporären 5G-Slices betreiben.

Geschwindigkeit ist hierfür nur der Türöffner. Der eigentliche Mehrwert entsteht, weil 5G Qualität garantieren kann – und zwar Anwendung für Anwendung. Mit Network Slicing, Ultra Reliable Low Latency Communication (URLLC), Massive Machine Type Communication (mMTC) und Edge Computing wird aus einem Funknetz eine Plattform, in der man Kapazität, Latenz, Verfügbarkeit und Sicherheit pro Geschäftsprozess zuschneiden kann. Genau diese Planbarkeit fehlte bisherigen Mobilfunkgenerationen.

Der „Wizard of GRC“ für eine Zeit, in der dein Kaffee noch warm ist

Es ist ein schwindelerregender Moment: Du öffnest den Editor, gibst zwei, drei Sätze in ein Prompt-Feld – und noch bevor dein Kaffee kalt wird, steht das Gerüst eines kompletten Dienstes vor dir. Routen, Controller, Datenmodell, API-Doku, Unit-Tests, Dockerfile, CI-Workflow: alles da. Was gestern noch ein Sprint war, passt heute in eine Session. Fantastisch für die Geschwindigkeit, beängstigend für die Sichtbarkeit. Denn jede generierte Codezeile erzählt nicht nur eine Geschichte von Produktivität, sondern auch eine über Compliance, Abhängigkeiten und Third-Party-Risiken.

Der IT-Grundschutz des BSI ist seit Jahren die wohl deutscheste Antwort auf eine sehr internationale Frage: Wie organisiert man Informationssicherheit so, dass sie im Alltag funktioniert, auditierbar bleibt und trotzdem mit der Technik Schritt hält? Mit „Grundschutz++“ kündigt sich nun die nächste Evolutionsstufe an – eine Fortentwicklung, die den Standard stärker digitalisiert, prozessorientierter macht und für die kommenden Jahre fit. Das BSI hat dazu im Sommer 2025 ausdrücklich den Dialog mit der Fachöffentlichkeit gesucht und den Namen „IT-Grundschutz++“ als Arbeitstitel gesetzt. Ziel: Modernisierung ohne Bruch, also Kontinuität dort, wo sie sinnvoll ist, und spürbare Vereinfachungen dort, wo die Praxis es braucht.

Dieser Beitrag ordnet den Kontext ein, erklärt die Design-Ideen hinter Grundschutz++, zeigt, was sich wahrscheinlich verändert (und was nicht), und gibt konkrete Hinweise, wie sich Organisationen – vom Mittelständler bis zur Behörde – heute so aufstellen, dass der Übergang locker gelingt. Wir stützen uns dabei auf die offiziellen BSI-Informationen zum IT-Grundschutz und auf frühe, öffentliche Berichte aus der Praxiscommunity, die die Digitalisierung und Maschinenlesbarkeit des Standards, eine stärkere Objekt-/Prozessorientierung sowie Übergangsfristen skizzieren.

Es beginnt selten mit einem direkten Angriff auf das eigene Haus. Häufiger startet die Kettenreaktion einige Sprünge entfernt: ein „Minor Incident“ bei einem SaaS-Anbieter, eine Schwachstelle in einer File-Transfer-Lösung, ein überprivilegierter Account beim Managed Service Provider, ein Update, das im Build-Prozess eines Partners kompromittiert wurde. Für die Öffentlichkeit sind das zunächst nur Randnotizen. Für Betreiber kritischer oder wichtiger Dienste können es jedoch die Sekunden sein, in denen aus einem Fremdproblem eine eigene Meldepflicht wird. Spätestens mit NIS2 ist klar: Wer auf Lieferketten setzt (und wer tut das nicht?), trägt Verantwortung – und zwar nicht nur für die Prävention, sondern auch für die Meldung. Dieses „NIS2 im Nacken“-Gefühl ist kein Aktionismus, sondern Ausdruck einer Realität, in der Abhängigkeiten Teil des Kernbetriebs sind.

Dieser Beitrag erklärt, warum Lieferkettenereignisse unter NIS2 meldepflichtig werden können, wie sich Meldewege, Schwellen und Verantwortlichkeiten in der Praxis anfühlen, welche Governance-Bausteine jetzt zählen – und wie man den Spagat schafft zwischen Transparenz, Tempo und Verlässlichkeit. Nicht als trockene Gesetzeslektüre, sondern als Betriebsanleitung für den Ernstfall.

Es knirscht selten laut, wenn es passiert. Kein großer Knall, keine rot blinkenden Warnlampen. Stattdessen: eine kleine Konfigurationsänderung bei einem Dienstleister, ein unscheinbares Update, eine freundliche E-Mail eines „Partners“, ein Browser-Plugin aus einem Hersteller-Marketplace. Wochenlang wirkt alles normal, die Dashboards bleiben grün. Und doch hat sich die Risikolage grundlegend verschoben – nur eben nicht dort, wo das eigene SOC hinschaut. Die Schwachstelle liegt außerhalb des Perimeters, außer Reichweite der üblichen Telemetrie und häufig auch jenseits der eigenen Zuständigkeiten. Genau dort, wo moderne Wertschöpfung in der Praxis stattfindet: bei Third Parties.

Dass Drittparteien zur Achillesferse werden, ist keine überraschende Schlagzeile – aber die Mechanik dahinter wird in vielen Unternehmen unterschätzt. Third Parties stehen mitten in unseren Prozessen, tragen weitreichende Berechtigungen, hosten Daten, signieren Updates, verwalten Identitäten, triagieren Tickets, betreiben Infrastruktur und liefern das, was Kundinnen und Kunden direkt erleben: Verfügbarkeit, Geschwindigkeit, Qualität. In dieser Rolle sind sie nicht „außen“, sondern innen – oft mit mehr Rechten, mehr Einblick und mehr Steuerungsmacht als das, was wir im eigenen Haus für selbstverständlich halten.