Shared Responsibility & Exception Management

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.

Cloud Service Provider (CSP)

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.

Cloud Team (CCoE + Platform Team)

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.

Application Teams

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

Swipe sideways to see the whole table

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:

Swipe sideways to see the whole table

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

Swipe sideways to see the whole table

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