Purpose
Section titled “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
Section titled “Governance hierarchy”Governance design and delivery
Section titled “Governance design and delivery”Core governance building blocks
Section titled “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
Section titled “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
Section titled “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
Section titled “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
Section titled “Related Target Operating Model guidance”Governance and Decision Making assigns decision rights and escalation paths for these account, folder, and project boundaries.
Anti-patterns to avoid
Section titled “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.