Accountability should sit with the platform, cloud security, and infrastructure owners who define how Terraform code is discovered, governed, and remediated. If unmanaged code exists, the organisation needs an explicit ownership model for onboarding it into policy, CI/CD, and drift control. Shared visibility is essential, but accountability cannot remain ambiguous.
Why This Matters for Security Teams
Terraform governance becomes a control problem the moment code exists in two states at once: managed and unmanaged. The risk is not only drift, but also ambiguity about who approves changes, who remediates violations, and who brings orphaned code into policy. That ambiguity is where compliance gaps, over-permissioned infrastructure, and untracked changes tend to accumulate.
Current guidance aligns with the view that infrastructure-as-code should be treated as an asset lifecycle, not just a repository concern. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs frames lifecycle ownership as the basis for discovery, remediation, and retirement, while the NIST Cybersecurity Framework 2.0 reinforces that governance must connect asset visibility to action. When unmanaged Terraform is left outside that model, teams usually discover it only after a failed audit, an unexpected cloud change, or a production incident has already exposed the gap.
How It Works in Practice
The practical answer is to assign accountability to the function that owns infrastructure policy and enforcement, usually platform engineering or cloud security, with infrastructure owners responsible for the service outcomes their code creates. That ownership needs to cover both the managed estate and the intake process for unmanaged code, because governance only works when every module, workspace, and state file has a path into control.
A workable model usually has three parts:
- Discovery: identify all Terraform repositories, local state, ad hoc scripts, and shadow workspaces.
- Intake: classify unmanaged code by environment, business criticality, and risk before onboarding it into CI/CD and policy checks.
- Control: apply review gates, drift detection, secrets scanning, and approval rules so unmanaged code cannot bypass the same baseline as managed code.
That model maps well to NHI Lifecycle Management Guide because the operational problem is the same: identity or infrastructure objects need an owner, a lifecycle, and a revocation path. It also aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where configuration management, access control, and continuous monitoring intersect. In practice, teams often pair this with policy-as-code and drift remediation so unmanaged code is not merely cataloged but actually brought under the same control plane. These controls tend to break down when multiple business units can deploy independently to shared cloud accounts because ownership becomes fragmented faster than policy enforcement can keep up.
Common Variations and Edge Cases
Tighter Terraform control often increases onboarding and review overhead, requiring organisations to balance speed of delivery against the need for provable governance. That tradeoff becomes more visible in hybrid environments where some code is centrally managed and some is generated by application teams, vendors, or legacy automation.
There is no universal standard for this yet, but current guidance suggests three common patterns. First, centrally managed code should follow strict guardrails with platform or cloud security as the accountable control owner. Second, unmanaged code should be placed on a remediation backlog with explicit service ownership and deadlines. Third, exceptions should be time-bound, documented, and tracked as temporary risk acceptance rather than informal tolerance.
NHIMG’s Top 10 NHI Issues is useful here because unmanaged infrastructure often hides the same structural weaknesses seen in NHI programs: poor visibility, weak rotation discipline, and inconsistent accountability. For audit and reporting expectations, the Ultimate Guide to NHIs — Regulatory and Audit Perspectives helps frame how evidence should be assembled when ownership is split across teams. The model is strongest when the organisation can enforce a single inventory and a single policy baseline; it becomes less reliable when Terraform is embedded in local developer workflows that never touch central review.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Governance must define who owns managed and unmanaged Terraform. |
| NIST SP 800-63 | Identity proofing is less relevant than accountable lifecycle ownership here. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Terraform often provisions NHIs and secrets that need lifecycle governance. |
Assign clear ownership for Terraform intake, policy enforcement, and remediation across the cloud estate.
Related resources from NHI Mgmt Group
- Who is accountable when hybrid identity governance leaves systems outside central policy control?
- Who is accountable when business-critical apps sit outside the identity governance framework?
- Who is accountable when a cloud identity governance platform is used in a regulated environment and a control failure occurs?
- What breaks when IAM resources are changed outside Terraform governance?
