Who should own remediation when cloud resources are outside IaC?

Why This Matters for Security Teams

Cloud resources that sit outside infrastructure as code create a governance gap, not just a documentation problem. If a database, bucket, service account, or API gateway was created manually, the control owner may not have a clean path to enforce policy, rotate secrets, or prove who approved it. That is why remediation ownership must sit with the team that can either codify the asset or retire it, while security keeps the risk visible until closure. NIST’s Cybersecurity Framework 2.0 reinforces the need for accountable governance over asset risk, and NHIMG has repeatedly shown how unmanaged cloud exposure becomes material, as seen in the Guide to the Secret Sprawl Challenge.

The practical issue is that resources outside IaC often escape standard change control, drift review, and automated policy checks. That makes them harder to inventory and easier to forget, especially when multiple platform teams share responsibility. In practice, many security teams encounter real exposure only after a manual resource has already been used in production for months, rather than through intentional review.

How It Works in Practice

The cleanest ownership model is simple: the team closest to the workload owns remediation, and security owns escalation and tracking. If the resource can be captured in code, the application, platform, or cloud engineering team should create the IaC definition, peer review it, and migrate the live resource under policy enforcement. If the resource is obsolete, that same team should decommission it with security validating that the risk has been removed. This is consistent with 230M AWS environment compromise lessons: unmanaged cloud surface area rarely stays benign.

Operationally, remediation should include four steps:

• Identify the resource owner through account, subscription, project, or service metadata.
• Classify whether the asset should be codified, replaced, or retired.
• Assign a deadline for either IaC onboarding or shutdown.
• Track exceptions as time-bound risk items, not permanent waivers.

Security should not become the repair crew, but it must own the escalation path, evidence, and exception register. That prevents “shadow” cloud assets from becoming invisible just because they were created outside the approved pipeline. Current guidance suggests tying remediation to the team with deploy and delete rights, because only that team can actually close the gap. These controls tend to break down in merged accounts, shared landing zones, and legacy subscriptions where ownership metadata is missing or stale.

Common Variations and Edge Cases

Tighter remediation ownership often increases friction for platform and application teams, requiring organisations to balance speed of recovery against the overhead of tracing old resources to a living owner. That tradeoff is real in fast-moving cloud estates, especially when teams inherit subscriptions, automate across multiple accounts, or operate under merger-driven complexity.

There is no universal standard for this yet, but best practice is evolving toward explicit exception handling for anything outside IaC. If a resource is truly unowned, security and cloud governance should jointly decide whether to isolate it, snapshot it for analysis, or remove it after a defined grace period. The most dangerous failure mode is allowing “temporary” manual resources to persist indefinitely because no one feels empowered to touch them. NHIMG research on the Guide to the Secret Sprawl Challenge and the Snowflake breach shows how quickly unmanaged access and secrets issues compound once exceptions become routine.

For audit purposes, the important distinction is not whether the resource started life outside IaC, but whether a named team is now accountable for either bringing it under code or removing it. If that answer stays ambiguous, the exception is already a control failure.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• Who should own containment when a dependency attack exposes cloud and repository credentials?
• Who should own vendor sprawl remediation in an identity programme?
• Who should own governance when humans, services, and AI agents all access the same resources?