--- title: Account Governance description: Define account and project topology, ownership boundaries, and guardrails as the organizational control plane for migration. sidebar: label: Account Governance order: 10 source_url: "https://framework.stackit.cloud/migration/design-and-mobilize/landing-zones/account-governance/" source_file: "docs/migration/design-and-mobilize/landing-zones/account-governance.mdx" --- ## Purpose Account governance defines how you separate environments, teams, and responsibilities in a way that remains auditable and scalable. It creates the organizational control plane for migration waves: where workloads are hosted, who owns which scope, and how new projects are added without bypassing guardrails. ## Governance hierarchy ![Governance hierarchy from customer account and folders to projects, resources, and labels](./files/stackit-governance-hierarchy.svg) ## Governance design and delivery ### Core governance building blocks - **Regions**: Region strategy determines data locality, latency profile, and resilience boundaries for workloads and shared services. Define region usage principles early and align them with compliance and continuity requirements. Documentation - **Customer Account**: The customer account is the top governance boundary for ownership, billing, and administration. It is the anchor for organization-wide standards and control responsibilities. Documentation - **STACKIT Folder**: Folders structure organizational domains (for example platform, shared services, business units, environments) and allow policy inheritance and clean delegation models. Resource Manager - **STACKIT Projects**: Projects are the delivery scopes where resources are deployed and operated. They should be attached to folders through a defined onboarding model, not created ad hoc. Resource Manager ### How these elements work together - **Region principles first**: Define which regions are allowed for which workload classes. - **Customer account as governance root**: Set global ownership, policy intent, and financial accountability. - **Folders for structure and delegation**: Translate the operating model into scalable organizational boundaries. - **Projects for delivery**: Provision project scopes through a standard lifecycle with mandatory controls inherited from the folder model. ### Key design decisions - **Region governance model**: Decide single-region, dual-region, or workload-based region strategy and required exceptions. - **Customer-account responsibilities**: Define which central teams own governance, billing oversight, and control operations. - **Folder topology**: Decide how folders map to domains such as platform, environments, and business units. - **Project onboarding model**: Standardize project creation, naming, tagging, and lifecycle controls. - **Policy and exceptions**: Define mandatory guardrails and transparent exception workflows. ### Typical outputs - **Governance blueprint**: Customer-account, folder, and project topology with ownership matrix. - **Region usage policy**: Approved region patterns per workload type and risk profile. - **Project onboarding standard**: Repeatable process for creating and connecting governed projects. - **Control baseline**: Enforced naming, tagging, and policy controls with documented exception flow. ## Related Target Operating Model guidance [Governance and Decision Making](/migration/design-and-mobilize/operating-model/governance-and-decision-making/) assigns decision rights and escalation paths for these account, folder, and project boundaries. ### Anti-patterns to avoid - **No region policy**: Region selection per team or project without enterprise rules. - **Unstructured project sprawl**: Projects created without folder strategy, ownership clarity, or lifecycle standards. - **Governance only on paper**: Controls documented but not embedded in project onboarding and operations.