Change Management in the ISMS: Steering Changes Safely

Why Change Management Is Part of the ISMS

Information security is not a static state. Systems are updated, configurations changed, new software introduced, old software retired. Each of these changes can improve or degrade the security posture — and without a structured process, you only find out when something has already gone wrong.

ISO 27001 addresses this topic in Annex A.8.32 (Change Management). The requirement states: changes to information processing facilities and information systems must be subject to a change management procedure. Anyone who has already built an ISMS is familiar with the standard's requirements. This sounds abstract but means something very concrete: before someone changes anything on a production system, it must be clear what is being changed, why, what risks are involved, who approves the change, and how it can be reversed if things do not go as planned.

In many mid-market companies, this process is precisely what is missing. The IT department installs an update, reconfigures a firewall rule or migrates a server without anyone outside IT knowing about it. This works until it doesn't: a faulty update takes down the email server, a changed firewall rule blocks access to a business-critical system, a migration aborts and leaves inconsistent data behind.

Change management in the ISMS is not meant to slow down the IT department or bury it in bureaucracy. It is meant to ensure that changes are carried out consciously, planned and traceably — and that a Plan B exists in case of failure.

Change Types: Standard, Normal and Emergency

Not every change requires the same amount of planning and approval. A routine Windows update is fundamentally different from migrating a database to a new system. That is why good change management distinguishes three types, each following a different process.

Standard Changes

Standard changes are recurring changes with low risk that have been pre-approved and are carried out according to a fixed procedure. They require neither an individual risk assessment nor a separate approval, because both have already been granted in advance.

Typical examples of standard changes:

• Installation of approved software from the software catalog
• Regular operating system updates and security patches (per defined patch cycle)
• Creating, modifying or deactivating user accounts
• Replacing defective hardware with identical models
• Adjusting printer permissions or network drive mappings
• Certificate renewals with identical parameters

For a change to qualify as a standard change, it must meet three criteria: it has been successfully carried out multiple times, the risk has been documented and assessed as low, and a written work instruction exists for execution.

Standard changes are recorded in the change log but not individually approved. Pre-approval typically occurs once a year through the Change Advisory Board or the IT manager.

Normal Changes

Normal changes are planned changes that require an individual risk assessment and explicit approval. They account for the majority of changes that go beyond routine activities.

Examples of normal changes:

• Introducing new software or a new cloud service
• Migrating systems or databases
• Changes to network architecture (segmentation, VPN configuration, firewall rules)
• Updates beyond simple security patches (major versions, feature releases)
• Changes to encryption standards or authentication methods
• Introducing or modifying monitoring and logging systems
• Relocating servers or network components
• Changes to the backup concept

Normal changes go through the full change process: request, risk assessment, approval, planning, implementation, testing, post-implementation review. Lead time varies depending on complexity and risk, from a few days to several weeks.

Emergency Changes

Emergency changes are unplanned changes that must be carried out immediately because an acute threat or severe outage exists. They follow an expedited approval process, with documentation completed after the fact.

Typical situations for emergency changes:

• Applying a critical security patch for an actively exploited vulnerability (zero-day)
• Isolating a compromised system from the network
• Immediately locking a user account when compromise is suspected
• Emergency firewall rule changes to defend against an ongoing attack
• Restoring a system after an outage when deviation from the documented configuration is necessary

The critical point: emergency changes bypass the normal approval process, but they do not bypass documentation. Every emergency change must be retroactively documented, assessed and confirmed by the CAB within 24 to 48 hours.

Change Advisory Board for SMEs: Pragmatic, Not Bureaucratic

In large enterprises, the Change Advisory Board (CAB) is a formal body with regular meetings, defined members and its own process. In mid-market companies, this does not need to be as elaborate — but the function still needs to be fulfilled: there must be a forum where changes are assessed, discussed and approved.

Composition

A CAB for an SME with 50 to 200 employees typically consists of 3 to 5 people:

• IT manager or system administrator: Assesses technical feasibility and technical risk.
• Information Security Officer (ISO): Assesses the impact on information security.
• Representative of the affected business unit: Assesses the impact on business operations. Who this is depends on the specific change.
• Optional: management or their representative: For changes with high risk or high costs.
• Optional: external IT service provider: When IT is fully or partially outsourced.

Meeting Format

