Notifications
Clear all
Topic starter
12/06/2026 12:20 am
TL;DR: As cloud estates expand from a few accounts to dozens across environments, business units, and tools, visibility, compliance, and change control break down unless every change is forced through code, according to ControlMonkey. The governance problem is not account count itself but the lack of enforceable automation, resilience, and auditability across the full infrastructure lifecycle.
NHIMG editorial — based on content published by ControlMonkey: multi-account cloud governance and the limits of IaC
Questions worth separating out
Q: How should security teams govern cloud accounts when estates keep growing?
A: They should treat account growth as a control-design problem, not a provisioning problem.
Q: Why does multi-account cloud create risk even when the architecture is intentional?
A: Because separation improves isolation only if governance keeps pace.
Q: What do teams get wrong about infrastructure as code?
A: They often treat IaC as a tool purchase instead of a control boundary.
Practitioner guidance
- Measure real IaC coverage by environment Separate code-managed changes from console-driven and ticket-driven changes across dev, staging, and production, then track bypasses as governance exceptions.
- Eliminate direct-change paths for production accounts Restrict manual edits to emergency break-glass workflows with logging, review, and post-change reconciliation so the pipeline remains the default control point.
- Create a single account and resource inventory Consolidate account metadata, resource ownership, and policy state so security, compliance, and engineering teams work from the same control view.
What's in the full article
ControlMonkey's full blog post covers the operational detail this post intentionally leaves for the source:
- Practical questions for assessing real IaC coverage across environments and teams
- Operational guidance on detecting manual change paths that bypass Terraform or OpenTofu
- A working model for visibility, automation, and resilience across multi-account cloud estates
- The article's own framing for reducing toil, audit friction, and production drift
👉 Read ControlMonkey's analysis of multi-account cloud governance and IaC enforcement →
Multi-account cloud sprawl: what IAM teams are missing?
Explore further
12/06/2026 9:30 am
Multi-account cloud sprawl is really an identity governance problem disguised as an infrastructure problem. Once access, change rights, and approvals are spread across dozens of accounts, the question is no longer how many environments exist. The question is whether governance can still prove who can change what, where, and under which control path. That makes cloud estate design inseparable from IAM and NHI lifecycle discipline.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 35.6% of organisations cite managing consistent access across hybrid and multi-cloud environments as their top NHI security challenge, which shows how often governance problems are still underestimated in distributed estates.
A question worth separating out:
Q: How do you know if cloud governance is actually working?
A: Look for three signals: every account is visible, every change has a code path, and production state can be restored and validated without manual detective work. If any of those require tribal knowledge, the governance model is too fragile for continued scale.
👉 Read our full editorial: Multi-account cloud sprawl exposes the limits of IaC governance
