Who is accountable for Terraform governance when some code is managed and some code is still outside control?

Who owns Terraform governance when control is split between managed and unmanaged code?

When Terraform spans both governed and ungoverned estates, accountability must be assigned to the teams that control the platform guardrails, not left with the individual authors of each file. That usually means platform engineering, cloud security, and infrastructure owners share the duty to define discovery, approval paths, exception handling, and remediation. The governance problem is not just code quality. It is whether the organisation can prove what exists, who approved it, and how unmanaged infrastructure definitions are brought under control.

This is where governance becomes an operational control issue rather than a documentation exercise. If some code is outside policy, the risk is that ownership fragments and no one is forced to reconcile reality with the intended state. NIST Cybersecurity Framework 2.0 is useful here because its governance and risk ownership lens reinforces that accountability must be explicit, not implied. In practice, many teams discover this only after unmanaged Terraform has already created drift, duplicated resources, or untracked access paths.

How governance works when part of the estate is still outside policy

Terraform governance only works when the organisation treats managed and unmanaged code as one control domain. The managed portion can be checked through repositories, CI/CD, policy-as-code, and change approval. The unmanaged portion requires a different discipline: discovery, intake, classification, and a decision on whether it is adopted, retired, or temporarily exempted. Without that split, teams often assume the existence of a pipeline means governance exists everywhere, when in fact it only covers what has been onboarded.

Accountability should follow the mechanism that can actually change the state of the environment. Platform teams typically own the delivery path, cloud security owns the control expectations, and infrastructure owners own remediation prioritisation. That division matters because no single control objective is met if unmanaged code remains invisible. Governance should therefore answer three questions: what Terraform exists, which parts are under policy, and who is responsible for closing the gap.

• Discovery tells you what code and state exist outside the normal workflow.
• Ownership tells you who must decide whether that code is brought under control.
• Remediation tells you how quickly unmanaged definitions are reviewed, migrated, or retired.

If the organisation cannot tie those three steps to named owners, then Terraform governance is only partial, even if managed repositories are mature. The model breaks down when unmanaged code is treated as someone else’s problem or when exceptions are left open indefinitely.

Where shared responsibility breaks down in mixed-control Terraform estates

Tighter Terraform governance often increases operational overhead, requiring organisations to balance control coverage against delivery speed. That tradeoff is most visible when teams must support both legacy, unmanaged definitions and new policy-enforced workflows at the same time.

One common edge case is inherited infrastructure code held in shared drives, tickets, or personal repos rather than a formal source control path. Another is shadow automation, where code is technically present but never integrated into the organisation’s review and drift processes. Guidance here is less consensus-driven than it is practical: the industry generally agrees that unmanaged infrastructure should not remain permanently exempt, but there is no universal rule for how quickly every legacy asset must be migrated. The right answer depends on change velocity, blast radius, and audit pressure.

Another common failure is split accountability between “who wrote it” and “who runs it.” For governance, the operational owner matters more than the original author, because the owner is the party able to enforce policy and respond to drift. External guidance from the NIST Cybersecurity Framework 2.0 is relevant here because it reinforces accountability for risk treatment, while control catalogues such as NIST SP 800-53 Rev. 5 are useful where change control and monitoring expectations must be mapped to specific technical obligations.

The model becomes weakest when unmanaged code is large enough to materially affect posture but small enough to be ignored. That is usually where governance gaps persist longest.

Practitioner Guidance

What to prioritise: Assign one named operational owner for the unmanaged Terraform backlog, even if delivery responsibility remains distributed. Without that owner, discovery findings tend to stall between security, platform, and application teams.

What to verify: Confirm that the owner can show three things: an inventory of unmanaged code, a decision path for each item, and a dated remediation or exception record. If any of those are missing, governance is not yet defensible.

Decision rule: If Terraform materially changes cloud resources, treat unmanaged code as a governance gap, not a tooling nuisance. If the code can alter access, networking, or identity-linked infrastructure, escalate it as a control issue rather than a backlog item.

Practitioner takeaway: Mixed-control Terraform estates only become governable when accountability shifts from “who created the code” to “who can force it into the control model and prove the gap is closing.”

Related resources from NHI Mgmt Group

• Who is accountable when hybrid identity governance leaves systems outside central policy control?
• Who is accountable when infrastructure as code onboarding leaves unmanaged code paths outside governance?
• What makes agentic AI an NHI governance issue?
• What is the difference between attack surface management and NHI governance?