Notifications
Clear all
Topic starter
12/06/2026 12:26 am
TL;DR: Infrastructure as Code coverage should be treated as a security metric because unmanaged resources sit outside preventative controls, remediation, and auditability, and the post links low coverage to twice the risk of governed infrastructure, according to ControlMonkey. The editorial takeaway is that coverage now functions as a forward-looking indicator of cloud identity and control-plane exposure, not just delivery consistency.
NHIMG editorial — based on content published by ControlMonkey: IaC coverage as a security metric
Questions worth separating out
Q: How should cloud teams measure Infrastructure as Code coverage in practice?
A: Measure the percentage of cloud resources managed through approved code paths versus those created manually or by script.
Q: Why do unmanaged cloud resources increase security risk?
A: Unmanaged resources sit outside the controls that make cloud change governable, including policy checks, version control, and auditable approvals.
Q: What do security teams get wrong about IaC coverage?
A: They often treat coverage as a DevOps efficiency measure rather than a control-plane visibility measure.
Practitioner guidance
- Inventory unmanaged infrastructure by control plane Map every cloud account, subscription, and project to resources created outside IaC so you can see where policy-as-code does not apply.
- Track coverage as a risk metric in leadership dashboards Place IaC coverage next to vulnerability and compliance indicators so cloud and security leaders can review the same exposure picture.
- Assign ownership for every unmanaged resource class Give each unmanaged resource a named owner, remediation path, and target system of record so it can be folded into code or explicitly retired.
What's in the full article
ControlMonkey's full blog post covers the operational detail this post intentionally leaves for the source:
- The full coverage-to-risk index used to bucket environments into low, medium, and high exposure bands
- The exact symptoms ControlMonkey associates with different coverage thresholds across cloud estates
- The practical dashboarding and remediation workflow the vendor recommends for cloud and security teams
- The detailed explanation of how unmanaged resources affect visibility, validation, and change accountability
👉 Read ControlMonkey's analysis of why IaC coverage belongs on security dashboards →
IaC coverage: what cloud and security teams are missing?
Explore further
12/06/2026 9:40 am
IaC coverage is now a security control boundary, not an engineering preference. The article is right to separate managed from unmanaged infrastructure because the boundary determines whether preventative controls can operate at all. Once resources exist outside code, policy enforcement becomes inconsistent and auditability becomes partial. For practitioners, the important shift is to treat coverage as a governance boundary that defines where security can and cannot reliably intervene.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
- Only 13% of organisations feel extremely prepared for the reality of agentic AI, even as most are racing toward autonomous adoption.
A question worth separating out:
Q: Who should own remediation when cloud resources are outside IaC?
A: Ownership should sit with the team that can either codify the resource or retire it, but security should track the risk until that happens. The key is to avoid orphaned exceptions. If no one is accountable for bringing a resource under code, it will remain outside policy enforcement indefinitely.
👉 Read our full editorial: IaC coverage is becoming a security metric, not just ops hygiene
