--- title: "Shared Responsibility & Exception Management" description: "The shared responsibility model in the cloud, exception management for guardrail deviations, and the escalation path for governance conflicts." sidebar: order: 3 label: "Shared Responsibility" source_url: "https://framework.stackit.cloud/advisory/governance/shared-responsibility/" source_file: "docs/advisory/governance/shared-responsibility.mdx" --- ## The three-layer responsibility model Cloud governance only works when it is clear who carries which responsibility. A common mistake is to divide responsibility only between "cloud provider" and "us." In practice, a more precise distinction is needed across three layers — because within the organisation, not all parties are equally responsible. The provider delivers the technical foundation: data centres, hardware, network infrastructure, virtualisation, and access to cloud services via APIs and portals. The provider's responsibility ends where the organisation consumes the provided services. The internal Cloud Team is responsible for governance, standards, security requirements, and the technical platform. It does not protect individual applications — it sets the framework within which application teams can work securely. Without this framework, uncontrolled growth results. The teams building and operating applications are responsible for correctly using the provided platform. They decide on deployments, configurations, and the operation of their workloads — within the boundaries set by the Cloud Team. The critical insight: "The provider is secure" does not mean that your resources at the provider are securely configured. A misconfigured IAM policy, a publicly accessible storage bucket, a container without a security context — that is the responsibility of the application team, not the provider. The Cloud Team sets the guardrails that detect or prevent such errors. ## CCoE vs. Platform Team: Two distinct functions Within the Cloud Team there is a further important distinction that is frequently blurred in practice, leading to friction. The **Cloud Center of Excellence (CCoE)** is responsible for governance and standards — it defines _what_ applies: policies, security requirements, compliance controls, cost management, the service catalogue. It answers the question: "What must and may the cloud look like?" The CCoE advises application teams, establishes guardrails, and monitors compliance. The **Cloud Platform Team** is responsible for technical implementation and operations — it implements _how_: Landing Zone, network infrastructure, automation, self-service platforms, monitoring of platform components. It answers the question: "How is what the CCoE has defined technically realised?" This separation prevents governance decisions from being silently replaced by technical implementation decisions — and conversely, governance becoming a paper tiger because nobody implements it. ## Exception Management: When guardrails are too restrictive Guardrails are not perfect for every situation. There will be legitimate cases where a team must deviate from a standard. Exception management is the structured process for this. ### Exception categories | Category | Example | Approval level | Maximum duration | | -------------------------- | --------------------------------------------------------- | ---------------- | ----------------------------- | | **Technical necessity** | App requires a public IP for operational reasons | CCoE | 90 days, then review | | **Migration phase** | Legacy system cannot support encryption in the short term | CCoE | 30 days, then escalation | | **Compliance exception** | Regulatory requirement conflicts with technical standard | CISO + CCoE | 12 months, then review | | **Architecture deviation** | New technology does not fit standard pattern | CCoE + Architect | 90 days, then standardisation | ### Exception process The exception process follows five steps: the team requests the exception with justification and planned duration (Request). The CCoE reviews within 2 business days — is the deviation acceptable or must an alternative be found? (Review). On a positive decision, the team completes an exception form: description of the standard, justification for the deviation, risk assessment, mitigation measures, duration and review date — signed by the CCoE Lead, for security exceptions additionally by the CISO (Approval). The exception is documented in the exception log, a calendar reminder is set, and it is listed monthly in the governance report (Monitoring). At the review date, the CCoE decides: close the exception and implement the standard, or request an extension — with CCoE escalation to ensure exceptions do not silently become permanent (Review / Extension). ## The exception log: transparency over deviations The CCoE maintains a running exception log — visible to CIO, CISO and Cloud Strategy Board: | ID | Resource/Workload | Deviated standard | Justification | Duration | Approved by | Status | | ------- | ----------------- | ------------------ | ---------------------------------------------------- | -------- | ----------- | ------ | | EXC-001 | payment-service | Public IP | Payment gateway API requires fixed IP | 90 days | CCoE Lead | Active | | EXC-002 | legacy-erp | Encryption at rest | Migration underway, alternative encryption activated | 30 days | CCoE + CISO | Active | | EXC-003 | dev-sandbox | Geo-guardrail | Testing with EU partner infrastructure | 14 days | CCoE Lead | Closed | ## Governance escalation path | Situation | Escalate to | | ------------------------------------------------- | ------------------------------------------------------------ | | Team not following standard, no request submitted | CCoE escalates to the team's management | | Exception request rejected, team appeals | CCoE Lead → CIO | | Compliance finding from external audit | CISO → Cloud Strategy Board | | Governance conflict between teams | CCoE mediates, CIO decides on escalation | | Critical security exception requirement | CISO informed immediately, decision with four-eyes principle | ## Governance report: what the Cloud Strategy Board sees Quarterly, the CCoE delivers a governance report to the Cloud Strategy Board: 1. **Compliance scorecard**: All guardrails, % compliance, trend 2. **Exception overview**: How many active exceptions, which risk category 3. **Security findings**: Incidents, investigations, resolutions 4. **Regulatory updates**: New or changed requirements 5. **Recommendations**: What must the Board decide or be informed about? ## Practical steps 1. **Formalise and communicate** the exception process 2. **Set up the exception log** in CCoE tooling (Confluence, Jira, or a simple spreadsheet) 3. **Create a governance report template** 4. **Schedule quarterly governance review** in the Board calendar