The CAB does not need to sit together for hours. A weekly 30-minute meeting is sufficient in most cases. The agenda is straightforward:

1. Review open change requests (check risk assessment, clarify questions, approve or reject)
2. Check status of ongoing changes (is everything on track?)
3. Review completed changes (did everything work, are there lessons learned?)
4. Retroactively assess emergency changes from the past week

With low change volume, the CAB can also meet bi-weekly. What matters is regularity: if the CAB is only convened on an ad-hoc basis, the habit of carrying out changes without approval quickly takes hold.

Decision-Making

The CAB decides on the approval of normal changes. There are four options for the decision:

• Approved: The change may be carried out as requested.
• Approved with conditions: The change may be carried out, but under certain conditions (e.g., outside business hours, with enhanced monitoring, after additional testing).
• Deferred: The change is not rejected, but information is missing or the risk assessment is incomplete. The requester must provide additional details.
• Rejected: The change will not be carried out. The justification is documented.

Risk Assessment Before Changes

Every normal change and every retroactively assessed emergency change requires a risk assessment. This assessment does not need to be scientifically precise, but it must cover the essential risk dimensions.

The Five Core Questions of Change Risk Assessment

1. What can go wrong? Identify realistic failure scenarios. A database upgrade can lead to incompatibilities with application software. A firewall change can block legitimate traffic. A server migration can lead to data loss if the migration fails.

2. How likely is a failure? Based on experience, the complexity of the change and the quality of preparation. A simple update on a test system that was previously tested successfully has a lower failure probability than a first-time migration without a test run.

3. What are the impacts of a failure? Impacts on availability (system outage), integrity (data loss, data inconsistency), confidentiality (unintended data access) and business operations (productivity loss, customer complaints, contractual consequences).

4. Which systems and processes are affected? Identify dependencies: what other systems depend on the affected system? What business processes use it? How many users are affected?

5. Is the change reversible? Can the change be rolled back, and if so, how quickly and at what cost? A configuration change is typically quickly reversible. A database migration often is not.

Risk Matrix for Changes

A proven model for change risk assessment uses two dimensions: impact (low, medium, high, critical) and probability of failure (low, medium, high). The combination yields a risk level that determines the approval path.

The risk level determines the approval path:

• Low: IT manager approves alone, CAB is informed.
• Medium: CAB approves in the regular weekly meeting.
• High: CAB approves, management is informed, enhanced rollback plan required.
• Critical: Management approves personally, dedicated planning meeting, full test on staging environment, rollback tested.

Approval and Documentation Process

The change process from idea to completion follows a clear workflow. This workflow is complete for normal changes and applies in adapted form for standard and emergency changes.

Phase 1: Create Change Request

The requester fills out a change request containing at least the following information:

• Description of the change: What exactly is being changed?
• Justification: Why is the change necessary? What problem does it solve?
• Affected systems and services: Which infrastructure components are affected?
• Planned date and duration: When should the change be carried out, and how long is it expected to take?
• Risk assessment: Assessment based on the five core questions (see above).
• Rollback plan: How is the change reversed if it fails?
• Test plan: How is correct functioning verified after the change?
• Communication plan: Who needs to be informed in advance?

Phase 2: Assessment and Approval

The change request is presented to the CAB. The CAB evaluates the risk assessment, reviews the rollback plan and decides on approval. For high-risk changes, the CAB may require additional measures: extended testing, implementation outside business hours, provision of additional resources or involvement of an external specialist.

Approval is documented in writing. This can be an entry in a change management tool, a signed email or a note in the change log. What matters is that the approval is traceable and attributed to a date and a person.

Phase 3: Planning and Preparation

After approval, the change is prepared. This includes:

• Informing all affected individuals and departments
• Creating and verifying backups of affected systems
• Preparing a test environment (if required)
• Providing rollback materials (configuration files, backup media, installation media)
• Blocking a time window in the calendar and organizing on-call support

Phase 4: Implementation and Testing

The change is carried out according to the documented plan. Every step is logged, including deviations from the plan and their justification. After implementation, the defined tests are executed to verify correct functionality.

If the tests fail, the rollback plan is activated. The rollback is likewise logged and the change request is closed with a status of "failed."

Phase 5: Closure and Documentation

After successful implementation and passed testing, the change request is formally closed. The IT documentation is updated: network diagrams, system documentation, configuration management database (CMDB), operations manuals. The change is marked as completed in the change log.

