Cloud governance policy generator · free AI skill

Generates a complete cloud governance policy document covering resource tagging standards, approved regions and services, cost threshold alerts, access control policies, and security baseline requirements — calibrated…

Purpose

Produce a ready-to-adopt cloud governance policy document that translates organizational context — size, compliance obligations, provider mix, and risk tolerance — into concrete, enforceable guardrails across tagging, region/service allowlists, cost controls, access management, and security baselines. Eliminates the months-long effort of drafting governance from a blank template and gives a Cloud CoE a defensible, auditable policy artifact.

When to Use

Invoke this skill when the user asks to:

Draft a cloud governance policy or governance framework document
Define resource tagging standards or a mandatory tagging taxonomy
Establish approved regions, services, or a service allowlist/denylist
Set up cost threshold alerts, budgets, or spend guardrails
Document access control (IAM/RBAC) and least-privilege policies
Create security baseline requirements for a landing zone or new account onboarding

Inputs Required

Before starting, collect:

Organization size: Number of teams/accounts, approximate engineer headcount, and cloud maturity (net-new, migrating, or established)
Regulatory environment: Applicable frameworks (e.g., SOC 2, HIPAA, PCI-DSS, GDPR, FedRAMP, ISO 27001) or "none required"
Cloud provider(s): AWS, Azure, GCP, or multi-cloud — and primary vs. secondary
Risk tolerance: Conservative / Balanced / Fast-moving — how much friction the org will accept for control
Data residency constraints: Any countries/regions data must stay in or must avoid
Cost profile: Approximate monthly spend and whether cost overruns are a current pain point
Existing tooling: Any current IaC, SSO/identity provider, or CSPM tools already in place

If risk tolerance is not specified, default to Balanced and note the assumption. If provider is unspecified, default to AWS and flag that region/service names are provider-specific.

Instructions

