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

Ownership should sit with the platform, DevOps, or cloud security team that governs infrastructure standards, with clear input from application owners for business impact. The right operating model assigns a named owner, a remediation path, and an approval process for imports. That keeps cleanup consistent and prevents unmanaged assets from lingering.

Why This Matters for Security Teams

Unmanaged AWS resources outside Terraform are not just a housekeeping problem. They create an ownership gap where nobody is clearly accountable for patching, tagging, access review, cost control, or eventual removal. That gap matters because cloud drift often becomes security drift: orphaned instances, security groups, IAM roles, and storage surfaces can outlive the change that created them.

For security teams, the remediation question is really an operating model question. The team that owns infrastructure standards should own the remediation workflow, while application owners provide business context for imports, dependencies, and outage risk. That split aligns with the lifecycle thinking in NHI Lifecycle Management Guide and the broader risk themes in Ultimate Guide to NHIs – Key Challenges and Risks. It also fits NIST Cybersecurity Framework 2.0 by linking inventory, governance, and response to a named control owner.

In practice, many security teams discover unmanaged resources only after a billing spike, incident review, or failed audit has already exposed the drift.

How It Works in Practice

The cleanest model is to assign remediation authority to the platform, DevOps, or cloud security function that sets infrastructure standards and controls the Terraform baseline. That team should own the intake queue, risk triage, and the import or decommission decision path. Application owners should not be asked to resolve the drift alone, but they should validate whether a resource is still needed, whether it supports production traffic, and whether a Terraform import would create configuration risk.

That operating model usually works best when it includes four steps: detect the unmanaged resource, identify a business owner, decide whether the asset should be imported, and then either codify it in Terraform or retire it. The value is consistency. Security can enforce guardrails, infra teams can maintain source of truth, and app teams can approve business-impact exceptions. This matches the lifecycle and remediation emphasis in Top 10 NHI Issues and the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls.

• Platform or DevOps owns the remediation queue and Terraform state reconciliation.
• Cloud security defines policy for detection, tagging, and exception handling.
• Application owners confirm business need, service criticality, and dependency impact.
• Approved imports are recorded, reviewed, and tracked until the resource is fully governed.

A useful rule is that ownership should follow the team that can safely change the infrastructure definition, while approval should follow the team that understands the workload impact. These controls tend to break down when there is no accurate asset inventory, because teams cannot distinguish deliberate exceptions from forgotten cloud drift.

Common Variations and Edge Cases

Tighter remediation control often increases operational overhead, requiring organisations to balance speed against change safety. Not every unmanaged AWS resource should be handled the same way. A disposable test instance, a legacy production database, and a public S3 bucket all deserve different remediation urgency, approval depth, and evidence capture. Current guidance suggests that the more sensitive or internet-exposed the asset is, the less tolerance there should be for informal ownership.

There is no universal standard for this yet, but a few edge cases are common. If the resource belongs to a decommissioned application, the platform team should usually drive deletion after confirming no hidden dependencies remain. If the resource was created manually during an incident, it should be treated as temporary until imported or removed. If the workload is owned by a vendor or central shared-services team, then remediation should be coordinated through the same governing function, with documented handoff and accountability. The Guide to the Secret Sprawl Challenge is a useful reminder that unmanaged infrastructure and unmanaged secrets often appear together, which is why remediation should include both ownership and credential review.

In short, the best model is not “security fixes it” or “the app team fixes it” alone. It is a governed workflow where the infrastructure owner executes remediation, the application owner validates impact, and exceptions are time-bound and auditable.

Related resources from NHI Mgmt Group

• What breaks when AWS CodePipeline resources are left outside Terraform governance?
• How should security teams manage AWS IAM resources in Terraform without disrupting live access?
• What breaks when IAM resources are changed outside Terraform governance?
• How should teams approach importing unmanaged cloud resources into Terraform without creating drift or downtime?