Cloud Governance: Guardrails, Policies and Evidence

Microsoft’s Cloud Adoption Framework gives a precise definition: cloud governance is how an organization controls its use of cloud services by establishing guardrails, a set of policies, procedures, and tools that define acceptable and unacceptable cloud activities. It covers several domains at once: security, regulatory compliance, operations, cost management, data management, resource provisioning, and newer areas such as AI. The same framework stresses that governance is not a one-time project but a continuous cycle of assessing risk, writing policy, enforcing it, and monitoring compliance.

This page covers governance in general. For the cost-specific version, see the cloud cost governance framework.

Three layers of control

Governance has three kinds of control, and each provider supplies the first two differently.

Who may act (identity). IAM roles and permissions decide which principals can call which APIs.

What may exist (policy). Organization-level policy constrains how resources can be configured, regardless of who creates them.

What actually happened (evidence). Logs, inventories, and compliance reports show whether the first two worked.

How each provider implements the policy layer

• AWS Organizations service control policies (SCPs) set the maximum available permissions for accounts in an organization or organizational unit. AWS describes them as coarse-grained guardrails: they do not grant access themselves, and the effective permissions are the intersection of the SCP and the identity or resource policies.
• Azure Policy evaluates resources against rules with effects including audit, deny, modify, append, and deployIfNotExists, so the same definition can report a violation, block it, or correct it.
• Google Cloud’s Organization Policy Service configures constraints across the resource hierarchy, set on an organization, folder, or project. Google draws the distinction cleanly: IAM focuses on who can act, Organization Policy focuses on what, meaning how resources can be configured. Typical constraints restrict resource locations, limit service account usage, and restrict resource sharing by domain.

Choosing between prevent, detect, and correct

Prevention (deny) is the strongest control and the most disruptive when a rule is wrong. Detection (audit) never blocks and depends on someone reading the report. Correction (modify, or automated remediation) fixes drift but changes resources on the owner’s behalf. A practical order is to start new rules in audit mode, measure how often they would have fired, then promote to deny or modify when the false-positive rate is known.

Governance for the tools you add

Every platform with write access to your cloud is part of the governed estate. Apply the same questions to it: who can use it, what it may change, and what record it leaves. In ZopNight, the gateway enforces role-based access with Admin, Editor, and Viewer roles plus custom roles scoped to specific resources; every mutating API request is written to an audit log; destructive remediations can require admin approval; and an account connected read-only is blocked server-side from starting, stopping, or remediating anything. See RBAC and audit trail.

Keeping it alive

• Assign an owner to each policy and review it on a schedule.
• Track exceptions as records with expiry dates, not as undocumented gaps.
• Report compliance levels and violations over time, as the Cloud Adoption Framework recommends, so governance can show whether it is improving.
• Treat infrastructure-as-code review as a governance point too; see infrastructure as code.