3. Juli 2026 · AI
Shift Up in der Cybersecurity: vier Lesarten, eine tragfähige
Executive Summary
- „Shift Up“ ist kein definierter Begriff: Vier veröffentlichte Quellen benutzen ihn für vier verschiedene Achsen. Wer ihn ohne Präzisierung übernimmt, kauft eine Vendor-Positionierung statt einer Strategie.
- Die tragfähige Lesart ist prozesszentrisch: Security bewegt sich nicht die Hierarchie hinauf, sondern vom technischen Artefakt hinauf zum wertschöpfenden Geschäftsprozess.
- Der Grund ist die Verlagerung des Schutzobjekts: Wenn KI in Geschäftsprozessen verankert wird, ist der Prozess die Angriffsfläche. Code-zentrierte Modelle greifen dort strukturell daneben.
- Die Toolchain existiert bereits: Prozessmodellierung und Enterprise-Architektur liefern die Landkarte, auf der Security-Entscheidungen überhaupt erst verortbar werden. Die Anwendung auf Security ist allerdings ein Ansatz, kein Katalogprodukt.
- Risikoquantifizierung bleibt notwendig, aber nachgelagert: Sie ist die Sprache gegenüber Vorstand und Aufsicht, nicht der Kern der Neuausrichtung.
Strategischer Kontext
Situation: Über ein Jahrzehnt lang war „Shift Left“ das Ordnungsprinzip der Enterprise-Security: früher testen, früher patchen, früher in den Entwicklungszyklus integrieren. Investitionen in DevSecOps, SAST/DAST und Security Champions folgten dieser Logik.
Complication: Seit etwa zwei Jahren kursiert „Shift Up“ als Nachfolgebegriff. Nur meint jeder Absender etwas anderes damit: Anbieter von Risikoquantifizierung meinen den Vorstand, Anbieter von Supply-Chain-Analyse meinen die Lieferkette, Plattformanbieter meinen Tool-Konsolidierung. Alle drei verkaufen ihre eigene Kategorie als Paradigma.
Question: Welche Lesart beschreibt tatsächlich eine Veränderung des Operating Models, und welche beschreibt nur ein Produkt?
Answer: Die prozesszentrische. Sie ist die einzige, die beantwortet, was geschützt wird, statt nur wer entscheidet, womit oder wie früh.
Warum Shift Left an seine strukturellen Grenzen gestoßen ist
Die Grundprämisse von Shift Left war vernünftig: Wer Sicherheitsprobleme früh im Entwicklungszyklus identifiziert, spart Kosten und reduziert das Exposure. Diese Logik funktionierte, solange Software in kontrollierten, sequenziellen Pipelines entstand und Sicherheit ein technisches Qualitätsproblem war.
Matt Rose, Field CISO bei ReversingLabs, formuliert das Problem präzise: Wer mit einem Sicherheitswerkzeug auf eine einzelne Komponente schaut, bekommt immer nur eine Momentaufnahme. Software Supply Chains, Open-Source-Abhängigkeiten und KI-generierter Code schaffen ein Risikogeflecht, das kein lineares Modell mehr abbildet.
Hinzu kommt das Fragmentierungsproblem. Uptycs zitiert Crunchbase-Daten, wonach in zehn Jahren über 40 Milliarden US-Dollar in mehr als 5.000 Cybersecurity-Startups geflossen sind, während Sicherheitsverletzungen häufiger sind als je zuvor. Die Ursache liegt nicht im Mangel an Werkzeugen, sondern in ihrer Fragmentierung: Organisationen werden von Alerts überwältigt und übersehen echte Angriffe.
So weit ist der Befund unstrittig. Umstritten ist, was daraus folgt.
Ein Begriff, vier Bedeutungen
Wer „Shift Up“ recherchiert, findet vier veröffentlichte Definitionen. Sie widersprechen sich nicht im Ton, aber in der Achse. Und die Achse ist der ganze Inhalt des Begriffs, denn „oben“ ist nur relativ zu einer Richtung definiert.
| Absender | Achse | „Oben“ bedeutet |
|---|---|---|
| ReversingLabs | Betrachtungsumfang | Von der Einzelkomponente hinauf zur gesamten Software Supply Chain. Vorstand, Finanzfunktion und Risikoquantifizierung kommen nicht vor. |
| Uptycs | Werkzeuglandschaft | Auflösung von Tool-, Team- und Infrastruktursilos über vereinheitlichte Telemetrie und eine gemeinsame Plattform. |
| Kovrr | Organisationshierarchie | Vom IT-Bereich hinauf in C-Suite und Aufsichtsgremium, mit finanziell quantifiziertem Risiko als gemeinsamer Sprache. |
| Jon Robinson | Architekturtiefe | Qualitätssicherung beginnt nicht am Zeitstrahl, sondern bei Modell-, Agenten- und Kontextlogik. |
| Prozesszentrische Lesart | Wertschöpfung | Vom technischen Artefakt hinauf zum Geschäftsprozess, der den Wert erzeugt. |
Die prozesszentrische Lesart: Security folgt dem Wertstrom
Die fünfte Lesart kommt nicht aus dem Anbietermarkt, sondern aus einer Security-Organisation, die selbst Kunden durch Transformationen führt. Andreas Hauke, Head of the Office of the Chief Security Officer bei SAP, beschreibt sie öffentlich auf LinkedIn als Ergebnis einer Co-Engineering-Arbeit mit einem australischen Verkehrsministerium.
Seine Formulierung: Nach Jahren des „Shift Left“ bestehe die nächste Aufgabe darin, die Lücke zwischen Security und dem Geschäft zu schließen und Security über die gesamte Wertschöpfungskette des Kunden einzubetten. Sein Leitsatz dahinter lautet, dass jede Geschäftstransformation von einer Security-Transformation begleitet wird.
Der zweite Teil des Arguments ist der eigentlich entscheidende: Wenn Kunden sich in Richtung autonomes Unternehmen bewegen und KI in Geschäftsprozessen verankert wird, muss Security dieselbe Richtung nehmen und die Prozesse schützen, die realen Wert erzeugen.
Diese Lesart ist zudem metaphorisch konsistent. Shift Left bewegt sich entlang des Entwicklungszyklus. Der prozesszentrische Shift Up steht senkrecht dazu, auf derselben technischen Landkarte: von der System- und Codeebene hinauf zur Prozessebene. Die hierarchische Lesart wechselt dagegen die Bezugsgröße vollständig. Ihr „oben“ liegt im Organigramm und hat mit der Achse, auf der Shift Left operierte, nichts mehr zu tun.
Zur Einordnung gehört auch die Grenze: Es handelt sich um die öffentlich dargelegte Position eines Security-Verantwortlichen, nicht um ein publiziertes Framework oder eine Produktankündigung. Sie ist als Denkrichtung belastbar, nicht als Beschaffungsgrundlage.
Was das im SAP-Kontext konkret heißt
Für Verantwortliche komplexer SAP-Landschaften ist der Unterschied zwischen den Lesarten kein akademischer. SAP-Systeme verbinden Finanz-, HR-, Lieferketten- und Produktionsprozesse so eng, dass jede Schwachstelle systemkritisch wirkt. Die klassische SAP-Sicherheitsarchitektur war dennoch reaktiv organisiert: Berechtigungskonzepte als Compliance-Übung, GRC-Werkzeuge als Auditvorbereitung, Patch-Management als Betriebsaufgabe.
Prozesszentrisch gedacht verschiebt sich nicht die Zuständigkeit, sondern die Bezugsgröße jeder einzelnen Maßnahme.
| Dimension | Bezugsgröße bisher | Bezugsgröße prozesszentrisch |
|---|---|---|
| Berechtigungskonzept | Rolle und Transaktion | Prozessschritt und die Entscheidung, die dort getroffen wird |
| Patch-Priorisierung | CVSS-Score des Systems | Kritikalität der Prozesse, die auf dem System laufen |
| KI-Agenten | Modell- und Plattformabsicherung | Welche Prozessschritte darf der Agent auslösen, und wer prüft das Ergebnis |
| Schnittstellen | Technische Inventarliste | Prozessabhängigkeit: welcher Wertstrom bricht, wenn die Schnittstelle fällt |
| Incident-Bewertung | Betroffene Systeme | Unterbrochene Prozesse und deren Beitrag zum Ergebnis |
Der praktische Effekt zeigt sich bei agentischer KI am deutlichsten. Ein Agent, der Fertigungsaufträge freigibt oder Zahlungen abstimmt, ist kein Anwendungsfall für Modellsicherheit allein. Die relevante Frage ist, welche Prozessschritte er verändern darf und an welcher Stelle ein Mensch gegenzeichnet. Diese Frage lässt sich auf einer Systemlandkarte nicht beantworten, auf einer Prozesslandkarte schon.
Vier Richtungen, ein Wort
Die Toolchain: was sie leistet und was sie nicht leistet
Das interessanteste Element der prozesszentrischen Lesart ist die Behauptung, man brauche dafür kein neues Werkzeug. Wer Geschäftstransformationen betreibt, hat Prozessmodellierung und Enterprise-Architektur bereits im Haus. Beides erzeugt genau die Landkarte, die eine prozessorientierte Security braucht.
Der Beleg dafür ist allerdings differenzierter, als die These nahelegt. Ich habe geprüft, was die Hersteller selbst dokumentieren.
Enterprise-Architektur (SAP LeanIX): Das Modul für Technologierisiko und Compliance clustert Softwareversionen automatisch zu auswertbaren Fact Sheets, erkennt, welche Eigenentwicklungen auf welchen Standard-Stacks laufen, und pflegt Lifecycle-Daten zu Supporttypen und Supportfristen. Daraus entstehen Reports zur Ursachenanalyse technischer Schulden und Roadmaps für Komponenten, deren Support ausläuft. Was auf der Produktseite ausdrücklich nicht als eigenständige Funktion beschrieben wird: Abhängigkeitsanalyse als benanntes Feature und direkte Konnektoren zu Security-Werkzeugen. Der Nutzen liegt im Bestandsbild und im Veralterungsrisiko, nicht in einer fertigen Sicherheitsanalyse.
Prozessebene (SAP Signavio): Der Hersteller beschreibt für Risiko und Kontrolle eine Vorgehensweise in vier Schritten, nämlich Prozesse dokumentieren, Risiken und Engpässe identifizieren, Kontrollen implementieren und laufend überwachen, und nennt als unterstützte Regelwerke unter anderem SOX, Basel und Dodd-Frank. Konkrete Funktionsnamen für die Verknüpfung einzelner Risiken mit einzelnen Prozessschritten führt die Produktseite nicht auf.
Realistisch ist deshalb diese Formulierung: Prozessmodell und Architekturrepository sind die belastbare Grundlage, auf der sich Kritikalität überhaupt begründen lässt. Ohne sie ist jede Priorisierung eine Meinung. Mit ihnen wird sie nachvollziehbar. Die Verbindung zur Security ist Arbeit, die eine Organisation selbst leisten muss, und Hauke formuliert sie folgerichtig als Gelegenheit, nicht als vorhandene Lösung.
Risikoquantifizierung: der Governance-Baustein
Damit ist die hierarchische Lesart nicht erledigt, sie hat nur den falschen Platz eingenommen. Cyber Risk Quantification übersetzt technische Exposition in finanzielle Schadenspotenziale. Das ist die Sprache, die Vorstand, Aufsichtsrat und Regulierung verlangen, und sie ersetzt den CVSS-Score, den am Vorstandstisch niemand einordnen kann.
Kovrr beschreibt diese Strategie als Neurahmung von Cybersecurity als geschäftliches Kernrisiko, die CISOs, C-Suite und Aufsichtsgremien um finanziell quantifizierte Risikoerkenntnisse ausrichtet. Als Governance-Instrument ist das schlüssig.
Nur ist Quantifizierung eine Konsequenz und kein Ausgangspunkt. Sie setzt voraus, dass bekannt ist, welcher Prozess welchen Wert erzeugt und welches Ereignis ihn unterbricht. Wer versucht, Risiken zu beziffern, bevor er die Prozesse kennt, produziert Zahlen mit Nachkommastellen und ohne Fundament. In der Reihenfolge liegt der Unterschied zwischen belastbarer Governance und einer Kennzahl, die im nächsten Audit auseinanderfällt.
Strategische SWOT-Analyse der prozesszentrischen Ausrichtung
Stärken
- Priorisierung wird begründbar statt meinungsbasiert
- Nutzt vorhandene Transformationsartefakte weiter
- Trägt direkt in die Absicherung agentischer KI hinein
- Spricht die Sprache der Fachbereiche, nicht nur der IT
Schwächen
- Setzt gepflegte Prozessmodelle voraus, die vielerorts fehlen
- Keine fertige Produktbrücke zwischen Prozess und Security
- Erfordert Zusammenarbeit von Security, Fachbereich und Architektur
- Bislang kein publiziertes Framework, nur eine Denkrichtung
Chancen
- Transformationsprogramme als natürlicher Einstiegspunkt
- Agentische KI erzwingt die Prozessfrage ohnehin
- Prozesskritikalität als Grundlage belastbarer Quantifizierung
- Security wird früh Teil der Wertdiskussion statt späte Bremse
Risiken
- Prozessmodell veraltet schneller als die Landschaft sich ändert
- Sichtbarkeit wird mit Kontrolle verwechselt
- Begriffsverwirrung: jeder Anbieter besetzt „Shift Up“ anders
- Ohne Governance-Anbindung bleibt es eine Fachbereichsübung
Reifegradmodell: der prozesszentrische Transformationspfad
Regulatorische Beschleuniger: NIS2, DORA und die Offenlegungspflichten
Die regulatorische Lage wirkt in dieselbe Richtung, allerdings aus einem anderen Grund als oft dargestellt. NIS2 verpflichtet Unternehmen, Cybersicherheitsrisiken in die Unternehmensführung zu integrieren, und nimmt Leitungsorgane persönlich in die Pflicht. DORA verlangt von Finanzdienstleistern operative Resilienz einschließlich der Drittparteien. Die US-Offenlegungsregeln verlangen die Meldung wesentlicher Cybervorfälle.
Entscheidend ist das gemeinsame Merkmal dieser Regelwerke: Sie fragen nach Auswirkung, nicht nach Schwachstelle. Wesentlichkeit, operative Resilienz und Betriebsunterbrechung sind Prozessbegriffe. Eine Organisation, die ihre Risiken nur nach Systemen sortiert hat, kann keine dieser Fragen sauber beantworten.
| Regelwerk | Kernforderung | Warum das prozessorientiert ist |
|---|---|---|
| NIS2 | Cybersicherheit in der Unternehmensführung, Haftung der Leitung | Haftung bemisst sich an Auswirkungen auf den Betrieb, nicht an Schwachstellenzahlen |
| DORA | Operative Resilienz einschließlich Drittparteien | Resilienz ist als Fortführung kritischer Funktionen definiert, also prozessual |
| Offenlegungspflichten | Meldung wesentlicher Vorfälle | Wesentlichkeit lässt sich nur über den betroffenen Wertstrom begründen |
Schlüsselerkenntnisse
- Der Begriff trägt keine Bedeutung, nur eine Richtung. Fragen Sie bei jeder Shift-Up-Präsentation nach der Achse. Vier veröffentlichte Definitionen zeigen in vier Richtungen, und drei davon fallen mit der Produktkategorie des Absenders zusammen.
- Das Schutzobjekt hat sich verschoben. Solange Software nur Werkzeug war, war der Code das Schutzobjekt. Wenn Agenten Prozessschritte ausführen, ist es der Prozess.
- Sichtbarkeit ist nicht Kontrolle. Weder Architekturrepository noch Prozessmodell erzeugen Sicherheitsentscheidungen. Sie machen sie begründbar. Das ist viel wert, aber es ist nicht dasselbe.
- Quantifizierung gehört ans Ende. Finanzielle Risikoaussagen setzen Prozesskenntnis voraus. Umgekehrt entstehen Zahlen ohne Fundament.
- Die Regulierung fragt bereits prozessual. Wesentlichkeit und operative Resilienz sind keine Systembegriffe. Wer nur nach Systemen inventarisiert hat, kann nicht antworten.
Priorisierte Handlungsempfehlungen
| Priorität | Maßnahme | Wirkung | Zeithorizont |
|---|---|---|---|
| 1 Kritisch | Die fünf wertkritischsten Prozesse benennen und den Systemen zuordnen, auf denen sie laufen | Priorisierung wird erstmals begründbar | 0 bis 3 Monate |
| 2 Hoch | Für jeden produktiven KI-Agenten festhalten, welche Prozessschritte er auslösen darf und wer gegenzeichnet | Schließt die Lücke, die agentische KI gerade aufreißt | 0 bis 6 Monate |
| 3 Hoch | Vorhandene Prozessmodelle und das Architekturrepository auf Aktualität prüfen, bevor Security darauf aufsetzt | Verhindert Entscheidungen auf veralteter Landkarte | 3 bis 6 Monate |
| 4 Mittel | Patch- und Berechtigungspriorisierung von Systemkritikalität auf Prozesskritikalität umstellen | Ressourcen folgen dem Wert statt dem Score | 6 bis 12 Monate |
| 5 Mittel | Risikoquantifizierung auf der Prozesskritikalität aufsetzen und an die Governance anbinden | Berichtsfähigkeit gegenüber Aufsicht und Gremien | 12 bis 18 Monate |
Implementierungsüberlegungen
Die prozesszentrische Ausrichtung ist kein Softwareprojekt, und sie scheitert an anderer Stelle als erwartet. Der häufigste Fehler ist der Start mit einem Werkzeug. Ein Prozessmodellierungswerkzeug ohne gepflegte Modelle ist ein leeres Regal, und ein Architekturrepository, das den letzten Migrationsstand nicht kennt, führt Security-Entscheidungen zuverlässig in die Irre.
Drei Voraussetzungen müssen zusammenkommen. Es braucht mindestens für die wertkritischen Prozesse aktuelle Modelle. Es braucht eine belastbare Zuordnung zwischen Prozessschritt und ausführendem System, was in gewachsenen SAP-Landschaften mit Eigenentwicklungen und Schnittstellen die eigentliche Arbeit ist. Und es braucht eine gemeinsame Arbeitsweise von Security, Fachbereich und Enterprise-Architektur, drei Bereichen mit selten deckungsgleichen Prioritäten.
Häufig gestellte Fragen
Was unterscheidet Shift Up konkret von Shift Left?
Shift Left verschiebt Sicherheitsprüfungen zeitlich nach vorn im Entwicklungszyklus, bleibt dabei aber auf der Ebene technischer Artefakte. Shift Up wechselt in der prozesszentrischen Lesart die Abstraktionsebene: Bezugsgröße ist nicht mehr das Codeartefakt oder das System, sondern der Geschäftsprozess, der den Wert erzeugt. Beide Bewegungen schließen sich nicht aus, sie verlaufen senkrecht zueinander. Wichtig ist die Vorwarnung, dass andere Absender denselben Begriff für andere Achsen verwenden, etwa für den Aufstieg der Security ins Aufsichtsgremium.
Warum gibt es vier verschiedene Definitionen von Shift Up?
Weil der Begriff nie von einer Institution normiert wurde und weil er sich gut verkauft. ReversingLabs meint die Ausweitung auf die Software Supply Chain, Uptycs die Konsolidierung der Werkzeuglandschaft, Kovrr die Verankerung im Aufsichtsgremium über finanzielle Risikoquantifizierung, Jon Robinson den Einstieg der Qualitätssicherung bei Modell- und Agentenlogik. In drei dieser vier Fälle entspricht die Definition exakt der Produktkategorie des Absenders. Für die eigene Strategiearbeit ist deshalb die erste Frage immer, welche Achse gemeint ist.
Was ändert sich durch Shift Up bei der Absicherung von KI-Agenten?
Die Leitfrage verschiebt sich von der Modell- und Plattformsicherheit zur Prozessberechtigung. Ein Agent, der Fertigungsaufträge freigibt oder Zahlungen abstimmt, ist kein Modellproblem, sondern ein Prozessproblem: Welche Schritte darf er auslösen, welche Grenzwerte gelten, an welcher Stelle zeichnet ein Mensch gegen, und wie wird eine Fehlentscheidung erkannt und zurückgerollt. Diese Fragen lassen sich auf einer Systemlandkarte nicht beantworten, auf einer Prozesslandkarte schon.
Reichen Prozessmodellierung und Enterprise-Architektur als Security-Werkzeuge aus?
Nein, und das sollte man nicht behaupten. Nach der Herstellerdokumentation liefert das Architekturrepository Bestandsbild, Lifecycle- und Veralterungsrisiko sowie Auswertungen zu technischen Schulden; Abhängigkeitsanalyse als benanntes Feature und direkte Security-Konnektoren werden dort nicht beschrieben. Die Prozessseite beschreibt ein Vorgehen aus Dokumentieren, Risiken identifizieren, Kontrollen implementieren und Überwachen sowie unterstützte Regelwerke, aber keine namentlichen Funktionen für die Verknüpfung einzelner Risiken mit einzelnen Prozessschritten. Beides liefert die Landkarte, auf der Kritikalität begründbar wird. Die Sicherheitsentscheidung bleibt Arbeit der Organisation.
Ist Cyber Risk Quantification damit überflüssig?
Im Gegenteil, aber sie steht an anderer Stelle. Quantifizierung ist die Sprache gegenüber Vorstand, Aufsicht und Versicherern und für NIS2, DORA und Offenlegungspflichten praktisch unverzichtbar. Sie setzt allerdings voraus, dass bekannt ist, welcher Prozess welchen Wert erzeugt und welches Ereignis ihn unterbricht. Wer quantifiziert, bevor er die Prozesse kennt, erzeugt präzise wirkende Zahlen ohne Fundament. Die richtige Reihenfolge ist erst Prozesskritikalität, dann Bewertung, dann Berichtsweg.
Wie unterscheidet sich Shift Up von Zero Trust?
Zero Trust ist ein technisches Architekturprinzip und legt fest, wie Identitäten, Netzwerke und Zugriffe gestaltet werden. Die prozesszentrische Shift-Up-Lesart legt fest, woran sich diese Gestaltung ausrichtet, nämlich am Wert des betroffenen Prozesses. Die Konzepte sind komplementär: Zero Trust beantwortet, wie Zugriff kontrolliert wird, Shift Up beantwortet, welcher Zugriff überhaupt wie kritisch ist. Zero Trust ohne diese Priorisierung führt zu gleichmäßig verteiltem Aufwand über ungleich wichtige Prozesse.
Fazit
Shift Left war ein sinnvolles Ordnungsprinzip für eine Welt, in der Software gebaut und danach benutzt wurde. Diese Trennung löst sich auf, wenn Agenten im Betrieb Entscheidungen treffen, die vorher Menschen getroffen haben.
„Shift Up“ ist der Begriff, der diese Lücke füllen soll, aber er ist derzeit vier Begriffe in einem. Drei davon beschreiben ein Produkt. Der vierte beschreibt eine Verschiebung des Schutzobjekts vom technischen Artefakt zum wertschöpfenden Prozess, und nur diese Verschiebung verändert tatsächlich, wie eine Organisation Sicherheit priorisiert.
Die praktische Konsequenz ist unspektakulär und deshalb belastbar: Bevor Sie die nächste Plattform evaluieren oder das nächste Risikomodell aufsetzen, benennen Sie die fünf Prozesse, ohne die Ihr Geschäft steht, und finden Sie heraus, welche Systeme und welche Agenten darin arbeiten. Wer diese Liste nicht hat, priorisiert Sicherheit nach Bauchgefühl, unabhängig davon, wie viele Werkzeuge im Einsatz sind und auf welcher Hierarchieebene darüber gesprochen wird.
Quellen: Andreas Hauke, Head of the Office of the Chief Security Officer bei SAP, öffentlicher LinkedIn-Beitrag zur prozesszentrischen Lesart; ReversingLabs (Matt Rose, Field CISO); Uptycs, das für die Investitionszahl Crunchbase als Quelle angibt; Kovrr (Cyber Risk Quantification Research); Jon Robinson via LinkedIn Pulse; Herstellerdokumentation von SAP LeanIX und SAP Signavio. Produktaussagen geben ausschließlich wieder, was die Hersteller selbst dokumentieren. Keine Zahlen wurden ohne Quellennachweis verwendet.
