• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Standard : Infrastructure changes are peer reviewed and version controlled

Purpose and Strategic Importance

This standard ensures that all infrastructure changes — including infrastructure-as-code, configuration updates, and environment changes — are made through version-controlled systems and are subject to mandatory peer review. This improves system reliability, increases traceability, and reduces the risk of human error.

Aligned to our "Architect for Change" and "Secure by Design" policies, this standard promotes safer, auditable, and higher-quality infrastructure operations. Without it, changes become risky, undocumented, and harder to diagnose or recover from when failures occur.

Strategic Impact

  • Greater system resilience and reliability
  • Reduced change-related outages and faster recovery
  • Stronger compliance and audit capabilities
  • Improved cross-team learning and trust

Risks of Not Having This Standard

  • Untracked and unverified infrastructure changes leading to service outages
  • Increased difficulty diagnosing and recovering from incidents
  • Higher risk of security vulnerabilities due to unauthorised changes
  • Lack of audit trail for compliance and governance
  • Knowledge silos and reduced collaboration

CMMI Maturity Model

Level 1 – Initial

Category Description
People & Culture Infrastructure changes are made manually without formal oversight.
No peer review or consistency in approach.
Process & Governance Changes are applied ad hoc without tracking or approvals.
Technology & Tools No use of version control.
Scripts or configurations may exist only locally.
Measurement & Metrics No tracking of change success, failures, or audit logs.

Level 2 – Managed

Category Description
People & Culture Teams recognise the need for peer review but apply it inconsistently.
Process & Governance Manual documentation exists for some infrastructure changes.
Technology & Tools IaC may be stored in version control but is not enforced.
Pull requests may be informal.
Measurement & Metrics High-level incident data may be linked to changes informally.

Level 3 – Defined

Category Description
People & Culture Peer review is expected for all infrastructure changes.
Traceability and ownership are valued.
Process & Governance Version-controlled changes are required before promotion to live.
Technology & Tools IaC pipelines validate and apply changes post-review.
Automated checks are used consistently.
Measurement & Metrics Change volumes, rollback rates, and time to approval are tracked.

Level 4 – Quantitatively Managed

Category Description
People & Culture Peer review improves shared understanding and reduces silos.
Process & Governance Policy-as-code and compliance scans are embedded in reviews.
Technology & Tools Automated pipelines enforce guardrails and generate audit logs.
Measurement & Metrics Time to deploy vs. time to approve is optimised and reviewed regularly.

Level 5 – Optimising

Category Description
People & Culture Reviews are used as learning opportunities.
Teams reflect on and refine change workflows continuously.
Process & Governance Risk-based review rules adapt dynamically to context and history.
Technology & Tools Integrated analytics surface change anomalies and improvement areas.
Measurement & Metrics Continuous reduction in change-related incidents and increased delivery safety.

Key Measures

  • % of infrastructure changes peer reviewed before deployment
  • % of infrastructure changes tracked in version control
  • Average time from change proposal to deployment
  • Change-induced incident rate (pre- and post-standard adoption)
  • Compliance rate against infrastructure change policies
Associated Policies
  • Architect for Change
  • Secure by Design
Associated Practices
  • Policy as Code

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering