By NHI Mgmt Group Editorial TeamPublished 2025-09-03Domain: Governance & RiskSource: ControlMonkey

TL;DR: Cloud leaders are finding that delivery speed is constrained less by tools than by uneven Infrastructure as Code skills, with manual reviews, drift, and cleanup slowing teams as they scale according to ControlMonkey. The governance issue is not training alone but designing delivery paths where expertise and guardrails, not heroics, determine throughput.


At a glance

What this is: This is an independent analysis of how Infrastructure as Code skills gaps turn delivery speed into a governance problem, with manual reviews and drift creating bottlenecks and risk.

Why it matters: It matters because IAM, NHI, and human access programmes all fail when operational change depends on a small number of experts rather than consistent controls at the point of change.

👉 Read ControlMonkey's analysis of the IaC skills gap and cloud delivery risk


Context

Infrastructure as Code skills gaps become an identity and governance issue when delivery speed depends on a few experts who can safely approve or repair changes. In practice, the organisation is not just short on coding expertise, it is short on a repeatable control model that keeps less experienced contributors from introducing drift, non-compliance, or left-behind infrastructure.

The article argues for shifting from manual oversight to embedded guardrails, automated reviews, and policy enforcement at the point of change. That framing matters for IAM, NHI, and cloud security teams because the same pattern appears whenever teams rely on ad hoc approval to manage access, configuration, or lifecycle changes at scale.


Key questions

Q: How should teams close Infrastructure as Code skills gaps without slowing delivery?

A: Teams should replace manual gatekeeping with policy checks, reusable modules, and automation that enforces standards at the point of change. The goal is not to remove expertise, but to turn senior judgement into repeatable controls that less experienced contributors can use safely. That is how throughput improves without creating more drift or rework.

Q: Why do small Infrastructure as Code skills gaps create outsized risk?

A: Small gaps become outsized risk because cloud change is cumulative. One delayed review, one unsafe exception, or one left-behind resource can ripple across environments, especially when only a few people understand the full stack. The result is slower delivery, more cleanup, and weaker governance over time.

Q: How do organisations know if their IaC controls are actually working?

A: They should look for reduced exception handling, fewer manual escalations, lower drift, and faster safe delivery across the team. If every risky change still depends on a senior engineer, the control model has not scaled. Effective controls are visible in consistent outcomes, not in more review meetings.

Q: What is the difference between training engineers and encoding expertise into delivery?

A: Training improves individual capability, but encoded expertise changes the system. When standards live in modules, validations, and policy enforcement, every contributor benefits from the same guardrails regardless of experience level. That is a stronger control model than hoping people remember best practices under pressure.


Technical breakdown

Why the IaC skills gap becomes a throughput bottleneck

Infrastructure as Code only scales when change can move safely without requiring the same senior engineer to inspect every commit. A skills gap creates a narrow control point where people become the bottleneck, not the pipeline. The technical failure is not simply slower coding. It is inconsistent judgement across contributors, which increases rework, delays reviews, and lets configuration drift accumulate as the environment grows.

Practical implication: map where senior approval is acting as a substitute for policy and automation, then remove that dependency at the change boundary.

Point-of-change governance and blast-radius control

Govern at the point of change means policy checks run before infrastructure changes land, not after the environment has already diverged. Blast-radius estimation, policy engines, and automated review workflows reduce the chance that an unsafe change reaches production or that an inexperienced contributor creates hidden exposure. This is especially relevant where cloud configuration affects identity, secrets, and workload access, because the impact often spreads faster than manual cleanup can follow.

Practical implication: require pre-merge policy evaluation for identity-sensitive and high-impact infrastructure changes.

Encoded expertise and the role of AI in IaC delivery

The strongest IaC programmes turn senior engineering judgement into reusable guardrails inside the delivery path. That can include validated modules, standard templates, and AI-assisted suggestions that are constrained by local standards rather than free-form output. AI can narrow the skills gap, but only when it reinforces existing control logic and does not become a shortcut around it. Without that boundary, speed increases while assurance falls away.

Practical implication: use AI as a standards-aware assistant inside approved workflows, not as a substitute for policy or review.


NHI Mgmt Group analysis

IaC skills gaps are really control consistency gaps. The article describes a delivery model where the same few experts absorb the highest-risk changes while everyone else moves more slowly or less safely. That is not just a staffing issue. It is a sign that access to make change, the ability to judge risk, and the ability to keep resources under control are not yet encoded into the workflow. The practitioner conclusion is that throughput will stay capped until governance is built into the pipeline rather than concentrated in a few people.

Point-of-change policy is the right control model for cloud delivery. Manual review, delayed script checks, and after-the-fact cleanup do not scale when infrastructure changes happen continuously. The article’s core insight is that the environment is easiest to govern at the moment change is proposed, before drift and hidden dependencies multiply. For cloud teams, that aligns with NIST Cybersecurity Framework thinking and with NHI-style governance patterns that favour preventive control over retrospective cleanup. The practitioner conclusion is to move risk decisions as far left as possible.

