Teams should evaluate whether the resource is business critical, security sensitive, and likely to change over time. If it matters to operations or risk, it should usually be brought under Infrastructure as Code so it can be reviewed, versioned, and tracked. If the resource is temporary or obsolete, the better decision may be to remove it instead of importing it.
How teams judge whether an unmanaged cloud resource belongs in code
The real decision is not whether a resource can be imported, but whether its existence needs the same governance as the rest of the environment. A cloud resource that affects uptime, data exposure, auditability, or privilege should be treated as part of the managed control plane, because leaving it outside change control creates an inventory gap that can hide drift and weaken accountability. NIST Cybersecurity Framework 2.0 is useful here because it frames asset visibility, governance, and control consistency as operational requirements rather than optional hygiene.
Teams usually start by asking what would happen if the resource changed unexpectedly, failed, or were removed. If the answer is “we would notice late” or “we would struggle to prove who changed it,” the case for importing it into Infrastructure as Code is strong. If the answer is “it exists only for a short-lived task and carries no lasting dependency,” the stronger choice may be deletion or deliberate isolation rather than formal adoption. In practice, many teams discover unmanaged cloud resources only after a security review, cost issue, or incident has already shown that the asset was never truly temporary.
How the import decision works in practice
Importing a cloud resource is a governance decision as much as a technical one. The team is deciding whether the resource should inherit the same lifecycle controls, review process, and change history as everything else. That usually means comparing the resource’s business value, sensitivity, and volatility against the cost of managing it properly. A database, firewall rule, identity binding, or network exposure that supports production services normally belongs under code, because operational teams need to know who can change it, how changes are reviewed, and whether the current state matches intent.
The opposite case is also important. Some unmanaged resource are not worth formal import because they are redundant, obsolete, or ephemeral. Bringing them into code can create unnecessary maintenance burden and can even preserve bad architecture. The real question is whether the resource has a durable operational purpose. If it does, import supports traceability and repeatability. If it does not, removal is often the cleaner control choice.
Useful decision factors usually include:
- Whether the resource supports a live workload, data store, or trust boundary.
- Whether its configuration could create security exposure if it drifted.
- Whether the team can describe an owner, change process, and rollback path.
- Whether the resource is expected to persist beyond a one-off experiment.
- Whether the current state is acceptable enough to preserve in version control.
Teams also need to distinguish between “managed in cloud console” and “managed as code.” A resource may already be monitored and documented, but still lack the reproducible lifecycle discipline that Infrastructure as Code provides. That gap matters most when the environment is scaled, multi-team, or regulated. For that reason, import is often the right answer for resources that define access, routing, encryption, or shared dependencies, because those are the places where manual drift becomes expensive. This guidance breaks down when the resource is so transient, experimental, or vendor-controlled that the team cannot realistically own its full lifecycle.
Where import is the right answer, and where it creates more harm than value
Tighter governance often increases operational effort, so teams need to balance repeatability against the overhead of managing low-value assets. The best candidates for import are usually resources that are important enough to justify review, but stable enough to survive versioned management. The worst candidates are often “zombie” assets that were created for a task, never formalised, and now survive only because nobody wants to touch them.
There is also a practical boundary between preservation and correction. If an unmanaged resource is already misconfigured, importing it may preserve a bad state unless the team is ready to reconcile it immediately. In that situation, organisations should decide whether to import and normalise, or replace and retire. The choice depends on whether the resource is simple to re-create and whether the team can absorb a controlled change without service disruption.
For cloud environments, the edge cases tend to be shared services, legacy resources, and short-lived deployments. Shared services matter because multiple teams may depend on them but no one may own them cleanly. Legacy resources matter because import can expose undocumented assumptions. Short-lived deployments matter because formalising everything can slow teams down without adding lasting control. The useful rule is not “import everything,” but “import what needs durable control and delete what does not.”
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organisational Context | Unmanaged resources affect control scope, ownership, and governance. |
| ID.AM-01 — Physical Devices and Systems Inventory | The decision depends on whether the asset belongs in an authoritative inventory. | |
| PR.IP-1 — Configuration Management | Importing turns drift-prone resources into versioned, reviewable configuration. | |
| Recommendation — Define ownership and scope so unmanaged assets are brought under a controlled lifecycle. Maintain an accurate inventory and import resources that should be governed. Put durable resources under configuration management to control drift and review changes. | ||
| CIS Controls v8 | 1.1 — Establish and Maintain an Accurate Inventory of Enterprise Assets | The issue is whether the resource should be formally recorded and owned. |
| 4.1 — Establish and Maintain an Inventory of Software Assets | Unmanaged cloud resources often persist because they are not tracked as assets. | |
| 5.1 — Establish and Maintain an Inventory of Accounts | Cloud resources that control access or trust should not remain outside governance. | |
| Recommendation — Inventory resources that matter and retire assets that no longer serve a purpose. Track cloud resources as managed assets when they affect operations or security. Bring access-bearing resources under governance so ownership and revocation stay clear. | ||
Practitioner Guidance
What to prioritise: Prioritise resources that affect access, exposure, availability, or production dependencies. If a resource can change the risk profile of the environment, it deserves a managed lifecycle rather than informal handling.
Decision rule: If the team cannot explain who owns the resource, what breaks if it drifts, and how it will be retired, treat that as a warning sign that import is not the first question. Clarify ownership and necessity before preserving it in code.
What practitioners underestimate: Importing a resource is not a neutral act. It can lock in poor design, obscure obsolete assets, and create a false sense of control if the team does not reconcile the imported state against current standards.
Practitioner takeaway: The right choice is usually the one that improves lifecycle control without preserving unnecessary risk, which means importing durable and consequential resources, while removing transient ones that no longer justify ownership.
Related resources from NHI Mgmt Group
- How do security teams evaluate whether cloud resource import workflows are actually reducing manual effort?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
- How should security teams decide whether legacy PAM still fits cloud-native access needs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
