How should security teams measure Infrastructure as Code coverage across GCP projects in multi-cloud environments?

What IaC coverage really means in a multi-cloud GCP estate

IaC coverage is not just a count of templates or pipelines. For security teams, it is the proportion of live cloud resources that are created, changed, and governed through approved code paths rather than manual console activity. In a multi-cloud environment, that measurement has to be normalised across projects, accounts, subscriptions, and teams so the result reflects governance quality, not tool preference.

The most useful view is one that separates governed resources from merely discovered resources, then breaks the results down by GCP project, region, resource type, and provisioning tool. That lets teams see where policy is being applied consistently and where unmanaged assets accumulate. It also exposes a common blind spot: a project can look well covered at the platform level while still containing manually created exceptions that bypass review, approval, or tagging standards.

For teams aligning measurement to control expectations, NIST SP 800-53 Rev 5 Security and Privacy Controls is useful as a control reference because it emphasises configuration management, inventory discipline, and accountability. In practice, many security teams discover their IaC coverage gaps only after an audit, outage, or drift review reveals that “managed” and “coded” were never the same thing.

How to measure it without turning the metric into noise

Start with an asset inventory that can distinguish provisioned-by-code from provisioned-manually, then calculate coverage at the same granularity you operate at. For GCP, that usually means project-level reporting first, then region and resource category, with a separate roll-up for shared services and platform-managed exceptions. A single enterprise-wide percentage is usually too blunt to guide action because it can hide a weak project inside a strong average.

A practical measurement model should answer three questions: what is in scope, what is governed by IaC, and what is outside governance by exception. The “outside” bucket matters because some resources are unmanaged by design, but that should be explicit and time-bound. If teams cannot explain why a resource is excluded, the metric is probably undercounting exposure rather than reporting an acceptable exception.

• Measure by GCP project so ownership remains visible.
• Separate production, non-production, and shared platform projects where operating models differ.
• Track drift as a change indicator, not just a point-in-time percentage.
• Record the provisioning path for each resource, including console, script, pipeline, or imported state.
• Trend unmanaged resources over time so improvement or regression is visible.

Coverage also needs a tool dimension because a multi-cloud estate often uses different infrastructure pipelines for different platforms. If one tool generates GCP resources while another governs AWS or Azure, the measurement should compare like with like rather than flattening different operating models into one figure. That is why coverage should be paired with ownership and exception management, not treated as a standalone health score. Where resource discovery is incomplete or tagging is unreliable, the metric breaks down because teams can no longer tell whether a gap reflects true manual build activity or simply missing telemetry.

Where the metric becomes misleading, and what good reporting looks like

Tighter IaC measurement often increases reporting overhead, requiring organisations to balance governance accuracy against the cost of normalising inventories across clouds. That tradeoff matters because some edge cases are easy to count but hard to interpret, especially when platform teams use break-glass changes, imported resources, or shared modules that do not map neatly to a single source repository.

Coverage numbers become misleading when teams count repositories, modules, or pull requests instead of governed resources. A large codebase does not prove that live assets are controlled, and a small codebase does not mean low maturity if it governs a high proportion of critical resources. The better question is whether the metric reflects operational control over the actual environment. There is no universal consensus on one perfect formula, but there is broad agreement that resource-level coverage is more decision-useful than code-volume metrics.

Good reporting makes the exceptions auditable. That means every excluded resource should have a named owner, a reason, an expiry or review point, and a clear statement of whether it is temporary or permanent. It also means trending should show movement in the right direction: fewer unmanaged resources, fewer stale exceptions, and less drift between desired state and live state. In multi-cloud programmes, teams should expect the shape of coverage to differ by platform and should avoid comparing numbers without first checking whether the underlying provisioning model is the same.

Practitioner Guidance

What to prioritise: Measure governed resources first, not repository counts. If the reporting cannot distinguish live manual assets from code-managed assets, the programme is measuring activity rather than control.

What to verify: Confirm that each GCP project has an owner, each exception has a reason and review date, and each resource can be traced back to a provisioning path. If any of those fields are missing, the coverage figure is too weak to drive decisions.

What good looks like: A mature view shows coverage by project, region, and tool, with unmanaged resources trending down and exceptions shrinking over time. The point is not perfection; it is whether the organisation can see where manual change is still creating ungoverned exposure.

Practitioner takeaway: IaC coverage is most useful when it behaves like a control signal, not a vanity metric. Security teams should optimise for traceability, exception discipline, and trend direction, because that is what turns coverage reporting into meaningful governance.

Related resources from NHI Mgmt Group

• How should security teams maintain accurate cloud inventory across multi-cloud and GCP environments?
• How should security teams implement cloud user access reviews across SaaS and multi-cloud environments?
• How should security teams govern app identity modernization across multi-cloud environments?
• How should security teams implement DSPM across multi-cloud and SaaS environments?