What breaks when infrastructure is only partially managed as code?

Why Partial IaC Coverage Fractures Cloud Control

When infrastructure is only partly managed as code, the problem is not just slower delivery. The environment starts to split into two operating models: one with reviewable, repeatable change control and one that depends on manual action, local knowledge, and exceptions. That split makes drift harder to detect, weakens accountability, and creates uneven control enforcement across the same cloud estate. For a broad governance view, the NIST Cybersecurity Framework 2.0 is useful because it frames governance and control consistency as an operational security issue, not just an engineering preference.

In practice, many security teams discover the gap only after an incident, when unmanaged components or one-off changes turn routine recovery into a forensic reconstruction exercise.

Where Managed and Unmanaged Assets Start to Diverge

Partial infrastructure-as-code coverage breaks the assumptions that make modern cloud operations reliable. Managed resources benefit from version control, peer review, and repeatability. Unmanaged resources often rely on console changes, ad hoc scripts, or inherited defaults. Over time, that creates differences in tagging, access policy, network segmentation, encryption settings, and approval evidence, even when the assets look similar on paper.

The practical failure is usually not a single broken deployment. It is the accumulation of small inconsistencies that become operationally significant:

• Change records no longer describe the full environment.
• Rollback becomes uneven because some components can be redeployed while others must be repaired manually.
• Approval paths differ, so auditors and responders must verify multiple sources of truth.
• Dependency mapping becomes incomplete when unmanaged assets are attached to managed services without being versioned themselves.

That matters most when teams assume the code repository is the system of record. It is only the system of record for what is actually expressed in code. Anything outside that boundary can drift, retain stale privilege, or bypass standards that the team believes are universal. Where control evidence is important, the documentation discipline described in the NIST view of cybersecurity governance is more useful than treating IaC as a tooling choice alone.

The guidance breaks down when the environment includes many emergency exceptions, long-lived console-managed services, or shared platform layers that no single team fully owns.

Mixed Delivery Models Need a Deliberate Boundary, Not an Accidental One

Tighter IaC coverage often increases short-term migration overhead, so organisations have to balance standardisation against the cost of refactoring stable but unmanaged infrastructure.

Partial coverage can still work, but only if the boundary between managed and unmanaged components is explicit. The most common mistake is to treat “mostly codified” as equivalent to controlled. It is not. A cloud estate with a few manual exceptions can be manageable; a cloud estate with undocumented exceptions hidden inside critical paths becomes difficult to validate after every change.

There is also a trade-off between speed and traceability. Manual changes may appear faster during an outage, but they often create hidden debt that slows later remediation. That is especially true where security controls depend on inherited configuration, such as logging, security groups, IAM policies, or backup settings. If those controls are not expressed consistently, the team may have to inspect each asset individually instead of proving state from the pipeline.

NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it reinforces the need for control consistency, evidence, and ongoing monitoring across assets, not just within the automated portion of the estate.

Guidance becomes less reliable when unmanaged components are legacy systems, regulated workloads, or platform dependencies that cannot be safely replatformed in one cycle.

Practitioner Guidance

What to prioritise: Define which cloud assets must be fully codified first, based on blast radius and control sensitivity. Start with assets that affect identity, network exposure, logging, encryption, and recovery, because those are the places where partial coverage most quickly turns into control failure.

What to verify: Confirm that every critical asset has an owner, a source of truth, and a documented exception path. If a team cannot prove whether a resource is managed, it is already outside the reliable control boundary, even if it is technically reachable from the pipeline.

What practitioners underestimate: The hardest problem is not provisioning, but proving completeness. Partial IaC often looks acceptable during normal operations and then fails under incident pressure, when responders need a trustworthy inventory, a clear rollback path, and evidence of the last approved state.

Practitioner takeaway: Treat partial IaC as a governance boundary problem, not a documentation gap. The real risk is not that some resources are manual, but that teams start assuming uniform control over an environment that is no longer uniform.

Related resources from NHI Mgmt Group

• What breaks when credentials are managed outside infrastructure as code?
• What breaks when cloud governance is managed through manual configuration instead of infrastructure as code?
• What breaks when infrastructure-as-code is not part of cloud security architecture?
• What breaks when infrastructure as code embeds overly permissive IAM roles?