What should cloud and security teams do with resources that are still outside IaC?

Treat them as governed exceptions and prioritise them for migration into code. The main goal is to bring manual assets into the same deployment and policy path as the rest of the estate, so they can inherit validation, change tracking, and repeatable security controls.

Why unmanaged outside-IaC resources are a control problem, not just technical debt

Anything still outside infrastructure as code sits on a weaker governance path: it is harder to review, harder to reproduce, and easier to drift from policy. That matters because manual changes bypass the normal controls that make cloud estates predictable, including versioned review, testing, rollback, and consistent guardrails. The right response is to treat these assets as temporary exceptions, not a separate operating model.

Resources outside IaC also tend to accumulate hidden exceptions. Over time, they become the places where emergency fixes, one-off permissions, and undocumented dependencies survive longest, which increases the chance that the “real” environment and the documented environment diverge.

What “governed exception” means in practice

A governed exception is a resource that is explicitly known, owned, time-bounded, and tracked through migration. It should have an accountable owner, a reason for being outside code, a review date, and a clear path into the same deployment and policy workflow as everything else. For cloud teams, that usually means a backlog item to codify the resource, not a permanent exemption.

This is also where workload and privilege design become important. If the resource depends on manual credentials or ad hoc access, the migration plan should include not just the infrastructure definition but also the access path, so that policy, identity, and deployment controls move together rather than creating a new gap after the move.

For teams managing cloud entitlements, the Cloud PAM and CIEM Guide is useful because right-sizing access often exposes the same manual assets that need to be brought under code. Likewise, the Cloud Workload Identity Guide helps teams think about the identity mechanics that should be normalised when a manual resource is finally codified.

How to migrate without creating more risk

Prioritise by blast radius and change frequency. Start with externally reachable, privileged, or business-critical resources, then move the items that change often or already show evidence of drift. The objective is not to convert everything at once, but to reduce the size of the uncontrolled surface quickly while preserving service continuity.

Migration works best when it is treated as a control remediation programme, not a refactor project. Capture the current state, define the desired code-managed state, then compare the two for configuration drift, access paths, and hidden dependencies before cutting over. Where resources are hard to codify immediately, standardise compensating controls such as tighter approvals, stronger monitoring, and a fixed expiry date for the exception.

The Identity Security Posture Management (ISPM) Guide is relevant here because unmanaged cloud resources often correlate with stale permissions, standing access, and configuration drift. Bringing them into code makes those issues easier to detect and correct systematically.

Why this matters for repeatable security and auditability

Code-managed resources are easier to validate before deployment and easier to prove after deployment. That gives security teams a much better chance of enforcing baseline controls consistently, because changes move through the same review, testing, and evidence path instead of being scattered across consoles and tickets. It also improves incident response, because the team can tell which state was intended and when it changed.

If a resource cannot yet be expressed as code, the control question becomes whether the exception is still justified. The longer it remains manual, the more the organisation depends on memory and local knowledge rather than a repeatable control plane. In practice, that is where audit findings, missed patches, and inconsistent access review tend to appear first.

For cloud posture and validation controls, the NIST Cybersecurity Framework 2.0 supports the broader govern, identify, protect, detect, respond, recover lifecycle that code-managed resources fit naturally into. The NIST SP 800-53 Rev 5 Security and Privacy Controls is also relevant where teams need a control catalog for configuration management, access control, auditability, and system integrity.

Risk and Threat Considerations

Manual cloud assets are attractive because they are easier to overlook, harder to inventory, and more likely to retain stale permissions or undocumented access paths. That creates exposure not only to drift and misconfiguration, but also to privilege accumulation and slower containment when something goes wrong.

Failure mechanism: A resource that remains outside IaC can diverge from the approved baseline, keep unreviewed access, or escape change tracking entirely. Those conditions make it easier for misconfigurations to persist and harder for defenders to prove what changed, when, and by whom.

Impact: The organisation loses consistency, auditability, and rollback confidence, and an attacker or accidental operator error can exploit the weaker control path to expand impact before the issue is noticed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Manual cloud resources need standardised, reviewable configuration to reduce drift.
Recommendation — Inventory and baseline outside-IaC resources, then codify and harden them through standard configuration control.
NIST CSF 2.0	ID.AM-01 — Physical devices and systems are inventoried	You must know which resources still sit outside IaC before you can govern them.
	PR.PS-01 — Configurations are managed consistent with policy	The question is about moving manual assets into a managed, policy-driven deployment path.
Recommendation — Inventory manual cloud assets and track them as exceptions until they are migrated into code. Move exceptions into a policy-managed deployment process and enforce configuration baselines.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	Outside-IaC resources need an approved baseline before they can be governed consistently.
	CM-6 — Configuration Settings	Uncodified resources are a common source of drift in configuration settings.
Recommendation — Establish and maintain baselines for any manual cloud asset pending codification. Apply approved configuration settings and validate them against the codified standard.

Practitioner Guidance

What to prioritise: Classify every non-IaC resource by business criticality, privilege level, and exposure. High-impact or internet-facing assets should be first in the migration queue, because they carry the largest control gap if left manual.

Decision rule: If the resource is still needed, give it a named owner, an expiry date for the exception, and a codification plan; if it is no longer needed, retire it instead of preserving a manual exception.

What to verify: Before trusting the exception, verify that the resource is inventoried, monitored, and covered by compensating controls for access, change review, and configuration drift. If you cannot evidence those three things, it should not remain outside the governed path for long.

Practitioner takeaway: The goal is not to tolerate manual cloud assets indefinitely, it is to shrink their lifetime until the environment is managed primarily through repeatable code, policy, and review.