Getting Infrastructure-as-Code Changes Under Real Governance

Governance only works if the code actually represents the current state of your infrastructure; if manual changes have been applied outside the pipeline, your code is already out of sync with reality, and any review process built on top of it is reviewing a fiction. Run drift detection regularly, comparing actual infrastructure state against what the code declares, and treat any drift found as something to reconcile immediately, not a background task to get to eventually.

A change applied directly through a cloud console, even a small, well-intentioned one, breaks the premise that your code is the source of truth and undermines every review process built around it. Restrict direct write access to infrastructure to a small, clearly justified set of break-glass scenarios, and route everything else through the same pull-request-and-apply pipeline, so "review the diff before it ships" is actually true for every change, not just the ones someone remembered to make through the proper path.

A reviewer looking at a raw infrastructure diff, a security group rule added, a resource's size changed, often can't tell whether the change is routine or risky without more context. Require a short, specific description of why a change is being made as part of every pull request, and treat infrastructure changes with elevated risk, anything touching network boundaries, access permissions, or production data stores, with a higher bar for review than a routine capacity change and a named second reviewer where the risk warrants it.

"We discussed it in a channel" is not evidence an auditor, or a future engineer trying to understand why something is configured a certain way, can rely on. Keep the pull request itself, with its description, review comments, and approval, as the durable record, and make sure whatever mapping you do to a specific compliance control, if you're pursuing one, pulls directly from that record rather than requiring someone to reconstruct history from memory or a chat search months after the decision was actually made.

Requiring the same heavyweight review for a routine, low-risk change (bumping an instance count within an already-approved range) as for a change to network isolation or access control slows down the routine work without meaningfully improving safety on the changes that actually carry risk. Tier your review requirements explicitly: lighter, faster review for low-risk categories, and a genuinely thorough review, possibly requiring a second approver, for anything touching a trust boundary or compliance-relevant control. Publish the tiers themselves, not just enforce them silently, so engineers know upfront which category their change falls into before they open the pull request.

For example, imagine a team that bumps an instance count inside an approved range and, the same week, edits a security group to open a port to a partner. Under a tiered policy the first change merges after a single reviewer glances at the diff, while the second needs a written reason and a named second reviewer. A common mistake is to write the tiers down but leave them vague, so engineers guess which category applies and default to the heavier path for everything. The fix is to list concrete examples under each tier, such as capacity changes in the light tier and anything touching network isolation or access control in the heavy tier, and to update those examples whenever a review shows a change was misclassified.

A governance policy written once and never revisited tends to either calcify into pure friction that people route around, or quietly stop matching the actual risk profile of the infrastructure it governs, as new resource types and new attack surfaces get added over time. Review the policy itself, not just individual changes, on a recurring schedule, and specifically ask whether the tiering from the point above still matches where the real risk actually sits today, not where it sat when the policy was first written.

To put the whole policy into practice, work through these steps in order:

1. Run drift detection on a regular schedule and reconcile any gap between declared code and actual infrastructure right away, so reviews describe reality.
2. Restrict direct write access to a small set of break-glass scenarios, and send every other change through the same pull-request-and-apply pipeline.
3. Require a short, specific reason on every pull request, and name a second reviewer for changes touching network boundaries, access permissions, or production data stores.
4. Keep the pull request, with its description, review comments, and approval, as the durable audit record instead of relying on chat history.
5. Publish explicit review tiers, lighter for routine capacity changes and thorough for trust boundaries, so engineers know the bar before they open a pull request.
6. Review the policy itself on a recurring schedule and check whether the tiers still match where the real risk sits today.