Infrastructure as code for organizations that are not software companies

Infrastructure as code has a presentation problem. It is discussed almost entirely in the language of software engineering, illustrated with continuous deployment pipelines and container orchestration, and demonstrated at a scale that makes it look like something for organizations with a platform team.

The core idea is simpler and much more portable. It is this: the configuration of your systems should exist as a written, versioned, reviewable definition rather than as an accumulated history of changes that someone made through an interface and did not write down.

Stated that way, it is obviously applicable to a manufacturer, a clinic, a law firm or a school district. The question is not whether the principle applies. It is how much of the practice is worth adopting.

The problem it solves

Every environment that is administered by hand accumulates what is politely called configuration drift and less politely called nobody knows why that is like that.

A firewall rule added during an incident in 2022, still present, purpose unrecorded. Three servers that were built identically and are now subtly different because two received a fix and one was missed. A setting that must be a particular value or the application breaks, discovered empirically, documented nowhere. A staging environment that no longer resembles production, so testing in it proves progressively less.

The compound effect is that the environment becomes something to be studied rather than something to be understood. Changes get slower because each one requires investigation first. Recovery gets slower because rebuilding requires reconstructing knowledge that only exists in the running system. And the knowledge is concentrated in whoever has been there longest, which is a business risk that has nothing to do with technology.

What to adopt first, and what to skip

You do not need the full practice. Adopted in order of value per unit of effort, the sequence looks like this.

Version control for configuration, before automation of anything. Simply putting your configuration files, scripts and network definitions into a repository — with a history, a diff, and a record of who changed what and why — delivers a substantial share of the benefit and requires no new tooling philosophy. It answers "when did this change and why" which is the question you actually have during an incident.

Definition of the standard build. One document, precise enough to be executed, describing what a standard server or workstation of each type contains. Written before it is automated. Most of the value is in the act of writing it, because the writing surfaces the things nobody could state.

Automated provisioning of new systems. Once the build is defined, automate it. New systems being identical by construction is worth more than the time saved building them.

Automated enforcement of configuration, only where it earns its place. This is where the practice starts requiring genuine investment, and where organizations that are not software companies should be selective. Enforce the settings that carry security or compliance weight. Leave the rest alone.

Full pipeline automation with automated testing. Appropriate for organizations deploying frequently. If you change infrastructure monthly rather than daily, the pipeline costs more to maintain than it returns.

The cultural change is the hard part

The technical adoption is straightforward. The behavioral change is not, and it is where these efforts fail.

The rule that makes it work is that changes are made to the definition, not to the system. An administrator who fixes something directly on a server at 2am and does not update the definition has restored service and reintroduced drift. Over enough incidents, the definition becomes fiction, and a fictional definition is worse than none because it is trusted.

This needs to be a stated expectation rather than an aspiration, and it needs an escape valve, because sometimes the right answer at 2am genuinely is to fix the system directly. The escape valve is a rule that emergency changes are permitted and must be reconciled within a defined window — a ticket, a follow-up, a diff. What is not permitted is the change disappearing into the environment unrecorded.

Why this is a security control

It is worth stating plainly, because infrastructure as code is usually sold on efficiency and its security value is larger.

A defined environment is an auditable one. You can answer, with evidence, which systems have a given setting — rather than sampling and hoping. You can prove a control is applied consistently, which is exactly what a security questionnaire or an audit asks and exactly what hand-administered environments struggle to demonstrate.

A defined environment is also a recoverable one. The worst ransomware outcomes we have seen involved organizations that had data backups but no way to rebuild the systems that used the data. Restoring 4TB of files is straightforward. Reconstructing the eleven servers, their configuration, and their interdependencies from memory, under pressure, is where the weeks go.

That is the argument, and it does not require anyone to become a software company. It requires that the environment be written down somewhere other than in the environment itself.