Notifications
Clear all
Topic starter
10/06/2026 11:02 pm
TL;DR: Unmanaged infrastructure can carry up to 2x the security risk of governed resources, while internal research found actual IaC coverage is typically 30% to 40% lower than teams assume, according to ControlMonkey. The real issue is not visibility alone but whether cloud governance is tied to the delivery path that creates risk.
NHIMG editorial — what this means for NHI practitioners
By the numbers:
- Actual coverage is typically 30% to 40% lower than teams assume.
Questions worth separating out
Q: How should security teams measure whether infrastructure is actually governed by IaC?
A: Start by measuring coverage, drift, and exception volume together.
Q: Why do unmanaged infrastructure resources create more security risk than governed ones?
A: Unmanaged resources bypass the code path that makes change review, policy enforcement, and remediation repeatable.
Q: What breaks when drifted infrastructure is patched before it is reconciled?
A: The patch may not match the actual live configuration, which means the underlying exposure can remain even after the code is updated.
Practitioner guidance
- Define IaC coverage thresholds as policy gates Set explicit coverage bands for production environments and require exceptions when resources fall below agreed thresholds.
- Separate unmanaged, drifted, and in-sync remediation paths Do not treat every vulnerable resource the same.
- Build one operating view for cloud and security teams Use a shared dashboard for coverage, drift, and exposure so platform owners and security leads are resolving the same facts.
What's in the full announcement
ControlMonkey's full product announcement covers the operational detail this post intentionally leaves for the source:
- The exact colour-coded IaC Risk Index thresholds and how ControlMonkey applies them across environments
- The one-click remediation workflow for importing unmanaged resources and generating compliant Terraform code
- The shared dashboard workflow that connects delivery method, vulnerability mapping, and exception handling
- The onboarding assessment path for teams that want an IaC Risk review before rollout
👉 Read ControlMonkey's announcement on the IaC Risk Index for cloud governance →
IaC Risk Index: what it means for cloud governance teams?
Explore further
12/06/2026 4:50 am
IaC coverage has become a governance boundary, not a tooling preference. Once infrastructure is created outside Terraform, the organisation loses a consistent control plane for review, remediation, and policy enforcement. That is why unmanaged infrastructure carries a different risk profile from governed infrastructure. The practitioner takeaway is to treat IaC coverage as a control boundary that defines whether security can reason about the environment at all.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who should own IaC risk governance when DevOps and security share the same environment?
A: Ownership should sit with the team that controls the delivery path, but security must define the policy boundaries and escalation rules. If ownership is split without a shared view of coverage and exceptions, no one can prove whether a resource is governed, drifted, or unmanaged.
👉 Read our full editorial: IaC risk scoring shows where Terraform coverage leaves security gaps
