---
title: "Cloud Usage Policy: 12 Governance Domains"
description: "The twelve binding governance domains of the Cloud Usage Policy — from asset management through IAM to business continuity. Explained methodically for CCoE, IT architecture, and compliance stakeholders."
sidebar:
  order: 7
  label: "Usage Policy Domains"
source_url: "https://framework.stackit.cloud/advisory/governance/usage-policy-domains/"
source_file: "docs/advisory/governance/usage-policy-domains.mdx"
---

## What a Cloud Usage Policy Delivers

The Cloud Governance Policy defines strategic guidelines and principles. The Cloud Usage Policy translates these guidelines into binding, operational requirements — concrete rules that apply to every person and team that provisions, configures, or operates cloud resources.

A usage policy without structured domains is difficult to enforce: it grows into an opaque ruleset that nobody knows completely and that is expanded inconsistently as new requirements emerge. Structuring into twelve domains creates clarity — each requirement belongs to a clear domain, and stakeholders immediately know which domain is responsible for their topic.

![Cloud Usage Policy Domains](./files/usage-policy-domains.svg)

## Domain 1: Asset Management (AST)

Asset management is the foundation of all other governance domains. Those who don't know which cloud resources exist can neither secure them, operate them cost-efficiently, nor keep them compliant. A complete inventory of all cloud resources is therefore not an optional measure — it is the prerequisite for functioning governance.

Core obligations: every resource is recorded in a central inventory and kept current; every resource has a responsible team or person assigned; all resources follow defined naming conventions; complete tagging per standard is mandatory. Resources without defined owner and without complete tags are by definition non-compliant and must be immediately rectified or removed.

## Domain 2: Cloud Cost Management (FIN)

Uncontrolled cloud consumption leads to significant and unexpected costs. Transparent cost allocation and active management are therefore mandatory requirements for all cloud users — not just the FinOps team.

Every resource must be tagged with mandatory cost allocation tags, budget alerts must be configured, maximum spending limits are technically enforced, and unused or orphaned resources must be regularly identified and removed. Resources with significant cost implications — GPU instances, large database clusters — require explicit approval before deployment.

The chargeback and showback principle ensures that cloud costs are transparently allocated to the causing teams. Cost responsibility without cost transparency is ineffective.

## Domain 3: Identity & Access Management (IAM)

Identities and access permissions are the primary attack vector in cloud environments. The IAM domain defines binding requirements for managing user, service, and system identities, and the governance of access rights.

All access rights are assigned exclusively through roles or groups — never directly to individuals. Every person has an individual, identifiable user identity; shared accounts are prohibited. Multi-factor authentication is mandatory for all cloud resources, without exception for privileged accounts. Access occurs exclusively through the central identity provider — local cloud accounts outside the IdP are not permitted. Privileged access is granted time-limited on a just-in-time basis and regularly reviewed.

## Domain 4: Key & Secret Management (KSM)

Cryptographic keys, secrets, and certificates are critical security assets whose improper management can cause severe security incidents. Secrets are stored exclusively in a dedicated platform-provided secret management service — not in source code, configuration files, or version control systems.

System-managed identities are preferred over static credentials. Secrets and cryptographic keys rotate at defined intervals automatically. Certificates are centrally managed with continuously monitored expiration dates. All access to secrets and keys must be comprehensively logged.

## Domain 5: Network Security (NET)

The network architecture forms the foundation for secure and controlled communication between cloud resources and external systems. The fundamental principle is deny-by-default: all network traffic is denied by default. Communication is permitted only through explicitly defined rules.

Cloud resources are separated into logically distinct network segments. External access occurs only through defined and controlled entry points. Publicly accessible web services and APIs must be protected by a Web Application Firewall. Network traffic is continuously monitored for anomalies.

## Domain 6: Data Classification & Protection (DATA)

All data processed in the cloud must be classified — the classification is the basis for all downstream protection measures. Data may only be stored and processed in approved cloud regions.

All stored data must be encrypted — databases, storage accounts, and backups without exception. Production data must not be used in non-production environments — synthetic or anonymised datasets must be used instead. Sensitive data must be masked in logs, outputs, and interfaces. Cloud workloads processing personal data must be recorded in the processing activities register.

## Domain 7: Vulnerability Management (VUL)

Vulnerabilities in cloud resources, dependencies, and configurations represent a continuous security risk. All cloud resources are regularly and automatically scanned for vulnerabilities. Identified vulnerabilities are classified and prioritised by CVSS.

Binding remediation deadlines by severity: Critical vulnerabilities (CVSS 9.0–10.0) must be remediated within 72 hours. High vulnerabilities (CVSS 7.0–8.9) within 14 days. Medium vulnerabilities (CVSS 4.0–6.9) within 30 days. Low vulnerabilities in the next regular patch cycle. Container and VM images with critical or high vulnerabilities must not be deployed to production environments.

## Domain 8: Security Monitoring (MON)

Continuous monitoring of all cloud resources is essential for early detection of security incidents, misconfigurations, and anomalous behaviour. All cloud resources and workloads must be logged — disabling logging capabilities is not permitted.

Logs are centrally collected and stored — decentralised or isolated log storage is not permitted. Logs must be stored in a tamper-resistant manner. Security-relevant logs must be retained for at least 12 months. Automated alerts must be configured for security-relevant events.

## Domain 9: Incident Response (IR)

A documented incident response plan for cloud environments is mandatory. Security incidents must be classified, prioritised, and handled according to defined procedures. Critical security incidents require notification of the Cloud Team within 4 hours.

All incidents are fully documented — including causes, impacts, and measures taken. After every significant incident, a structured post-incident review with documented lessons learned must be conducted. Forensic investigability of incidents must be ensured through sufficient log retention and incident documentation.

## Domain 10: Business Continuity & Disaster Recovery (BCD)

Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) must be defined for critical applications. These values are the foundation for backup strategy and disaster recovery architecture — without them, no appropriate recovery design can be created.

Backup concepts must meet the defined RPO requirements. Disaster recovery plans must be regularly tested — untested plans are not a safety guarantee. Dependencies between systems must be identified and considered in recovery planning.

## Domain 11: Configuration Management (CFG)

All cloud infrastructure must be defined as code and versioned. Manual configuration changes to production resources are not permitted — all changes occur through the defined IaC process. Configuration changes undergo a formal review and approval process.

Configuration deviations (drift) between the desired and actual state must be automatically detected. All configuration changes are versioned and traceable.

## Domain 12: Platform Security (PSC)

All cloud resources must be hardened according to defined security baselines. Platform-provided security services — endpoint protection, vulnerability scanning, log collection — must be activated on all resources. Non-compliant resources must be identified, remediated, or removed.

The defense-in-depth principle is mandatory: multiple, independent security layers rather than a single measure. Security assessments for cloud environments are conducted regularly and upon significant architecture changes.

## The Usage Policy in Practice

The twelve domains are not equal in their risk potential. IAM, KSM, and NET form the security-critical core — violations in these domains can cause direct security incidents with significant damage potential. AST and FIN form the governance foundation — without complete inventory and cost transparency, none of the other domains can be effectively enforced.

The CCoE is responsible for maintaining, communicating, and enforcing the usage policy. Regular reviews — at least annually — ensure the policy remains current and accounts for new cloud services and risks.