Skip to content

Enterprise IT Change Management, Maintenance Windows & Release Governance Standard

STD-OPS-002 Architecture Standard v1.0.0
Last Updated 2026-10-15
Author Infrastructure Operations Team
Audience All Systems Administrators, Network Engineers, Helpdesk Personnel, and Engineering Leads
Target Architecture:
All Production Compute, Network, Storage & Cloud Services

1. Purpose & Scope

This standard establishes the mandatory governance model, classification matrix, risk assessment criteria, and maintenance windows for all alterations to enterprise IT infrastructure.

The purpose is to minimize service disruption, prevent unexpected outages, ensure configuration reproducibility, and guarantee that every modification has a tested, documented rollback plan.

This standard applies to all physical, virtual, cloud, network, and identity systems across all production and stage environments.


2. Regulatory & Compliance Context

  • ISO/IEC 27001:2022: Control 8.32 (Change Management).
  • ITIL v4 Framework: Change Enablement & Continual Improvement.
  • CIS Controls v8: Control 4 (Secure Configuration of Enterprise Assets and Software).

3. Change Classification Matrix

Every modification must be submitted as a Request for Change (RFC) classified into one of three categories:

Change TypeDefinitionApproval RequiredLead TimeTesting / Rollback Plan
Standard ChangeLow-risk, recurring, procedural tasks with established SOPs (e.g., Routine monthly patching per SOP-SYS-020, DNS record additions).Pre-approved via SOP register24 HoursPre-defined in SOP
Normal ChangeModerate to high-risk modifications (e.g., Core switch firmware upgrades, firewall rule overhaul, AD schema update).Formal Change Advisory Board (CAB)5 Business DaysMandatory lab-tested rollback plan
Emergency ChangeUrgent break-glass interventions required to resolve a P1 critical outage or mitigate an active cyber incident (e.g., SOP-SEC-010).Emergency CAB (ECAB): CISO + Lead SysAdminImmediate (Oral / Chat sign-off, retrospective RFC in 24h)Rollback or fail-forward strategy required

4. Maintenance Windows & Freeze Calendars

To protect business operations and core revenue channels, production modifications may occur only during authorized maintenance windows:

┌────────────────────────────────────────────────────────┐
│ ENTERPRISE MAINTENANCE SCHEDULE │
├─────────────────────────â”Ŧ──────────────────────────────┤
│ Window A (Core Network) │ Thursday 22:00 – Friday 02:00│
│ Window B (Hypervisors) │ Saturday 23:00 – Sunday 05:00│
│ Daily Micro-Window │ Tuesday / Thursday 05:00 – 06:00 (Standard Low-Risk Only) │
└─────────────────────────┴──────────────────────────────┘

4.1 Production Freeze Windows

All production changes (excluding emergency security interventions) are strictly frozen during:

  • Financial Fiscal Year / Quarter End: Final 5 business days of each fiscal quarter.
  • Enterprise Holiday Freeze: December 15 through January 5 annually.

5. Mandatory RFC Submission Requirements

Every Normal and Major RFC submitted to the CAB must include:

  1. Business Justification & Impact Statement: What business capability or security defense is enhanced?
  2. Detailed Execution Script: Step-by-step commands or runbook reference (e.g., linking to approved SOP).
  3. Verified Pre-Flight Health Checks: Validation that infrastructure is clean before executing.
  4. Actionable Rollback Procedure: Exact, timed reversal commands if validation tests fail.
  5. Success Criteria & Post-Change Verification: Explicit functional tests to confirm normal service.

6. Change Advisory Board (CAB) Governance

  • Meeting Cadence: Every Tuesday at 14:00.
  • Voting Quorum: Lead Systems Administrator, Network Lead, Cyber Security Lead (CISO delegate), Application Owner.
  • Unanimous Consent: Required for all Tier-0 changes (Domain Controllers, Core Firewalls, Backbone Storage).

7. Post-Implementation Review (PIR) & PMR Trigger

A formal Post-Implementation Review and Post-Mortem Report (templates/template-pmr.md) is mandatory if:

  • A change causes unplanned downtime exceeding 5 minutes.
  • The change execution failed and required an emergency rollback.
  • A change resulted in data loss, credential invalidation, or security alert escalation.

The PMR must be delivered to executive leadership within 3 business days of the event.

Comments