Safety Norms: Infrastructure as Code

1Purpose, Scope, and Safety Principles

These norms apply to everyone who writes, reviews, runs, or approves infrastructure code. In practice that includes templates for cloud accounts, virtual networks, compute clusters, managed databases, object storage, DNS records, identity and access policies, monitoring, and the pipelines that apply them. They also cover the repositories, state backends, and runner agents that hold or execute that code.

The purpose is to prevent accidental outages, data loss, exposure of private information, and unauthorized privilege. Four principles guide every rule: least privilege, separation of environments, reversibility, and evidence before change. Infrastructure code is production software with production consequences, so it receives the same care as an operational change.

• Mandatory: no manual edits to production resources managed by code, except under the emergency procedure in the incident section, and every such edit must be reconciled back into code.
• Recommendation: prefer small, reversible changes that can be reviewed in one sitting.

2Roles, Competence, and Accountability

Name the following roles for every infrastructure stack. The author writes or edits the code. The reviewer checks the change for correctness and risk. The approver authorizes deployment to the target environment. The platform owner owns shared modules, pipelines, and accounts. The data owner decides on changes that affect stateful systems. One person may hold more than one role in a development environment, but no one should author and approve their own change for production.

Competence comes before access. Authors need documented training on the provider tooling, the organization's module library, and secrets handling. Production deployment rights are granted in writing by the platform owner and reviewed on a fixed schedule. Shared administrative accounts are prohibited; each person uses a named identity with multifactor authentication.

• Mandatory: keep a current register of who may approve changes for each environment and review it at an interval set by the platform owner.
• Mandatory: remove production access within one business day after a role change or departure.
• Recommendation: pair new authors with an experienced reviewer for their first several merged changes.

3Hazards and Risk Assessment

Typical activities include writing modules, running plan and apply operations, editing identity policies, changing firewall and network rules, rotating credentials, scaling clusters, updating DNS records, and managing state files. The most common harms are accidental deletion or replacement of databases and storage, public exposure of buckets or management ports, plaintext secrets in state files or logs, drift between code and live systems, and partial applies that leave systems inconsistent. Unvetted third-party modules and unbounded autoscaling can also create security gaps and large unexpected costs.

Assess each change before work begins. Rate it low, medium, or high using blast radius, data sensitivity, reversibility, and whether it touches identity, network boundaries, encryption, or logging. Record the rating in the change request. A stateful deletion, an identity policy change, or a change that disables logging is automatically high.

• Low: tag updates, non-production sizing changes, and documentation-only module edits.
• Medium: new workloads in isolated networks, scaling policy changes with cost limits, and non-sensitive configuration.
• High: any change to identity policies, network ingress, encryption keys, backups, audit logging, or deletion of stateful resources.

4Preventive Controls and Safe Work Practices

Use version control with protected main branches, required peer review, automated policy checks, and promotion through development, test, and production in that order. Before any apply, the author attaches the plan output, and the reviewer checks it for create, update, replace, and destroy actions. A plan that replaces or destroys a stateful resource is treated as a high-risk change regardless of how small the code diff looks.

Pin provider and module versions so deployments are repeatable. Test upgrades in a non-production environment before promotion. Write the rollback procedure before applying a high-risk change, confirm that monitoring and alerting are active, and schedule the change within an approved window. Where the tool supports deletion protection or lifecycle guards on databases and storage, enable them and document any exception.

• Mandatory: production changes are applied only through the approved pipeline, never from a personal workstation.
• Mandatory: any plan that deletes or replaces a stateful resource requires approval from the data owner and a verified recent backup or snapshot.
• Mandatory: storage, database, and management endpoints are not exposed to the public internet unless a documented security review approves a specific exception.
• Mandatory: pipeline credentials are short-lived and scoped to a single environment.
• Recommendation: run static analysis and policy-as-code checks that flag open ingress, unencrypted storage, and missing ownership tags before review.
• Recommendation: keep each merge request to one logical change so reviewers can judge its effect.

5Equipment, Environment, Information, and Protective Safeguards

Keep environments separate by account, subscription, or project, with distinct credentials and network boundaries. Pipeline runners should be hardened, isolated, and preferably ephemeral. Engineer workstations need endpoint protection, full disk encryption, automatic screen locking, and current operating system patches. Treat the workstation as a privileged device because it often holds provider sessions and local copies of state.

