Who is accountable when unmanaged resources or Terraform drift creates misconfiguration risk across AWS accounts?

Why This Matters for Security Teams

Misconfiguration risk across AWS accounts is not just a hygiene issue. When unmanaged resources or terraform drift leave permissions, logging, or network controls inconsistent, the result is often an identity and access problem as much as a cloud configuration problem. That makes accountability difficult unless platform owners, cloud security, and application teams share an explicit operating model. NIST Cybersecurity Framework 2.0 emphasises governance and ownership as the basis for control effectiveness, not a substitute for it.

In practice, the failure mode is predictable: teams assume the central cloud function will catch drift, while the central team assumes account owners will remediate it. That gap is where unmanaged resources accumulate, especially in multi-account estates with different delivery cadences. The NHI breach patterns documented in The 2024 ESG Report: Managing Non-Human Identities show why visibility alone is not enough when credentials, roles, and infrastructure state are all drifting at once.

Cloud estates also fail when ownership is inferred from a dashboard rather than assigned through change control. Security teams need a named decision-maker for each account, each Terraform module, and each exception path. In practice, many security teams encounter account-level misconfiguration only after access has already been widened or logging has already been disabled, rather than through intentional review.

How It Works in Practice

The practical answer is to map accountability to the people who can actually change the environment. Platform teams usually own the Terraform workflow, cloud security owns guardrails and monitoring, and application owners own the workload-specific exceptions and business risk acceptance. Central cloud governance should define the control plane, but remediation must remain with the account or service owner. That is consistent with control thinking in NIST SP 800-53 Rev. 5 Security and Privacy Controls, which treats accountability, configuration management, and auditability as operational controls, not abstract policy statements.

For Terraform drift, the useful pattern is to separate detection from remediation:

• Detect drift continuously across all AWS accounts, including unmanaged resources created outside code.
• Assign each account to a named owner with a runbook for triage, approval, and rollback.
• Use policy-as-code to block high-risk changes and surface exceptions in review before deployment.
• Reconcile state files, cloud inventory, and tag ownership so that orphaned assets are not left ambiguous.
• Escalate unresolved drift through a time-bound workflow tied to change control, not email.

NHIMG guidance on lifecycle control in the NHI Lifecycle Management Guide applies here because unmanaged cloud resources behave like unmanaged identities: if they are not inventoried, attributed, and retired, they become persistent exposure points. The same logic underpins the Top 10 NHI Issues, where ownership gaps and stale artefacts repeatedly turn into access risk. These controls tend to break down when account creation is self-service without mandatory ownership tags and enforced module standards, because no team can prove who is responsible for fixing drift.

Common Variations and Edge Cases

Tighter ownership controls often increase operational overhead, requiring organisations to balance fast provisioning against clear accountability. That tradeoff is real in shared service accounts, ephemeral sandbox environments, and merger-driven multi-account estates, where the business wants speed but the security model needs traceability. Current guidance suggests that temporary accounts can be exempted only if they have an explicit expiry, a sponsor, and automated teardown.

There is no universal standard for this yet, but best practice is evolving toward account-level ownership plus workload-level exception ownership. Shared dashboards help, yet they do not settle disputes about who approves risk. The cleanest operating model is to treat unmanaged resources as an exception to be owned, not as a discovery artifact to be admired. Where Terraform state is stale, or teams deploy directly through the console, ownership should revert to the team that last changed the resource until a formal handoff is documented.

For broader governance context, Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful because auditors will ask the same question in a different form: who accepted the risk, when, and under what control? In environments with multiple CI/CD pipelines and delegated admin accounts, accountability often fractures fastest where there is no single source of truth for ownership, change approval, and rollback authority.

Related resources from NHI Mgmt Group

• Who is accountable when federated access is granted across AWS accounts and identity providers?
• Who should be accountable when employee impersonation creates access risk across HR, IT, and security?
• How should teams approach importing unmanaged cloud resources into Terraform without creating drift or downtime?
• How should security teams manage AWS CodePipeline resources in Terraform without creating configuration drift?