The Rollback Plan

A rollback plan is not an optional add-on but a mandatory component of every normal and emergency change. It describes how the change is reversed if it fails or has unexpected impacts.

Contents of a Rollback Plan

• Trigger criteria: Under what conditions is the rollback triggered? Not every deviation requires a rollback. Define clear criteria: "If the email server is not reachable within 15 minutes after the update" or "If response times of the ERP system permanently exceed 5 seconds after migration."
• Rollback steps: Concrete, step-by-step instructions for returning to the previous state. Not "restore backup," but: "1. Stop service XY. 2. Replace configuration file /etc/app/config.yaml with backup version from time T. 3. Restore database from snapshot at time T (command: ...). 4. Start service XY. 5. Perform functional test."
• Time frame: How long does the rollback take at most? This information is important for correctly sizing the maintenance window.
• Responsible person: Who carries out the rollback? Who decides whether the rollback is triggered?
• Communication: Who needs to be informed when the rollback is triggered?

Testing the Rollback

For changes with high or critical risk, the rollback should be tested in advance — ideally in a test environment. A rollback plan that has never been tested is a hope plan, and hope is not a strategy.

Post-Implementation Review

The post-implementation review (PIR) is the step that most organizations skip — and thereby miss an important learning opportunity. It takes place after a change has been completed and evaluates whether the change was successful and what can be done better next time.

Timing

The PIR should not take place on the day of the change but after an appropriate observation period. For simple changes, one week is sufficient. For complex migrations or system introductions, 2 to 4 weeks may be appropriate. This period allows enough time to identify problems that only occur during ongoing operations.

Contents of the PIR

• Goal achievement: Was the objective of the change met? Was the problem that triggered the change resolved?
• Plan deviations: Were there deviations from the plan? If so, why and with what consequences?
• Unforeseen problems: Did problems arise after the change that were not identified in the risk assessment?
• Rollback use: Did the rollback plan need to be activated? If so, did it work?
• Time expenditure: How long did the change actually take compared to the plan?
• Improvement suggestions: What would you do differently next time?

Using the Results

Findings from the PIR feed into three areas:

1. Improving the change process: If risk assessments regularly overlook certain risks, the assessment methodology is adjusted.
2. Defining standard changes: If a normal change has been carried out multiple times successfully and without complications, it can be reclassified as a standard change.
3. Documenting lessons learned: Findings are recorded in the change log and serve as a reference for future similar changes.

Emergency Changes: The Expedited Path

Emergency changes are the litmus test for a functioning change management process. They show whether the process works under pressure when there is no time for a regular CAB meeting.

When Is a Change an Emergency?

An emergency change exists when one of the following conditions is met:

• A security incident is active and requires immediate action
• A critical vulnerability is being actively exploited and a patch must be applied immediately
• A business-critical system has failed and restoration requires deviation from the standard configuration
• A regulatory violation must be remedied immediately

The IT manager or the ISO decides whether a change is classified as an emergency. This decision should not be taken lightly, as emergency changes bypass important controls.

Expedited Process

For an emergency change, the formal CAB approval before implementation is waived. Instead:

1. Telephone or chat approval by the IT manager or the ISO. If unreachable, the on-call administrator decides but documents the failed contact attempts.
2. Implementation with real-time logging of all steps (logbook, ticket, chat log).
3. Immediate notification of the CAB and affected business units after implementation.
4. Retroactive documentation within 24 to 48 hours: complete change request with risk assessment, justification for urgency and implementation log.
5. Retroactive assessment at the next CAB meeting: Was the emergency classification justified? Was the response correct? Is there room for improvement?

Preventing Misuse

A common problem: when emergency changes are easier to push through than normal changes, they are used excessively. Teams bypass the regular process by declaring changes as urgent even when they are not. You can counter this in two ways:

First, through regular evaluation of the emergency change rate. If more than 10 to 15 percent of all changes are classified as emergencies, something is wrong. Either the regular process is too slow and needs to be accelerated, or teams are misusing the emergency category.

Second, through consistent retroactive assessment. Every emergency change is reviewed in the CAB. If the urgency turns out not to have been warranted, this is documented and discussed with the team.

Connection to Vulnerability and Patch Management