Produce five policy sections. Each section must contain enforceable rules (not aspirations), an enforcement mechanism (how it's technically enforced), and an exception process. Calibrate strictness to the stated risk tolerance: Conservative = deny-by-default and manual approval gates; Balanced = allowlists with automated exceptions; Fast-moving = detect-and-alert with post-hoc remediation.

Section 1: Resource Tagging Standards

Define the mandatory tagging taxonomy.

Required tags: Specify 6–9 mandatory tags with allowed value formats. Standard set: environment (prod/staging/dev), owner (email or team alias), cost-center, application, data-classification (public/internal/confidential/restricted), managed-by (terraform/manual), plus 1–2 regulatory-driven tags if compliance frameworks apply
Enforcement: Tag policies (AWS Organizations Tag Policy / Azure Policy / GCP Org Policy) that block or flag untagged resource creation; IaC pre-commit tag validation
Data-classification tie-in: Map each classification level to downstream controls (encryption, access, retention)
Non-compliance handling: Grace period for existing resources, blocking for new resources based on risk tolerance

Section 2: Approved Regions and Services

Define where and what teams can deploy.

Approved regions: List permitted regions driven by data residency constraints; explicitly deny all others via service control policy / Azure Policy
Service allowlist/denylist: Categorize services into Approved (self-service), Restricted (requires CoE review — e.g., public data stores, ML services with data egress), and Denied (e.g., deprecated or non-compliant services)
Enforcement: SCPs (AWS), Azure Policy denyAssignments, or GCP Organization Policy constraints
New service onboarding: The review checklist a service must pass before joining the allowlist (compliance posture, encryption support, logging support, cost model)

Section 3: Cost Threshold Alerts and Budget Controls

Define spend guardrails calibrated to the org's cost profile.

Budget tiers: Set per-account and per-team monthly budgets; define alert thresholds at 50%, 80%, 100%, and 120% of budget
Anomaly detection: Enable cost anomaly detection (AWS Cost Anomaly Detection / Azure Cost Management alerts) with a defined dollar or percentage trigger
Hard vs. soft limits: For Conservative orgs, define automated actions at 120% (e.g., disable non-prod resources); for others, escalation-only
Tag-driven allocation: Reference the cost-center and application tags for showback/chargeback
Escalation path: Who is notified at each threshold and expected response time

Section 4: Access Control Policies

Define identity, authentication, and authorization rules.

Identity model: Centralized SSO via the org's IdP; no long-lived local users; federated access only
Least-privilege baseline: Define standard roles (read-only auditor, developer, deployer, admin, break-glass) with scope-of-access per role
Privileged access: Require MFA for all human access; just-in-time elevation for admin roles; break-glass account with monitored, alarmed usage
Service-to-service auth: Use workload identity / instance roles / managed identities — never static keys; define secret rotation cadence
Enforcement: IAM permission boundaries, SCP guardrails, conditional access policies; periodic access review cadence (quarterly recommended, monthly for Conservative)

Section 5: Security Baseline Requirements

Define the non-negotiable minimum security controls.

Encryption: Encryption at rest (CMK vs. provider-managed based on data-classification) and in transit (TLS 1.2+) as mandatory
Logging and monitoring: Centralized audit logging (CloudTrail / Azure Activity Log / GCP Audit Logs), log retention period aligned to regulatory requirements, and delivery to an immutable log archive
Network baseline: Default-deny security groups/NSGs, no public ingress without CoE approval, private subnets for data tiers
Vulnerability and posture management: Enable CSPM/native posture tooling (Security Hub / Defender for Cloud / Security Command Center); define remediation SLA by severity
Regulatory mapping: For each applicable framework, map baseline controls to the specific control families they satisfy
Enforcement: Detective controls via CSPM, preventive controls via policy-as-code, remediation SLAs by severity (e.g., Critical: 24h, High: 7d)

Final Section: Governance Operating Model

Close with the policy's operating mechanics:

Ownership: Who owns the policy (CoE) and who enforces it
Exception process: How teams request exceptions, who approves, and how exceptions are time-boxed and tracked
Review cadence: How often the policy is reviewed and updated
Version and effective date: Document version, effective date, and approval line

Output Format

Structure: Formal policy document with numbered sections; each control stated as a rule with enforcement mechanism and exception note
Length: 1,400–2,000 words
Format: Structured document — headed sections with sub-headings, bulleted rules, and tables for tagging taxonomy and role definitions
Sections: Document header (version/scope) → 1. Tagging Standards → 2. Approved Regions & Services → 3. Cost Controls → 4. Access Control → 5. Security Baseline → Governance Operating Model
Tone: Authoritative and precise, as a policy document should read — declarative rules ("must," "shall," "is prohibited"), no marketing language, no hedging

Quality Checklist

Before delivering output, verify:

[ ] All five core sections plus the operating model section are present
[ ] Tagging standards define 6–9 required tags with specific allowed value formats
[ ] Region and service rules are provider-specific and reference actual enforcement mechanisms (SCP, Azure Policy, Org Policy)
[ ] Cost section specifies numeric alert thresholds (50/80/100/120%) and a defined escalation path
[ ] Access control specifies MFA, least-privilege roles, and a break-glass procedure
[ ] Every regulatory framework named in the inputs is mapped to at least one concrete control
[ ] Strictness of controls matches the stated risk tolerance (deny-by-default vs. detect-and-alert)

Notes

The single highest-leverage section for most orgs is tagging — without enforced tags, cost allocation, access scoping, and data-classification controls all degrade. Lead with it and make it airtight.
For multi-cloud inputs, produce parallel enforcement mechanisms per provider rather than a lowest-common-denominator policy — the underlying rule stays the same, but the technical control differs.
Recommend the org adopt this policy as policy-as-code (OPA/Conftest, Sentinel, or native policy engines) rather than a static PDF — a governance policy that isn't machine-enforced drifts within a quarter.
If regulatory environment is "none required," still recommend a SOC 2-aligned baseline as a forward-looking default and note it as optional.

How to use this skill

This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.

Installing in Claude Code:

~/.claude/skills/<folder-name>/SKILL.md — auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)
<your-project>/.claude/skills/<folder-name>/SKILL.md — auto-loads only when working in that project (recommended for project-specific skills)

Restart Claude Code or open a new session to register.

Using in Claude.ai, ChatGPT, Gemini, or other AI tools:

Drag this file into a new chat, or copy and paste its contents
Send your task or request as your next message — the AI will apply the skill where it fits

For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills