Low coverage increases risk because unmanaged resources are invisible to most preventive controls and are usually repaired manually. That slows remediation, creates more opportunity for error, and allows drift to accumulate across environments. In security terms, the organisation loses standardisation at the point where the cloud estate is changing.
Why low IaC coverage changes the cloud risk profile
Infrastructure as Code works best when it is the normal path for creating, changing, and reviewing cloud resources. When coverage is low, the estate becomes partly governed by hand-built exceptions, console edits, and one-off scripts. That breaks the consistency cloud security depends on, because the organisation no longer has a single, repeatable source of truth for what exists and how it is configured.
Low coverage also means security teams lose visibility over a meaningful share of the environment. Preventive controls, policy checks, and peer review tend to sit around the declared code path, so unmanaged resources can slip outside those guardrails until someone notices them later. At that point, the issue is often not just a misconfiguration, but an unknown asset with an unknown owner and an uncertain change history.
In practice, the risk is amplified by the speed of cloud change. The more frequently environments are created, resized, or reconfigured, the more manual handling becomes a source of drift. For baseline control expectations, see CSA Cloud Controls Matrix and ISO/IEC 27001:2022 Information Security Management.
What unmanaged cloud resources change operationally
Low IaC coverage usually changes three things at once: who can change the environment, how quickly change is detected, and how reliably the intended state can be restored. Manual updates are slower to review and harder to reproduce, so a team can end up with different security settings across what appears to be the same workload pattern.
That inconsistency matters because cloud security is as much about control of configuration as it is about access control. When resources are created outside the codified path, the organisation often loses standard naming, tagging, logging, network boundaries, and approval evidence. The result is not only weaker prevention, but weaker recovery, because responders have less confidence that they can rebuild the environment cleanly after an incident.
That is why cloud control frameworks put so much emphasis on governance, inventory, and secure configuration. A useful reference point is the NIST Cybersecurity Framework 2.0, which ties governance and asset visibility to the rest of the security programme.
Why drift and manual repair are the real failure modes
The immediate problem with low IaC coverage is not simply that “people make mistakes”. The deeper issue is that manual repair creates a feedback loop: one exception leads to another, the environment drifts further from the intended baseline, and each later change has to account for an increasingly unique state. That makes mistakes more likely and makes audits, troubleshooting, and incident response harder.
Drift also creates a blind spot for attackers and for accidental exposure. If a resource is not managed through the same pipeline as the rest of the estate, it may escape scheduled review, policy enforcement, or dependency tracking. In a cloud environment, that can translate into lingering over-permissioned services, unreviewed network exposure, or stale secrets that stay in place far longer than intended. For a control view of that problem, consult the cloud security controls in ISO/IEC 27001:2022 and the NIST Cybersecurity Framework 2.0.
For organisations trying to reduce this class of exposure, the key question is whether exceptions are still rare and tightly owned, or whether they have become a second operating model. Once the second pattern exists, the security problem is no longer just configuration quality, it is control fragmentation.
Risk and Threat Considerations
Low IaC coverage increases both accidental exposure and adversarial opportunity. Unmanaged resources are harder to inventory, harder to monitor, and more likely to retain unsafe defaults or drifted permissions. That makes them attractive targets because they often sit outside the strongest preventive and detective controls.
Failure mechanism: Resources created or changed outside code review bypass standard checks, then accumulate configuration drift, inconsistent access settings, and delayed remediation.
Impact: Security teams lose assurance over what exists in the cloud estate, while attackers and mistakes alike can exploit the weaker visibility, slower repair cycle, and inconsistent baseline.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | IaC gaps often leave cloud resources outside IAM governance and review. |
| GRC — Governance, Risk and Compliance | Low IaC coverage is a governance problem because exceptions and drift weaken control assurance. | |
| Recommendation — Apply IAM controls to inventory, review, and govern all cloud resources. Track IaC exceptions as governed risks with owners, deadlines, and review dates. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Unmanaged cloud resources are a visibility and inventory gap. |
| PR.AA-01 — Identities and credentials are issued, managed, verified, revoked, and audited | Manual cloud change paths often create unmanaged access and inconsistent control. | |
| PR.PS-01 — Configuration management is performed | IaC coverage is directly about maintaining a controlled and consistent configuration baseline. | |
| Recommendation — Inventory all cloud resources, including those not yet managed by code. Audit and standardise access paths used to create or modify cloud resources. Use configuration management to keep cloud state aligned to approved code. | ||
| ISO/IEC 27001:2022 | A.5.23 — Information security for use of cloud services | Cloud service control depends on governance of configuration, visibility, and responsibility. |
| A.8.9 — Configuration management | Low IaC coverage increases drift and inconsistency, which configuration management is meant to prevent. | |
| A.8.32 — Change management | Manual repair and ad hoc changes are a core reason low IaC coverage raises risk. | |
| Recommendation — Define cloud governance rules that require controlled and reviewable changes. Enforce approved baselines and detect configuration drift across cloud resources. Require cloud changes to follow change control with traceable approval and rollback. | ||
Practitioner Guidance
What to prioritise: Treat coverage gaps by environment and resource type, not as a single percentage. The highest-risk gap is usually any class of resource that can be internet-reachable, hold credentials, or influence production access paths.
What to verify: Confirm that every unmanaged resource has an owner, a reason for being outside the IaC path, and a plan to converge back to the standard build pattern. If that evidence does not exist, the resource should be treated as a control exception, not as normal state.
Decision rule: If a manual change alters security posture, access, or exposure, require it to be codified or explicitly time-bound. If it cannot be codified, it should be isolated, reviewed more frequently, and removed as soon as the business need ends.
Practitioner takeaway: Low IaC coverage is dangerous not because code is fashionable, but because security works best when change is repeatable, reviewable, and measurable, and unmanaged resources break all three at once.
Related resources from NHI Mgmt Group
- Why does low alert coverage increase security risk?
- How should cloud security teams evaluate agentless CNAPP coverage across posture, secrets, and IaC risk?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?