Information needs particular care. State files, plan outputs, and logs can contain connection strings, keys, and personal data. Store state in an encrypted remote backend with restricted access and access logging. Never commit secrets, private keys, or real personal data to repositories or test fixtures. Use a dedicated secrets manager and short-lived credentials. Where personal data is processed, confirm data residency, retention, and logging obligations with the privacy office, since these depend on jurisdiction and must be verified locally.

• Mandatory: no long-lived credentials in code, variable files, or CI logs.
• Mandatory: state backends enforce encryption at rest, access restriction, and versioning so that a prior state can be recovered.
• Recommendation: enable repository secret scanning and pre-commit hooks that block likely credentials.
• Recommendation: tag resources with an owner and a data classification, but never place personal data in tags.

6Incident, Near-Miss, Emergency, and Escalation

Treat as incidents any unplanned outage, unauthorized or unreviewed change, production drift discovered during review, exposed credential, or suspected compromise. A near-miss is a risky change caught before harm occurred, such as a plan that would have destroyed a database. Report both through the internal incident channel without delay. Do not wait to confirm impact before reporting.

Immediate actions: pause the pipeline for the affected stack, preserve logs, plan outputs, and the prior state version, and notify the incident coordinator. Avoid uncontrolled manual fixes that overwrite evidence. If a credential may be exposed, revoke and rotate it under security team direction. Suspected compromise goes to security immediately, and personal data exposure goes to the privacy and legal contacts. If a system affects physical safety or medical care, contact emergency services first and follow the operating organization's emergency procedure.

• Mandatory: report incidents within the time limit set by the internal incident policy.
• Mandatory: emergency changes need approval from the on-call lead, must be logged, and must be reconciled into code within the period set by policy.
• Mandatory: rollback uses the approved pipeline unless the incident commander declares a documented emergency bypass.
• Recommendation: rehearse restoring a deleted test resource from backup during a tabletop exercise.

7Documentation, Training, Monitoring, and Review

Keep records that let another engineer reconstruct any change: repository history, approval records, plan outputs, module catalog entries with owners, the access register, and runbooks for common operations. Set retention periods with the records owner and legal counsel, because requirements vary by jurisdiction and sector.

Train authors on provider security settings, secrets handling, pipeline use, and this document before granting production rights. Refresh training on a fixed schedule and after major tooling changes. Monitor for drift, unexpected public exposure, cost anomalies, failed or partial applies, and unusual administrative activity. Review access lists, module versions, and these norms after each high-severity incident and on a fixed schedule.

• Mandatory: run drift detection on production stacks and investigate any unexplained difference.
• Mandatory: access reviews must remove unused privileged accounts.
• Recommendation: share a short summary of changes, incidents, and near-misses with stakeholders on a regular cadence.

8Authorized Testing and Responsible Use

Test infrastructure code only in environments you own or are explicitly authorized to test. Do not scan, probe, or change third-party or shared systems outside your approved scope. Security scans, penetration tests, and failover or chaos experiments require written approval, a defined scope, blast-radius limits, a stop condition, and a named responder. Authorization rules vary by jurisdiction and provider terms, so confirm them with the legal team and current provider documentation.

Do not use infrastructure code to collect data without a lawful basis, hide activity from audit logs, disable security controls for convenience, or host unlawful content. Report requests that appear to violate these limits to the platform owner. Responsible use also means recognizing the limits of automated tests and keeping human review in the loop for decisions with significant impact.

• Mandatory: run failover and resilience tests only in non-production unless a documented exception exists.
• Mandatory: never disable audit logging or security monitoring to complete a change.
• Recommendation: generate synthetic test data; never copy production personal data into test environments.

Implementation checklist

• Confirm the change has a named author, a separate reviewer, and an approver for the target environment.
• Classify the change as low, medium, or high risk and record the rating in the change request.
• Attach the plan output and check it for destroy or replace actions on stateful resources.
• Verify a recent backup or snapshot exists before approving any stateful deletion.
• Confirm no secrets, private keys, or personal data appear in code, variable files, state, or logs.
• Apply production changes only through the approved pipeline using short-lived credentials.
• Write and test the rollback steps before the change window opens.
• Confirm monitoring and alerting are active before and after the apply.
• Report incidents and near-misses immediately and preserve logs and state versions.
• Verify jurisdiction-specific laws, standards, and provider terms with qualified professionals.