Infrastructure as code standards for agencies must protect several boundaries at once: client isolation, provider credentials, reusable intellectual property, environment consistency and handover. Copying a working folder into each client repository creates drift and hidden risk. Forcing every client through one shared state or highly opinionated module creates a different kind of dependency. A useful standard defines the interfaces and evidence every engagement must preserve while allowing cloud, regulatory and customer requirements to vary. The outcome is repeatable change that a client can inspect, approve, operate and eventually own.
This guide treats IaC as a software delivery system rather than a collection of templates. Related reading includes infrastructure as code for safe change, Terraform module security review and CI/CD pipelines for reliable SaaS releases. Although examples use Terraform-style concepts, the controls apply to OpenTofu, cloud templates and other declarative tools. Tool-specific behavior, provider versions and backend security still require direct testing.
Separate client configuration from reusable modules
Give each client a clear repository and account or subscription boundary. Keep environment configuration, approved module versions, policies and deployment workflow visible to that client. Maintain reusable modules in independently versioned repositories with owners, documentation, tests and release notes. A root configuration composes modules for one environment; a module should expose a stable capability rather than encode an entire agency process. Do not hide critical resources behind code the client cannot access. Define source and licensing terms at contract start so handover does not trigger an ownership dispute.
Adopt consistent file, variable, output, naming and documentation conventions. HashiCorp's style guide recommends clear organization, validation, version constraints, separate module and configuration repositories, tests and policy. Require purpose, examples, inputs, outputs, compatibility, security assumptions, upgrade notes and owner for every released module. Pin module and provider versions deliberately and update through reviewed changes. Avoid copying module source into client roots because fixes then fail to propagate. Avoid deeply nested modules whose side effects are difficult to predict or import.
| Artifact | Ownership | Required evidence |
|---|---|---|
| Reusable module | Named agency or joint maintainer | Version, tests, documentation and changelog |
| Client root configuration | Client-visible delivery team | Environment intent, approved versions and plan |
| State | Client-controlled protected backend | Access log, encryption, backup and recovery |
| Policy | Named control owner | Rule, severity, test and exception process |
Protect state, credentials and environment isolation
Use a remote backend with encryption, locking, versioning or backups and tightly scoped access. State can contain resource identifiers and sensitive values even when outputs are marked sensitive. Do not share one state across unrelated clients or broad failure domains. Split state by lifecycle and ownership, not by arbitrary resource count. Document dependencies through stable outputs or an approved discovery mechanism; direct reading of another team's state creates coupling and can expose secrets. Test state restoration and the process for importing or removing resources.
Use workload identity or short-lived credentials in pipelines rather than long-lived client keys. Separate plan from apply authority and require stronger approval for production or high-risk resources. Human engineers should use individual identities with emergency access logged and reviewed. Scope provider roles to the resources and operations required. Protect branch, workflow and environment configuration from unauthorized modification because pipeline code can change deployment authority. Keep secret values in an approved secret system; do not place them in variables files, plan artifacts, logs or example repositories.
Design modules as tested infrastructure contracts
Define required inputs only when the caller must make a real choice. Provide safe defaults for optional behavior, validate values and express preconditions or postconditions where the tool supports them. Outputs should expose stable information needed by consumers, not leak implementation details. Document destructive changes and replacement behavior. Preserve backward compatibility within a major version when practical. A module that silently creates public access, broad identity or unbounded cost is not reusable merely because it deploys successfully.
Test formatting and static validation on every change, then test module behavior. Native Terraform tests can execute plan or apply scenarios and assertions. Add integration tests for representative provider behavior and destructive upgrades. Include security and cost checks at the plan stage. Generate documentation and examples from reviewed interfaces where possible. Test previous-to-new upgrades against disposable environments. A clean initial deployment does not prove that the module handles adoption, import, drift, changed inputs or removal safely.
Use policy as code with accountable exceptions
Translate a bounded set of client controls into plan-time policy: approved regions, required tags, encryption, public exposure, network ranges, identity, backup, logging and allowed services. Open Policy Agent can evaluate Terraform plan JSON and contextual data. Classify rules as advisory, mandatory or escalation. A policy needs an owner, rationale, tests and actionable message. Do not copy a generic policy pack and assume it matches the client's threat model or architecture. Prioritize controls whose violation can be determined reliably before apply.
Exceptions should identify scope, risk, compensating control, approver and expiry. Store them in version control or a linked governed system and make expired exceptions fail visibly. Review policy changes like software because an incorrect rule can block all delivery or permit broad exposure. Retain the plan, policy result, approvals, artifact identity and apply result as release evidence according to retention needs. Separate sensitive plan content from ordinary logs. SLSA concepts can inform provenance for build and release artifacts, while IaC-specific evidence still needs environment and resource context.
| Pipeline gate | Checks | Failure response |
|---|---|---|
| Author | Format, validate, lint and secret scan | Fix before review |
| Review | Module tests, security and ownership | Require qualified approval |
| Plan | Provider initialization, cost and policy | Block or record governed exception |
| Apply | Protected environment and approved artifact | Stop on drift or approval mismatch |
| Verify | Resource, telemetry and control assertions | Rollback, repair or quarantine |
Control plan, apply, drift and recovery
Produce plans in a trusted pipeline and apply the exact reviewed configuration and dependency lock. Treat saved plan artifacts as sensitive and short-lived. Prevent routine local production apply. Use concurrency controls so two changes cannot race. Establish a maintenance window or progressive approach for risky infrastructure. Verify important properties after apply because provider acceptance does not guarantee service health. Define rollback realistically: many infrastructure changes require forward repair, data restoration or traffic switching rather than simply applying the previous code.
Detect drift on a schedule appropriate to change frequency and consequence. Classify drift as emergency repair, authorized external system, provider behavior or unauthorized manual change. Import legitimate changes into code or revert them through an approved path; do not normalize permanent console changes. Alert the owning team with resource and impact context. Rehearse lost state, provider outage, expired credentials, partial apply and module rollback. Document which resources cannot be recreated without data loss and how their recovery integrates with application and business continuity.
Make client handover an ongoing acceptance test
Use client-controlled cloud accounts, state backends, source repositories and critical domains where practical. Provide architecture decisions, module sources and licenses, version locks, state inventory, policies, pipeline definitions, runbooks, known drift and recovery results. Train through participation: client staff should review plans, approve a change, investigate a failure and restore state before the engagement ends. A recorded walkthrough is useful reference but does not prove operational independence. Avoid proprietary wrappers that the client cannot run or replace without an undisclosed service.
Define exit for shared agency services such as registries, runners, observability and secret brokers. State which configurations move, which must be recreated and how access is revoked. Keep a bill of external modules, providers and automation actions with version and ownership. Reconcile every deployed workspace and backend at transition. Remove agency identities only after client operation is verified, then retain evidence of revocation. The final acceptance should include a client-led plan and apply for a safe representative change.
Measure the standard itself. Track module adoption, failed plans, policy violations, expired exceptions, manual changes, deployment lead time and recovery exercises. Review whether controls prevent risk or merely add queue time. Improve common modules from repeated client evidence while preserving versioned compatibility and explicit upgrade choices.
Adoption plan for an agency
- Inventory clients, repositories, states, credentials, tools and unmanaged changes.
- Approve minimum repository, naming, documentation and ownership standards.
- Build one versioned module and one client root as reference implementations.
- Add test, policy, protected plan and exact-artifact apply gates.
- Migrate a low-risk environment and rehearse drift and state recovery.
- Scale by module demand while measuring adoption, exceptions and handover readiness.
Key takeaways
- Separate reusable modules from client-owned environment intent.
- Treat state and pipeline identity as sensitive production assets.
- Test upgrades and recovery, not only clean creation.
- Give policies accountable owners and expiring exceptions.
- Prove client independence with an exercised change before handover.
Frequently asked questions
Should all client infrastructure live in one repository?
Usually not. Unrelated clients need clear access and lifecycle boundaries. Shared modules can use dedicated versioned repositories, while each client keeps visible root configuration. A monorepo may suit one client with aligned teams when access, pipelines and ownership remain clear.
Can state be transferred safely?
Yes, with planning. Back up and lock the source, verify destination encryption and access, transfer securely, reinitialize without changing resources, compare plans and test recovery. Revoke old access only after the destination is authoritative and a client-led operation succeeds.
How many modules should an agency create?
Create modules for repeated, coherent capabilities with owners and meaningful policy, not every resource. Begin from proven client repetition. Too many thin modules increase version and composition work; one giant module hides choices and creates coupled upgrades.
Conclusion
Agency IaC standards should make infrastructure change repeatable without taking ownership away from the client. Separate reusable contracts from environment intent, protect state and identity, test behavior, enforce accountable policy and retain release evidence. When handover is exercised throughout delivery, both agency and client gain faster change with fewer hidden dependencies.