Who should own governance when infrastructure delivery spans engineering and security?

Why This Matters for Security Teams

When infrastructure delivery spans engineering and security, ownership fails most often at the boundaries: who approves change, who defines the guardrails, and who proves the guardrails actually held. The practical risk is not just duplicated effort. It is drift, where engineering moves faster than policy updates, and security becomes a retrospective reviewer instead of an active control owner. NIST’s Cybersecurity Framework 2.0 remains useful here because it separates governance, risk, and control execution instead of collapsing them into one team’s responsibilities.

NHIMG research shows the same accountability problem in the wild. In the 2026 Infrastructure Identity Survey, 52% of respondents said AI security decision-making power is shifting toward platform and infrastructure teams, which reinforces a broader reality: delivery ownership is moving closer to the code path, while assurance still needs independent control. The mistake many organisations make is treating “shared responsibility” as a governance model instead of a coordination problem. In practice, many security teams encounter unsafe change only after an incident review, rather than through intentional ownership design.

How It Works in Practice

The cleanest operating model is to split ownership by control plane. Engineering owns the code path, build logic, and deployment mechanics. Security and platform teams own the policy boundaries, approval requirements, logging expectations, and exception handling. That means engineering can ship infrastructure as code, but cannot redefine the rules for access, secret handling, or audit evidence without independent review.

This approach works best when governance is expressed as code and attached to delivery pipelines rather than documented as policy alone. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful because infrastructure delivery increasingly depends on non-human identities, short-lived tokens, and automated workflows that need lifecycle ownership, not just periodic review. Security teams should define the minimum standards for:

• who can create or modify infrastructure identity bindings
• what approvals are required for privileged changes
• which logs and audit trails must be retained
• how secrets, tokens, and certificates are issued and rotated
• what triggers a rollback or emergency disablement

Practically, this also means separating design authority from execution authority. Engineering can propose the implementation, but platform or security should own the policy-as-code baseline and the evidence standard. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is relevant because auditors will look for clear control ownership, not just functional collaboration. These controls tend to break down when one team owns the pipeline but another team is expected to validate controls after deployment in fast-moving environments with frequent exceptions.

Common Variations and Edge Cases

Tighter governance often increases delivery overhead, so organisations have to balance speed against assurance. In smaller teams, one group may wear both engineering and security hats, but the ownership model should still be explicit even when people are shared. Current guidance suggests the key is not organizational separation for its own sake, but traceable accountability for each control decision.

There are also cases where platform engineering acts as the control operator while security acts as the control approver. That can work, but only if the approval criteria, escalation path, and evidence requirements are pre-agreed. The NIST Cybersecurity Framework 2.0 supports this split by emphasizing outcomes, not team labels. For NHI-heavy environments, the operational risk rises when infrastructure delivery depends on static credentials and weak lifecycle discipline; NHIMG’s Top 10 NHI Issues highlights why rotation, visibility, and privilege scoping must remain explicit governance responsibilities rather than assumptions. Best practice is evolving, but there is no universal standard that makes shared ownership safe without clear control boundaries.

Related resources from NHI Mgmt Group

• Who should own access governance when IT infrastructure is scaling quickly?
• Who should own just-in-time access governance for infrastructure identities?
• Who should own governance for AI-assisted developer access: IAM, engineering, or platform teams?
• What is the difference between role-based access and API key governance for NHI security?