Who should approve infrastructure changes when different teams own different stacks?

Why This Matters for Security Teams

When different teams own different stacks, approval is not a clerical step. It is the control that determines whether the people who understand the blast radius, dependencies, and rollback path can stop a risky change before it reaches production. Centralised approval queues often create blind spots, especially when infrastructure spans cloud, identity, CI/CD, and network layers. That is why operational ownership should drive approval, aligned to least privilege and accountability in NIST SP 800-53 Rev 5 Security and Privacy Controls.

NHIMG research shows why this matters: the Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, and 80% of identity breaches involve compromised non-human identities. If change approval is detached from stack ownership, those privileged identities can be used to push configuration drift, widen access, or disable safeguards without the right reviewers seeing it. In practice, many security teams discover approval gaps only after an over-privileged change has already altered the control plane, rather than through intentional change governance.

How It Works in Practice

The practical model is simple: approval should follow the owner of the affected control plane, not a generic seniority chain. A database change should be approved by the DBA or data platform owner. A Kubernetes or cloud networking change should be reviewed by the SRE or platform team that operates that layer. Security should approve when the change affects policy, secrets, identity controls, or compensating safeguards. This is consistent with current guidance on control ownership and change accountability in NIST controls.

Strong change governance usually includes:

• Named ownership for each stack, with an explicit backup approver for absence coverage.
• Segregation of duties so the person requesting a change is not the sole approver for the same control plane.
• Evidence captured in the ticket, pull request, or deployment record showing who approved what and why.
• Escalation paths for cross-stack changes, where more than one team must approve because the blast radius crosses boundaries.

For NHI-heavy environments, the approval decision should also consider whether the change touches service accounts, API keys, workload identities, or vault policies. The Ultimate Guide to NHIs highlights how often secrets and privileges drift, which means approval is not just about infrastructure uptime but also about identity exposure. A good approval model asks: who can actually evaluate the operational risk, and who can revoke or roll back safely if the change misbehaves? These controls tend to break down in multi-cloud environments with shared platform teams and ambiguous service ownership because approval responsibility becomes diffused across too many queues.

Common Variations and Edge Cases

Tighter approval routing often increases process overhead, requiring organisations to balance speed against assurance, especially for teams that ship frequently. That tradeoff is real, but the answer is not to default everything to central review. Best practice is evolving toward tiered approval: low-risk changes can use pre-approved patterns or policy-as-code guardrails, while high-risk changes still require human review from the owning team and, when needed, security.

There is no universal standard for this yet, but a few edge cases matter. Shared platforms often need joint approval when one team owns the runtime and another owns the policy layer. Emergency changes may allow a single designated approver, but only with post-change review and full audit trail. Vendor-managed stacks complicate matters further because internal teams may own the risk even when the vendor operates the tooling. In those cases, approval should sit with the internal control owner, not with procurement or a generic operations queue. The strongest pattern is the one that preserves accountability without creating a bottleneck that encourages shadow changes.

Related resources from NHI Mgmt Group

• Why do infrastructure and security teams need a different model for governing access as AI and automation expand?
• How should financial services teams enforce infrastructure governance across Terraform changes in regulated cloud environments?
• How should security teams govern infrastructure changes across a large GCP organisation without relying on manual project-by-project setup?
• How should security teams prevent duplicate Terraform resource definitions from breaking infrastructure changes at scale?