Change Management Procedure
Change classification, CAB, testing and rollback
1. Change Types
| Type | Description | Examples | Approval | Implementation time |
|---|---|---|---|---|
| Standard | Repeatable, low-risk, pre-approved | Server restart, password change, antivirus update | ▸ [Pre-approved / IT Admin independently] | ▸ [Any time within maintenance window] |
| Normal | Planned, requires assessment and approval | Software update, firewall configuration change, new system deployment | ▸ [CAB – min. 48h before]min. 48h before deployment | ▸ [Maintenance window – see section 3] |
| Emergency | Immediate response to an incident or critical vulnerability | Critical 0-day vulnerability patch, attacker IP block, repair of key system failure | ▸ [CISO + one Board member]minimum 2 persons | ▸ [Immediate, with full post-implementation documentation] |
2. Change Advisory Board (CAB)
▸ Organisation completes – CAB composition
| CAB Role | Position | Name |
|---|---|---|
| CAB Chair | ▸ CISO | ▸ |
| Business representative | ▸ [Director / Manager] | ▸ |
| IT Administrator | ▸ IT Admin | ▸ |
| System owner (if applicable) | ▸ | ▸ |
CAB meeting frequency: ▸ [weekly]min. every 2 weeks
Approval method: ▸ [email / ticketing system / meeting]
3. Maintenance Windows
▸ Organisation completes – maintenance window schedule
| System type | Standard maintenance window | Exceptions |
|---|---|---|
| Production IT systems | ▸ [e.g. Wednesday 22:00–02:00] | ▸ [emergency changes outside window – CISO approval] |
| OT/ICS systems (if applicable) | ▸ [e.g. First Sunday of month 06:00–10:00] | ▸ [only with Board approval] |
| Website / customer portal | ▸ [e.g. Saturday 01:00–05:00] | ▸ |
4. Requirements for Every Change
Before implementation
- Described and approved (Change Request – RFC).
- Risk assessment – especially for key systems.
- Test plan – how to verify correct operation after the change.
- Rollback plan – how to revert the change if something goes wrong.
- Backup before implementing changes to critical systems (DOC-012).
After implementation
- Verification per test plan.
- Update of configuration documentation.
- Close RFC with result (success / partial success / rollback).
- For emergency changes: full retrospective documentation within ▸ [24h].
5. Change Register
All changes are recorded in the central system: ▸ [e.g. ServiceNow / Jira / Excel register]. Entry contains: ID, type, description, risk, approval, implementation date, result, responsible person.
Change register retention: ▸ [min. 5 years]min. 5 years – NIS2.
6. Change History
| Version | Date | Author | Description | Approved by |
|---|---|---|---|---|
| ▸ 1.0 | ▸ DD/MM/YYYY | ▸ | ▸ Initial release | ▸ Board |
DOC-013 Change Management Procedure | v1.0 | NIS2/ISMS