Why do manually created infrastructure stacks create governance risk in cloud delivery pipelines?

Manually created stacks create blind spots whenever new code paths appear faster than operations can register them. That gap can leave Terraform changes outside standard review, policy enforcement, and testing. In practice, the risk is misconfiguration, inconsistent compliance, and uncontrolled drift between what developers build and what the organisation believes is governed.

Why This Matters for Security Teams

Manually created infrastructure stacks are a governance problem because they bypass the controls that make cloud delivery auditable: policy checks, standard templates, peer review, and change traceability. When a stack is assembled outside the normal pipeline, security teams lose confidence that the resulting environment matches approved baselines. That is where drift, shadow infrastructure, and inconsistent tagging or encryption settings start to accumulate.

This is especially risky in cloud delivery because infrastructure changes are often frequent, automated, and interconnected. A single manually built stack can introduce unmanaged secrets, oversized permissions, or unsupported network paths that never pass through the same gates as code-driven changes. NHI Management Group has documented how identity and secret sprawl compound this problem in cloud operations, including the broader Guide to the Secret Sprawl Challenge and the Top 10 NHI Issues.

Current guidance from the NIST Cybersecurity Framework 2.0 and NIST control baselines points toward repeatable, documented, and monitored change paths. In practice, many security teams encounter governance failures only after a manually created stack has already gone live and the audit trail has been reconstructed after the fact, rather than through intentional design.

How It Works in Practice

The core issue is not simply that a stack was created by hand. The problem is that manual creation usually breaks the chain between intent, implementation, and enforcement. In a governed pipeline, infrastructure-as-code can be scanned, approved, and versioned before deployment. A manually created stack may still function technically, but it often sits outside those controls, which means the organisation cannot prove who approved it, what policies applied, or whether the final state matches the intended design.

That gap matters because cloud governance depends on repeatable identity and policy decisions. A manual stack may create new service accounts, IAM roles, security groups, storage policies, or secrets without triggering the same checks used in standard delivery. That can leave privileged access, exposed endpoints, or unencrypted resources invisible to normal review. The risk is not only misconfiguration. It is also uncontrolled divergence from the control plane that the organisation believes is governing the environment.

Security teams typically reduce this risk by enforcing the same baseline across every path to production:

• Require infrastructure-as-code for all repeatable builds and treat manual creation as an exception process.
• Run policy-as-code checks before deployment, not after, so denied configurations never reach the cloud provider.
• Compare deployed state against approved templates to detect drift quickly.
• Log and review all privileged actions that create or mutate stacks outside CI/CD.

That operational model aligns with NIST SP 800-53 control expectations for configuration management and continuous monitoring, and it mirrors the lifecycle discipline discussed in NHIMG’s Ultimate Guide to NHIs. These controls tend to break down when platform teams allow console-based emergency changes to become a normal deployment path because the exceptions outgrow the original approval model.

Common Variations and Edge Cases

Tighter change control often increases delivery overhead, requiring organisations to balance speed against governance assurance. That tradeoff is real in incident response, rapid prototyping, and lab environments where fully formalised pipelines can slow urgent work. Best practice is evolving here: there is no universal standard for when a manual stack should be prohibited outright versus allowed under a tightly logged exception.

The edge case is not every hand-built environment. It is the hand-built environment that later becomes shared, persistent, or connected to production data. In those cases, the governance risk escalates because a temporary shortcut turns into a long-lived control gap. This is where manual creation intersects with broader NHI and secret exposure patterns described in NHIMG research, including the CI/CD pipeline exploitation case study and the Reviewdog GitHub Action supply chain attack.

The practical decision point is whether the organisation can still answer five questions: who created the stack, what standard it was meant to meet, what access it introduced, how drift is detected, and when it will be retired or rebuilt through the governed pipeline. If those answers are unclear, the stack is already a governance liability, even if it appears secure today.

Related resources from NHI Mgmt Group

• How should security teams add governance to existing Infrastructure as Code pipelines without disrupting delivery workflows?
• Why do Infrastructure as Code pipelines need a separate governance layer in cloud environments?
• Why does standing access create governance problems for cloud and infrastructure teams?
• Why do standing privileges in cloud infrastructure create outsized risk for engineering teams?