Security teams should insert policy checks after the plan phase and before changes are applied, then retain the existing CI/CD workflow. This approach preserves developer velocity while adding cost, security, compliance, and audit controls. The key is to centralise review, keep evidence from every change, and avoid forcing teams to migrate pipelines just to improve governance.
Why Governance Belongs Between Plan and Apply in Infrastructure as Code
Adding governance to Infrastructure as Code works best when it sits on the same path the change already follows, rather than creating a second process beside it. For most teams, that means checking the plan output before apply so security, compliance, and cost controls can influence what ships without breaking the delivery model. NIST Cybersecurity Framework 2.0 is useful here because it frames governance as part of normal security management, not an exception to delivery. In practice, many security teams discover the pain only after they have asked engineers to bypass the pipeline to get approvals.
How Governance Fits Into an Existing Delivery Pipeline
The main design choice is where to introduce control without turning Infrastructure as Code into a manual approval exercise. The safest pattern is to treat the plan phase as the point where governance can inspect proposed state, then allow apply only when the result satisfies policy. That preserves the original workflow, keeps the source of truth in code, and avoids splitting technical delivery from control evidence.
Well-run teams usually separate this into three layers: authoring, policy evaluation, and execution. Authoring remains with the infrastructure owner or platform team. Policy evaluation is centralised, so the same rules are used across projects instead of being reimplemented in each repository. Execution remains automated, but gated by the policy result. This matters because governance is not only about blocking bad changes. It is also about making sure the control decision is repeatable, reviewable, and tied to the exact change request.
- Inspect the planned delta, not the live environment alone, so reviewers can see what the pipeline intends to change.
- Check for conditions such as public exposure, overly broad permissions, unsafe encryption settings, and unsupported regions or services.
- Capture evidence from the plan and policy decision so audit teams can reconstruct why a change was approved.
- Keep the original CI/CD steps intact wherever possible, because forcing a new workflow often pushes teams to route around governance.
Security teams should also be clear about what governance is not trying to do. It is not replacing engineering judgment or turning every deployment into a committee review. It is adding a consistent control point that can detect policy violations before they become deployed infrastructure. Where the pipeline also manages secrets, identity bindings, or privileged automation, the same design helps reduce hidden access paths because the review happens before the change reaches production. This guidance breaks down when policy logic is scattered across tools and no single decision point can produce a trustworthy approval record.
Where IaC Governance Gets Harder at Scale
Tighter governance often increases pipeline complexity, so organisations must balance stronger control against faster delivery and lower operational friction. The tradeoff becomes most visible when many teams share the same templates or when a single platform team owns policy but not the application context.
One common edge case is exception handling. Mature teams usually need a formal path for justified exceptions, but ad hoc waivers create inconsistent risk acceptance and weaken the value of the control. Another is drift between the plan and the actual apply window. If too much time passes, the approved state may no longer match the environment by the time the change runs. In that case, governance should treat the plan as stale and require regeneration rather than relying on an old approval.
There is also a practical distinction between policy that is preventive and policy that is advisory. Some controls should block the pipeline, while others should warn and report. Not every finding deserves the same treatment, and the industry does not fully agree on a single threshold model. The better practice is to reserve hard blocking for changes that create material exposure, then use softer controls for informational or low-impact issues. For teams operating across many repositories, standardisation matters more than perfection: a consistent control that is slightly less granular is often more useful than a sophisticated rule set that developers ignore. When teams try to enforce governance retroactively on every existing pipeline without staging or clear ownership, the result is usually slower delivery and weaker compliance, not better security.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | IaC governance must fit existing delivery and risk context. |
| GV.RM-01 — Risk Management Strategy | Policy checks formalise risk decisions before infrastructure changes apply. | |
| PR.AC-4 — Access Permissions and Authorizations | IaC policy often governs privileged infrastructure actions and permissions. | |
| Recommendation — Align pipeline policy gates to organisational risk tolerance and delivery context. Define approval criteria that reflect acceptable infrastructure change risk. Enforce least-privilege controls on automation identities and deployment actions. | ||
| CIS Controls v8 | 4.1 — Establish and Maintain an Inventory of Enterprise Assets | Governance depends on knowing which infrastructure assets are being changed. |
| 5.1 — Establish and Maintain an Inventory of Software Assets | IaC pipelines rely on controlled build and deployment tooling assets. | |
| 6.3 — Require MFA for Externally-Exposed Applications | Pipeline governance often protects access paths that would expose deployments. | |
| Recommendation — Keep the infrastructure inventory aligned to the resources your pipelines can create. Track the pipeline tooling and modules that can alter production infrastructure. Protect administrative and deployment access paths with strong authentication. | ||
Practitioner Guidance
What to prioritise: Establish one authoritative policy decision point and make it consume the plan artifact directly. That gives teams a governance control that is reviewable without changing how developers commit, test, or promote code.
What to verify: Confirm that the policy engine evaluates the exact planned change, that approvals are traceable to the same build or run ID, and that evidence is retained in a form audit and operations can both use. If the control cannot prove which change it approved, it is not mature enough for real governance.
Common mistake: Requiring teams to rebuild their pipelines around the governance tool instead of inserting governance into the workflow they already trust. That usually creates shadow processes, manual exceptions, and weaker adoption.
Practitioner takeaway: The best IaC governance is the kind engineers barely feel until a risky change is stopped, because durable control depends more on fitting the delivery path than on adding more review steps.
Related resources from NHI Mgmt Group
- How should security teams prevent source code leaks without disrupting engineering workflows?
- How should security teams add application security testing into Azure DevOps CI/CD pipelines without slowing delivery?
- How should security teams test AI-generated code in fast-moving delivery pipelines without drowning in false positives?
- How should security teams bring hidden privileged identities into PAM workflows without disrupting existing controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