Change management and patch management are closely intertwined. Every patch is a change to a system and must be treated as such. At the same time, structured vulnerability management frequently creates the occasion for changes.

Patch Management as a Change Process

Regular security patches should be defined as standard changes. This means: the patch cycle is pre-approved, the procedure is documented, the risks are known and assessed as low. Patches are applied according to the defined cycle (e.g., monthly on Patch Tuesday plus 7 days for testing) without a change request being submitted for each individual patch.

Exceptions: patches that go beyond a simple security fix (feature changes, major updates) are treated as normal changes. Critical out-of-band patches for actively exploited vulnerabilities are applied as emergency changes.

Vulnerability Management as a Change Driver

When a vulnerability scan or a penetration test identifies security gaps, this typically generates changes: configuration changes, system hardening, software updates or architecture modifications. These changes go through the regular process but are prioritized based on the criticality of the vulnerability.

The connection in practice looks like this:

1. Vulnerability scan identifies vulnerability X with CVSS score 8.5 (high).
2. IT creates a change request to remediate the vulnerability.
3. CAB assesses the change and considers the criticality of the vulnerability in prioritization.
4. Change is implemented.
5. Follow-up vulnerability scan confirms that the vulnerability has been remediated.
6. PIR documents the entire process.

Linking Documentation

In the ISMS, the change log, vulnerability register and patch status should be linked to each other. In ISMS Lite, changes, risk assessments and approvals can be documented centrally and linked to the associated vulnerabilities. When an auditor asks how a specific vulnerability was handled, you must be able to demonstrate the path from detection through risk assessment and change request to confirmation of remediation without gaps.

Practical Example: Change Management in an 80-Employee Company

A mid-market mechanical engineering company with 80 employees, 3 of whom are in-house IT, introduces change management as follows:

CAB: IT manager, ISO (in dual role with the quality manager), production manager. Weekly meeting on Tuesday afternoon, 30 minutes. In case of absence, votes are cast by email.

Standard changes: Monthly Windows updates, user management (create, modify, lock), printer configuration, routine maintenance of production plant IT (per maintenance schedule). The list of standard changes is reviewed annually by the CAB and updated as needed.

Normal changes: Everything beyond standard changes. Recent examples: introduction of a new MES interface for ERP integration, migration of the file server to a new virtualization environment, VPN solution transition.

Emergency changes: Rare but have occurred: immediate lockout of a compromised admin account, emergency patch for a critical Exchange vulnerability over the weekend.

Documentation: Change requests and change log are maintained in a simple ticketing system. Each change request uses a form template with mandatory fields. The PIR is a brief comment in the ticket answering the five PIR questions.

KPIs: The CAB evaluates quarterly: total number of changes, broken down by standard/normal/emergency, number of failed changes, average lead time of normal changes. These ISMS KPIs feed into the management review.

Tips for Implementation

If you do not yet have formal change management, do not start with a 50-page process manual. Start small and build up:

Month 1: Define the three change types and create a simple change request form. Determine who sits on the CAB and when the first meeting takes place. Begin documenting all changes to production systems, even if assessment and approval are still informal.

Months 2-3: Establish the weekly CAB rhythm. Introduce risk assessment for normal changes. Create the first list of standard changes. Define the emergency change process.

Months 4-6: Introduce the post-implementation review. Begin linking change management and vulnerability management. Create rollback plan templates. Define KPIs and evaluate them for the first time.

From month 7: Optimize the process based on the experience of the first months. Automate where possible (e.g., automatic reminders for PIR, dashboard for change KPIs). Expand the standard change list. Review whether the process also works for business units or whether it is perceived as a purely IT topic.

The key to success lies not in the perfection of the process but in consistent application. A simple process that is consistently followed is worth more in an audit than a comprehensive process that is regularly bypassed.

Further Reading

• Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees
• Patch Management for SMEs: Closing Vulnerabilities Before They Cause Damage
• Risk Assessment in the ISMS: From Identification to Risk Analysis
• Detecting, Reporting and Responding to Security Incidents
• Conducting an Internal ISMS Audit: Planning, Checklist and Report

Changes to IT systems will never stop. New requirements, security updates and technological advances ensure that infrastructure is continuously evolving. Change management gives this evolution a structure that ensures every change is carried out consciously, planned and traceably. This not only protects against preventable outages but also provides the auditor with evidence that your ISMS works in day-to-day operations.