--- title: "Shared Responsibility & Ausnahmemanagement" description: "Das Shared-Responsibility-Modell in der Cloud, Ausnahmemanagement für Leitplanken-Abweichungen und der Eskalationspfad bei Governance-Konflikten." sidebar: order: 3 label: "Shared Responsibility" source_url: "https://framework.stackit.cloud/de/advisory/governance/shared-responsibility/" source_file: "docs/de/advisory/governance/shared-responsibility.mdx" --- ## Das Drei-Schichten-Verantwortungsmodell Cloud Governance funktioniert nur, wenn klar ist, wer welche Verantwortung trägt. Es ist ein häufiger Fehler, die Verantwortung nur zwischen „Cloud-Anbieter“ und „uns“ aufzuteilen. In der Praxis bedarf es einer genaueren Unterscheidung über drei Ebenen hinweg — denn innerhalb der Organisation sind nicht alle Parteien gleichermaßen verantwortlich. Der Anbieter liefert das technische Fundament: Rechenzentren, Hardware, Netzwerkinfrastruktur, Virtualisierung und Zugriff auf Cloud-Services über APIs und Portale. Die Verantwortung des Anbieters endet dort, wo die Organisation die bereitgestellten Leistungen konsumiert. Das interne Cloud-Team ist verantwortlich für Governance, Standards, Sicherheitsanforderungen und die technische Plattform. Es schützt nicht einzelne Anwendungen, sondern setzt den Rahmen, innerhalb dessen Anwendungsteams sicher arbeiten können. Ohne diesen Rahmen entsteht unkontrolliertes Wachstum. Die Teams, die Applikationen erstellen und betreiben, sind für die korrekte Nutzung der bereitgestellten Plattform verantwortlich. Sie entscheiden über Deployments, Konfigurationen und den Betrieb ihrer Workloads — innerhalb der vom Cloud-Team festgelegten Grenzen. Die kritische Erkenntnis: „Der Provider ist sicher“ bedeutet nicht, dass Ihre Ressourcen beim Provider sicher konfiguriert sind. Eine falsch konfigurierte IAM-Richtlinie, ein öffentlich zugänglicher Storage Bucket, ein Container ohne Sicherheitskontext — das liegt in der Verantwortung des Anwendungsteams, nicht des Anbieters. Das Cloud-Team legt die Leitplanken fest, die solche Fehler erkennen oder verhindern. ## CCoE vs. Platform Team: zwei unterschiedliche Funktionen Innerhalb des Cloud-Teams gibt es eine weitere wichtige Unterscheidung, die in der Praxis häufig verwischt und zu Reibungen führt. Das **Cloud Center of Excellence (CCoE)** verantwortet Governance und Standards — es definiert, _was_ gilt: Richtlinien, Sicherheitsanforderungen, Compliance-Kontrollen, Kostenmanagement, Servicekatalog. Es beantwortet die Frage: „Wie muss und darf die Cloud aussehen?“ Der CCoE berät Anwendungsteams, setzt Leitplanken und kontrolliert deren Einhaltung. Das **Cloud Platform Team** ist verantwortlich für die technische Implementierung und den Betrieb — es setzt das _Wie_ um: Landing Zone, Netzwerkinfrastruktur, Automatisierung, Self-Service-Plattformen, Monitoring der Plattformkomponenten. Es beantwortet die Frage: „Wie ist das, was der CCoE definiert hat, technisch realisiert?“ Diese Trennung verhindert, dass Governance-Entscheidungen stillschweigend durch technische Umsetzungsentscheidungen ersetzt werden — und umgekehrt Governance zum Papiertiger wird, weil niemand sie umsetzt. ## Ausnahmemanagement: Wenn Leitplanken zu restriktiv sind Leitplanken sind nicht für jede Situation perfekt. Es wird berechtigte Fälle geben, in denen ein Team von einem Standard abweichen muss. Das Ausnahmemanagement ist hierfür der strukturierte Prozess. ### Ausnahmekategorien | Kategorie | Beispiel | Genehmigungsstufe | Maximale Dauer | | ----------------------------- | -------------------------------------------------------------------- | ------------------- | --------------------------------- | | **Technische Notwendigkeit** | App benötigt aus betrieblichen Gründen eine öffentliche IP | CCoE | 90 Tage, danach Review | | **Migrationsphase** | Altsystem kann Verschlüsselung kurzfristig nicht unterstützen | CCoE | 30 Tage, dann Eskalation | | **Compliance-Ausnahme** | Regulatorische Anforderung widerspricht technischem Standard | CISO + CCoE | 12 Monate, danach Review | | **Architekturabweichung** | Neue Technik passt nicht zum Standardmuster | CCoE + Architect | 90 Tage, dann Standardisierung | ### Ausnahmeprozess Der Ausnahmeprozess folgt fünf Schritten: Das Team beantragt die Ausnahme mit Begründung und geplanter Dauer (Request). Der CCoE prüft innerhalb von 2 Werktagen — ist die Abweichung akzeptabel oder muss eine Alternative gefunden werden? (Review). Bei einer positiven Entscheidung füllt das Team ein Ausnahmeformular aus: Beschreibung des Standards, Begründung für die Abweichung, Risikobewertung, Mitigationsmaßnahmen, Dauer und Prüfdatum — unterschrieben vom CCoE Lead, bei Sicherheitsausnahmen zusätzlich vom CISO (Approval). Die Ausnahme wird im Ausnahmeprotokoll dokumentiert, eine Kalendererinnerung wird gesetzt und sie wird monatlich im Governance-Bericht aufgeführt (Monitoring). Zum Prüftermin entscheidet der CCoE: die Ausnahme schließen und den Standard umsetzen oder eine Verlängerung beantragen — mit Eskalation durch den CCoE, damit Ausnahmen nicht stillschweigend dauerhaft werden (Review / Verlängerung). ## Das Ausnahmeprotokoll: Transparenz über Abweichungen Der CCoE führt ein fortlaufendes Ausnahmeprotokoll — sichtbar für CIO, CISO und Cloud Strategy Board: | ID | Ressource/Workload | Abweichender Standard | Begründung | Dauer | Freigegeben von | Status | | ------- | ------------------ | ------------------------------ | ---------------------------------------------------------- | -------- | --------------- | ----------- | | EXC-001 | payment-service | Öffentliche IP | Payment-Gateway-API erfordert feste IP | 90 Tage | CCoE Lead | Aktiv | | EXC-002 | legacy-erp | Verschlüsselung im Ruhezustand | Migration läuft, alternative Verschlüsselung aktiviert | 30 Tage | CCoE + CISO | Aktiv | | EXC-003 | dev-sandbox | Geo-Leitplanke | Testing mit EU-Partner-Infrastruktur | 14 Tage | CCoE Lead | Geschlossen | ## Governance-Eskalationspfad | Situation | Eskalieren an | | ------------------------------------------------------------- | ------------------------------------------------------------- | | Team folgt nicht dem Standard, kein Antrag eingereicht | CCoE eskaliert an das Management des Teams | | Ausnahmeantrag abgelehnt, Team legt Einspruch ein | CCoE Lead → CIO | | Compliance-Feststellung aus externer Revision | CISO → Cloud Strategy Board | | Governance-Konflikt zwischen Teams | CCoE vermittelt, CIO entscheidet über Eskalation | | Kritische Security-Ausnahme erforderlich | CISO sofort informiert, Entscheidung im Vier-Augen-Prinzip | ## Governance-Bericht: Was das Cloud Strategy Board sieht Der CCoE liefert quartalsweise einen Governance-Bericht an das Cloud Strategy Board: 1. **Compliance-Scorecard**: alle Leitplanken, % Compliance, Trend 2. **Ausnahmenübersicht**: wie viele aktive Ausnahmen, welche Risikokategorie 3. **Sicherheitsfeststellungen**: Vorfälle, Untersuchungen, Behebungen 4. **Regulatorische Aktualisierungen**: neue oder geänderte Anforderungen 5. **Empfehlungen**: Was muss das Board entscheiden bzw. worüber informiert werden? ## Praktische Schritte 1. **Ausnahmeprozess formalisieren** und kommunizieren 2. **Ausnahmeprotokoll einrichten** in CCoE-Tools (Confluence, Jira oder eine einfache Tabellenkalkulation) 3. **Governance-Berichtsvorlage erstellen** 4. **Quartalsweise Governance-Prüfung** im Board-Kalender einplanen