Encoded expertise is the named concept that matters here. Senior judgement is valuable, but an organisation cannot depend on individual memory to enforce safe cloud delivery forever. The real objective is to convert tacit expertise into repeatable module standards, policy rules, and constrained AI assistance that lower variance across engineers. That is how teams reduce the gap between the best and the rest without pretending the skill gap has disappeared. The practitioner conclusion is to make expertise portable, not personal.

AI can widen or narrow the skills gap depending on how it is governed. The article treats GenAI as a force multiplier, but the governance question is whether it accelerates compliant delivery or accelerates bad decisions. In cloud programmes, AI-generated infrastructure suggestions are only trustworthy when they inherit the organisation’s standards, review logic, and drift controls. The practitioner conclusion is to govern AI-assisted delivery as part of the same control plane as IaC, not as a separate productivity experiment.

Cloud delivery maturity now depends on eliminating hidden exceptions. Left-behind resources, custom scripts, and one-off review processes all create invisible complexity that eventually shows up as cost, compliance, or security debt. This is where infrastructure governance meets identity governance: if a resource or permission is not continuously managed, it will eventually become an exception. The practitioner conclusion is to treat unmanaged exceptions as a programme defect, not an operational inconvenience.

From our research:

  • 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
  • 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years.
  • That forward shift makes the Ultimate Guide to NHIs , Standards a useful companion for teams trying to align policy, identity, and workload control.

What this signals

Encoded expertise: the real governance advantage is not more training, but converting senior judgement into reusable controls that scale across the team. When that conversion fails, throughput and assurance diverge, and the organisation starts paying for exceptions in every release cycle.

With 70% of organisations already granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the delivery challenge is shifting from speed to supervised autonomy. That means cloud programmes should prepare for AI-assisted change as a governance problem, not a productivity feature.

Teams that still rely on senior engineers as the main safeguard should expect review backlogs, hidden drift, and brittle ownership patterns. The practical signal to watch is whether policy enforcement is embedded in the workflow or still depends on a handful of people remembering the right thing at the right time.


For practitioners

  • Move policy checks to the point of change Require pre-merge evaluation for high-impact infrastructure changes so risky configurations are blocked before production drift begins.
  • Standardise reusable modules and templates Replace ad hoc infrastructure patterns with approved modules that encode security, compliance, and naming standards into the delivery path.
  • Reduce review dependence on senior engineers Identify change types that still require expert judgement and convert them into policy rules, validations, or automated checks.
  • Treat AI suggestions as constrained inputs Allow AI to assist with infrastructure authoring only inside approved workflows where the output is checked against organisational standards.
  • Eliminate left-behind resources as a governance defect Track orphaned or unmanaged infrastructure items as a control failure because they usually indicate gaps in lifecycle management and ownership.

Key takeaways

  • Infrastructure as Code skills gaps become governance bottlenecks when safe change depends on a few experts rather than encoded controls.
  • Manual review and after-the-fact cleanup do not scale as cloud environments grow, so drift and left-behind resources will keep accumulating unless policy moves earlier in the workflow.
  • The most durable fix is to turn senior expertise into reusable guardrails, then use AI only inside those guardrails.

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, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Access and change control need to stay consistent as more contributors touch IaC.
NIST CSF 2.0PR.IP-1Policies and procedures must be embedded in delivery workflows, not kept as tribal knowledge.
NIST Zero Trust (SP 800-207)AC-2Point-of-change governance aligns with least-privilege change authorization in cloud delivery.

Map IaC change permissions to PR.AC-4 and automate approval logic for sensitive infrastructure paths.


Key terms

  • Infrastructure as Code skills gap: The difference between the complexity of infrastructure work and the ability of a team to perform that work safely and consistently. In practice, it shows up as slower reviews, uneven change quality, and over-reliance on a few experts to prevent mistakes.
  • Point-of-change governance: A control model that evaluates and blocks risky infrastructure or identity changes before they are applied. It reduces the need for after-the-fact cleanup by enforcing policy at the moment a change is proposed, when remediation is still cheapest and the blast radius is smallest.
  • Encoded expertise: The process of turning senior practitioners' judgement into reusable modules, policy rules, and automated checks. Instead of living in one person's head, the standards become part of the delivery system, allowing less experienced engineers to work safely within clear boundaries.
  • Blast-radius estimation: A method for estimating how far a change could spread if it fails or is misconfigured. In cloud and identity programmes, it helps teams decide which changes need tighter review because the impact could affect many systems, permissions, or dependent workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by ControlMonkey: the IaC skills gap and its effect on cloud delivery speed and risk. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-09-03.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org