Role Model and RACI

Why a Role Model?

A cloud transformation rarely fails because of technology. It fails because it is unclear who decides what, who needs to be informed, and who ultimately bears responsibility. The RACI model answers this question for each of the central activities in the framework — before the ambiguity becomes an obstacle.

RACI stands for four types of responsibility. Responsible designates the person who executes or coordinates a task. Accountable is the person who must ultimately answer for it — exactly one per activity. Consulted are people whose input is sought before a decision is made. Informed are people who are notified of the outcome without being actively involved.

The role model of this framework is deliberately functional, not hierarchical. A CIO can be Accountable for the overall strategy and Informed on technical detail decisions at the same time. The roles describe responsibility, not job profiles.

The Eight Roles

CIO — Chief Information Officer

The CIO is the sponsor and ultimate decision-maker of the cloud transformation. They are responsible for strategic direction, secure the budget, and serve as the link between IT transformation and corporate leadership. In the Advisory phase, the CIO makes the fundamental decisions: what cloud strategy do we pursue? With which provider? On what time horizon? In the Adoption phase, the CIO is primarily an escalation authority and communicator upwards and outwards.

The CIO is the only role accountable for the entire transformation strategy. Without an active, visible CIO as sponsor, cloud transformations fail not because of budget, but because of organisational energy.

CTO — Chief Technology Officer

The CTO is responsible for technical architecture and platform strategy. They ensure that the technical decisions of the transformation are consistent, serve the long-term goals of the organisation, and do not end in a technology zoo. In organisations without a separate CTO role, this function is typically performed by a Head of Architecture or an Enterprise Architect.

The CTO is the bridge between strategic vision and technical reality. They answer the question: is what we are doing also what we will want to do in five years?

CISO — Chief Information Security Officer

The CISO is responsible for security requirements and their enforcement in the cloud environment. They define the security baseline, assess risks, and ensure that compliance requirements — GDPR, BSI IT-Grundschutz, TISAX, BAIT — are translated into technical controls.

The CISO is often the most critical stakeholder in cloud transformations: they can slow a transformation if their requirements are not engaged early, and they are one of the most important enablers when security is built into the architecture from the beginning rather than bolted on retrospectively.

Cloud Architect

The Cloud Architect is the technical lead of the transformation at platform level. They design the landing zone, define the network topology, set up guardrails, and are the first point of contact for technical architecture decisions by product teams. The Cloud Architect is not a bottleneck — they are an enabler who provides patterns and reference architectures so that product teams can build independently.

Platform Owner

The Platform Owner is responsible for operating the cloud platform as an internal product. They ensure that the platform is available, up to date, and usable by product teams. The Platform Owner works closely with the Cloud Architect and is responsible for operations while the Architect is responsible for design.

FinOps Lead

The FinOps Lead is responsible for cost transparency, cost governance, and the introduction of FinOps practices in the organisation. They coordinate between Finance, IT, and Business, operate the tagging framework, conduct rightsizing reviews, and communicate cloud costs comprehensibly to all stakeholders.

The FinOps Lead is not a purely IT role. The most successful FinOps programmes are led by people who bring both controlling affinity and technical understanding.

IAM Lead

The IAM Lead is responsible for the identity and access architecture of the entire cloud environment. They define the RBAC concept, introduce the IDP, enforce MFA, and ensure that least-privilege principles are operationally lived. The IAM Lead works closely with the CISO but is an independent operational role.

CCoE Lead — Cloud Centre of Excellence Lead

The CCoE Lead coordinates the Cloud Centre of Excellence and is responsible for ensuring that knowledge, standards, and best practices are distributed throughout the organisation. They organise guilds, build the champions network, coordinate training programmes, and are the first point of contact for teams that need support with cloud adoption.

The CCoE Lead is one of the most impactful roles in the transformation — and one of the most frequently underestimated. An effective CCoE multiplies the impact of all other roles.

RACI Matrix

In the following matrix: R = Responsible (executes / coordinates), A = Accountable (bears ultimate responsibility), C = Consulted (input sought), I = Informed (notified of outcome).

Swipe sideways to see the whole table

Activity	CIO	CTO	CISO	Cloud Arch.	Platform Owner	FinOps Lead	IAM Lead	CCoE Lead
STRATEGY & GOVERNANCE
Adopt cloud strategy	A	C	C	C	—	C	—	I
Select cloud provider	A	R	C	R	—	C	C	I
Adopt governance charter	A	C	R	C	—	—	C	C
Build compliance register	I	—	A	—	—	—	C	R
Define security baseline	I	C	A	R	C	—	R	C
Approve cloud budget	A	C	—	—	—	R	—	I
ORGANISATION & ROLES
Found and commission CCoE	A	C	C	—	—	—	—	R
Introduce RACI model	A	C	C	C	C	C	C	R
Set up training programme	I	C	C	C	—	—	—	A/R
Build champions network	I	—	—	C	—	—	—	A/R
Introduce operating model (YBIYRI)	A	R	C	R	R	—	—	C
PLATFORM & LANDING ZONE
Design landing zone	I	A	C	R	C	—	C	—
Put landing zone into operation	I	A	C	R	R	—	—	—
Implement guardrails	I	C	A	R	R	—	C	—
Approve network topology	I	A	C	R	C	—	—	—
FINANCE & COSTS
Define tagging standard	I	C	—	C	C	A/R	—	C
Introduce showback	I	—	—	—	C	A/R	—	C
Introduce chargeback	C	—	—	—	C	A/R	—	C
Establish rightsizing process	I	—	—	—	C	A/R	—	—
IDENTITY & ACCESS
Set up IDP federation	I	C	C	C	R	—	A/R	—
Enforce MFA for all users	I	—	A	—	R	—	R	—
Define RBAC matrix	I	C	A	C	—	—	R	—
Introduce access review process	I	—	A	—	—	—	R	—
PROCUREMENT & LEGAL
Conclude DPA with provider	A	—	R	—	—	—	—	—
Review EVB-IT Cloud contract	A	C	R	—	—	—	—	—

Notes on Application

The RACI matrix is a starting point, not an immutable document. Every organisation has a different leadership structure, different role definitions, and different decision-making paths. The matrix should be discussed within the leadership team at the start of the Advisory phase, adapted, and then formally adopted.

Three patterns that frequently occur in application and affect the quality of the matrix: first, too many A entries for one person. Accountability must be assigned sparingly. If one person is accountable for 15 of 25 activities, that is not a leadership model — it is a diagnosis of overload. Second, missing R entries. If nobody is listed as Responsible for an activity, it will either not be done or spontaneously taken over by the wrong person. Third, too many C entries. If all roles are consulted for every activity, that slows down decision-making without proportional quality gain.