--- title: "Role Model and RACI" description: "Eight roles, their areas of responsibility, and a complete RACI matrix for the 25 central framework activities." sidebar: order: 4 label: "Role Model and RACI" source_url: "https://framework.stackit.cloud/advisory/cloud-vision-and-strategy/role-model-raci/" source_file: "docs/advisory/cloud-vision-and-strategy/role-model-raci.mdx" --- ## 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). | 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.