The Governance That Makes Things Worse
There is a category of cloud governance that produces the exact opposite of its intended effect. It is identifiable by a consistent set of symptoms: shadow IT that grows faster than the central cloud team can track, development teams that find workarounds for governance controls rather than working within them, engineering velocity that declines as the governance overhead increases, and a growing perception among engineering leaders that governance is the enemy of delivery.
This governance exists in many large enterprises. It was designed with genuine intent to manage cloud risk, control costs, and maintain compliance. And it systematically produces the dynamics that make the risk harder to manage, the costs harder to control, and the compliance harder to assure.
The failure is not in the intent. It is in the design. Most cloud governance frameworks are designed for control: to prevent things from happening that the governance owner does not want to happen. Control-oriented governance relies on approval processes, policy enforcement, and human review. It places the governance function in the path of the decisions it is designed to govern. And it creates the friction that drives the behaviours it was designed to prevent.
This first article in a three-part series diagnoses the design failures in control-oriented cloud governance. The second and third articles build the alternative: a governance model designed for enablement rather than control.
The Approval Process That Creates the Problem It Solves
The most common form of control-oriented governance is the change approval process: the requirement that cloud configuration changes pass through a review and approval gate before being deployed to production. The approval gate exists to prevent risky changes from reaching production without review. It often produces the opposite effect.
The change approval process that takes three to five business days to process a routine change creates a powerful incentive for engineering teams to find paths around it. Teams that cannot wait three days for a configuration change will deploy to production without approval, work in accounts that are outside the governance framework’s visibility, or categorise changes as “routine” to avoid the approval queue. Each of these responses increases the risk that the approval process was designed to reduce.
The approval process that requires a security or architecture review for every cloud resource provisioning request creates an operational model that does not scale. When the volume of provisioning requests exceeds the review capacity, the governance team becomes a bottleneck. Development teams wait for approvals. Delivery timelines slip. The governance team acquires a reputation as an obstacle to delivery. And the development teams develop creative interpretations of what requires approval and what does not.
The failure mode is not unique to cloud governance. It is the failure mode of any control system that creates friction in proportion to transaction volume rather than in proportion to transaction risk. A governance control that applies the same review intensity to a low-risk routine change as to a high-risk architecture change is miscalibrated by design.
The Policy Framework That Cannot Be Enforced
The second design failure is the policy framework that is theoretically complete but practically unenforceable. Many enterprise cloud governance programmes produce extensive policy documentation: acceptable use policies, security configuration standards, cost management policies, and architecture standards. The documentation is thorough. The enforcement is sporadic.
The unenforceability has two common causes. The first is that the policies were written without consideration for how they would be technically enforced. Policies that require human review to verify compliance can only be verified as frequently as the review cadence allows, which for most governance programmes means quarterly or annually. Between reviews, the policies are guidelines that motivated teams follow and unmotivated teams ignore.
The second cause is that the policies are too numerous and too detailed to be consistently applied. A security policy with 200 configuration requirements that apply across all cloud environments provides a compliance team with a clear audit checklist but provides an engineering team with an operationally impractical standard. The engineering team that attempts to apply 200 configuration requirements to every deployment will slow delivery significantly. The one that applies the most visible requirements and ignores the obscure ones will pass the next audit on the 70 requirements the auditor checks and fail on the 130 they do not.
Both causes produce the same outcome: a policy framework that creates compliance overhead without producing the security posture or risk management outcomes it was designed to deliver.
The Accountability Structure Without Authority
The third design failure is the accountability structure that assigns ownership of cloud governance without giving the owner the authority required to exercise that ownership effectively. The cloud governance function that is accountable for cloud security posture but cannot enforce security controls on the engineering teams that provision cloud resources is set up to fail in a very specific way.
The failure pattern is predictable. The governance function identifies a security gap. It issues guidance or a policy requiring remediation. The engineering team with the gap acknowledges the guidance and continues with its current priorities, because remediation is not resourced in its sprint backlog and the governance function cannot require it to be. The gap persists. The governance function escalates. The escalation lands in a leadership conversation about prioritisation that the governance function is not positioned to win against delivery priorities. The gap persists longer.
This failure pattern repeats across enterprise cloud governance programmes. The governance function is visible and active. The security posture does not improve at the pace the activity level suggests it should. The disconnect is structural: accountability for outcomes that require authority over others is unachievable without that authority.
The structural fix requires either giving the governance function the authority to enforce its recommendations — which requires organisational design changes that most enterprises resist — or designing governance so that enforcement is automatic rather than dependent on authority relationships.
What Comes Next
The three design failures described above are not inevitable features of cloud governance. They are consequences of a design philosophy that treats governance as a control mechanism operating through human approval, policy compliance, and organisational authority.
The second article in this series examines the alternative design philosophy: governance designed as an enablement mechanism that operates through automation, built-in controls, and guardrails that guide rather than obstruct. The third article provides the measurement framework that proves governance designed this way is working.
The argument across the series is that the choice between control and enablement is not a choice between rigour and permissiveness. It is a choice between two implementation strategies, one of which produces better security outcomes, better cost control, and better compliance than the other.
The one that works is not the one most enterprises have built.