Who should own the remediation of unmanaged AWS resources discovered outside Terraform?

Why Ownership Matters When Cloud Drift Appears Outside Terraform

Unmanaged AWS resources are not just an aesthetic problem in infrastructure code. They create governance gaps, weaken change control, and make it harder to prove which assets are approved, monitored, or eligible for remediation. The core question is not who first spotted the drift, but which team can enforce standards, judge whether the resource should be imported, rebuilt, or removed, and coordinate the business impact of that decision. The most direct external reference for this governance problem is the NIST Cybersecurity Framework 2.0. In practice, many security teams discover the ownership gap only after stale cloud assets have already accumulated across multiple accounts and no one can confidently claim responsibility for cleanup.

How Remediation Ownership Should Work in Practice

The practical owner of remediation is usually the platform, DevOps, or cloud security function that controls infrastructure standards and change enforcement. That team should not act in isolation, because a resource that looks orphaned from an IaC perspective may still support an application workflow, integration, or temporary business need. The cleaner operating model is a named owner for the remediation workflow, a separate business owner for impact decisions, and a documented path for imports when a resource is valid but unmanaged.

This matters because Terraform drift often mixes three different problems: missing code, shadow provisioning, and deliberate exceptions that were never formalised. The remediation owner needs enough authority to decide whether the resource should be captured into code, replaced with compliant infrastructure, or decommissioned. Application owners should supply context on dependency and service impact, but they should not be expected to arbitrate infrastructure standards on their own. Where the organisation already uses control baselines, the remediation team should align cleanup decisions to those standards rather than treating each resource as a one-off judgment. That is why a control-oriented view is useful, and the intent of NIST SP 800-53 Rev 5 Security and Privacy Controls fits the ownership model better than ad hoc ticket routing.

• Platform or cloud security owns the remediation process and approval path.
• Application owners confirm whether the resource is still needed and what depends on it.
• Terraform or import decisions follow a standard rule set, not informal exception handling.
• Decommissioning is handled by the team with the ability to verify downstream impact.

Where this model breaks down is when cleanup is assigned to the team that merely reported the drift, because detection is not the same thing as authoritative ownership.

Boundary Cases That Change the Ownership Decision

Tighter remediation control often improves consistency, but it also adds coordination overhead, so teams have to balance speed against the risk of deleting something still in use.

Shared services and platform-managed resources are the easiest case: the infrastructure team should own cleanup because it also owns the standards that define whether the resource belongs. Business-unit resources are less straightforward. If a team has been granted autonomy to create cloud assets, it may retain operational ownership for the resource, while platform security still owns the remediation policy and enforcement mechanism. That distinction is important and often misunderstood.

Imported resources add another edge case. If the asset is valid, the remediation path should usually be to bring it under Terraform management rather than remove it. If the asset is unsupported, duplicate, or violates policy, ownership should shift toward decommissioning with a documented approval trail. Teams sometimes treat every unmanaged resource as a security defect that must be deleted, but that approach can create avoidable outages when the real issue is missing inventory, not malicious provisioning. The better practice is to classify the resource first, then assign the owner who can actually complete the corrective action. Where governance is mature, that means the platform team leads, the application owner validates business necessity, and exceptions remain time-bound rather than open-ended.

Practitioner Guidance

What to prioritise: Assign one remediation owner who can close the loop on import, rebuild, or removal, then make application owners accountable for impact validation rather than execution. The first decision should be whether the resource is unmanaged but legitimate, or unmanaged because it should not exist at all.

What to verify: Confirm who has authority over the AWS account, the Terraform repository, and the decommission path before opening a remediation ticket. If those three rights sit in different teams, the workflow must be explicit or the asset will linger.

Practitioner takeaway: Ownership should follow the team that can enforce infrastructure standards and complete the corrective action, not the team that merely detected the drift.

Related resources from NHI Mgmt Group

• Who should own remediation when cloud resources are outside IaC?
• What breaks when AWS CodePipeline resources are left outside Terraform governance?
• Who is accountable when unmanaged resources or Terraform drift creates misconfiguration risk across AWS accounts?
• How should teams handle unmanaged cloud resources that fall outside Terraform coverage?