Compliance

This is the Compliance demo. Every visitor shares this company, and it resets every night.

What you change here, everyone sees until the next reset. Email, payments, and the AI models are switched off.

Start your own trial
  • EU GDPR (2016)
  • ISO 27001:2022
  • NIS2
  • NIS2 Netherlands (Cbw, 2026)

Nothing found that matches the search criteria.

Start your own trial
SV
Sam de Vries
sam.devries@tidewell-it.example

Change Management Procedure

Edit

Purpose

This Procedure controls changes to production systems, hosting platforms, and customer environments, so that changes are planned, tested, approved, and reversible.

Scope

It applies to every change to systems, configuration, networks, and software that Tidewell IT operates, and to changes we make in customer environments.

Roles

  • Change requester: describes and implements the change.
  • Peer reviewer: an engineer who did not write the change.
  • Change Manager: owns this Procedure and chairs the weekly change review.
  • Incident Coordinator: approves Emergency changes together with one more approver.
  • Service Desk Lead: sends notices to customers.

Procedure

Raise and classify

  1. The requester raises a change with the description, the risk, the impact, the test, and the rollback plan.
  2. The Change Manager classifies the change as Standard, Normal, or Emergency. A Standard change is a low-risk, repeatable change from the pre-approved list.

Review and approve

  1. A peer reviews the change, the test result, and the rollback plan before approval.
  2. A Standard change is pre-approved. A Normal change is approved at the weekly change review, chaired by the Change Manager.
  3. An Emergency change is approved by the Incident Coordinator and one more approver, and is reviewed within 2 working days.
  4. Work that affects customers is announced at least 5 working days ahead, unless the change is an Emergency.

Implement and verify

  1. The requester implements the change in the agreed window and follows the plan.
  2. The requester verifies the result with the checks named in the plan, and rolls back when a check fails.
  3. The requester updates the configuration records and the baseline of the systems that changed.

Close and learn

  1. The requester closes the change with the outcome, and the Change Manager confirms the close.
  2. Every failed change is reviewed to find the cause. Lessons go back into the test and rollback guidance.
  3. The Change Manager reports the number of changes per class, the number of failures, and the number of Emergency changes to the ISMS Manager every quarter.

Records

  • The change record with its class, approvals, test result, and outcome.
  • The minutes of the weekly change review.
  • The review of each failed change and of each Emergency change.

Related documents

  • Secure Development and Change Policy
  • Vulnerability and Patch Management Procedure
  • Incident Handling Procedure

Review

The Change Manager reviews this Procedure at least once a year and after a significant change, and when the failure review shows a gap in the Procedure itself.

Framework
Code
Title
Mandatory
iso-27001-2022
6.3
Planning of changes
Mandatory
iso-27001-2022
A.8.9
Configuration management
iso-27001-2022
A.8.32
Change management

Are you sure?

This action cannot be reverted.

Leave this page?

Your changes on this form are not saved. If you leave, they are lost.