Governance, Policy and Guardrails

FinOps governance sets the rules for spending — required tags, allowed regions and sizes, budget thresholds, commitment approval — and enforces them with preventive and detective guardrails rather than manual approvals.

Governance answers: what are the rules, and how do we keep them without slowing everyone down? In the cloud, the answer is guardrails, not gates.

flowchart LR
  POL["Policy: written rules"] --> PREV["Preventive: block at creation"]
  POL --> DET["Detective: find and report"]
  POL --> CORR["Corrective: fix automatically"]
  PREV --> TEAM["Teams build freely inside the guardrails"]
  DET --> TEAM
  CORR --> TEAM
  %% step POL: Write a short policy: required tags, allowed regions and sizes, who may buy commitments.
  %% step PREV: Preventive controls stop non-compliant resources: SCPs, Azure Policy deny, IaC checks.
  %% step DET: Detective controls find what slipped through: reports, Config rules, policy scans.
  %% step CORR: Corrective controls fix or stop things automatically, mostly in non-production.
  %% step TEAM: Inside these limits, teams create resources without waiting for approval.

Typical FinOps policies

Policy	Enforcement examples
Required tags (`team`, `env`, `cost-center`)	AWS tag policies + SCP deny without tag, Azure Policy, GCP org policy, Terraform checks
Allowed regions	SCP / Azure Policy deny outside approved regions
Instance size limits in sandboxes	SCP or policy on instance types; budget actions
Budgets per account/team	Budgets with alerts; actions only in sandboxes
Commitment purchases	Only the central FinOps team may buy; procurement involved above a threshold
Data retention	Default lifecycle and log retention in landing-zone templates

Preventive vs detective

Preventive controls give the strongest result but can block legitimate work; start with detective reports, communicate, then switch to deny when compliance is high. Policy-as-code (OPA/Conftest, Sentinel, Checkov, Cloud Custodian) lets the same rules run in CI and in production.

Risk and exceptions

Every rule needs an exception process (with an owner and expiry date). Track policy compliance as a KPI, and review exceptions in the monthly review.

Intersecting disciplines

FinOps governance overlaps with security (keys, regions), ITAM (licences), procurement (contracts) and sustainability (carbon). Coordinate rules so teams get one consistent set of guardrails, not five.

Traps: requiring approval tickets for every resource (teams route around it); switching on deny policies without warning; and policies with no exception path, which push teams to shadow accounts.