Zum Hauptinhalt springen
CENEDRIL WIKI
DE
Annex A · Technological Control

A.8.32 — Change Management

Updated on 4 min Reviewed by: Cenedril Editorial
A.8.32 ISO 27001ISO 27002BSI OPS.1.1.3

A network engineer updates a firewall rule on Friday afternoon without documentation or testing. On Monday, the finance team reports that they cannot reach the banking portal. Nobody remembers the Friday change. The troubleshooting takes three hours. A.8.32 ensures that every change to information processing systems follows a documented, approved and reversible process.

Uncontrolled changes are among the leading causes of outages and security incidents. Change management creates a structured process that reduces risk while enabling necessary modifications to systems and infrastructure.

What does the standard require?

  • Plan changes. Document the change description, reason, scope and implementation plan.
  • Assess impact. Evaluate the potential security and operational impact of the change before approval.
  • Obtain approval. Changes require documented authorization from responsible parties.
  • Test before implementation. Verify the change in a non-production environment before deploying to production.
  • Prepare rollback procedures. Define how to reverse the change if it causes problems.
  • Communicate. Inform affected stakeholders about the change, timing and potential impact.
  • Document and review. Record the change details, implementation results and any issues encountered. Conduct post-implementation reviews.

In practice

Use a change management tool. Track all changes in a tool (ServiceNow, Jira Service Management, Freshservice or a simple ticketing system). Every change has a ticket with description, risk assessment, approval, implementation notes and review.

Integrate with CI/CD. For software deployments, the CI/CD pipeline itself can serve as the change management system: pull requests (description, review, approval), automated tests (pre-implementation testing), deployment logs (implementation record) and monitoring (post-implementation review).

Conduct change advisory board (CAB) meetings. For significant changes, convene a regular meeting to review upcoming changes, assess risks and coordinate timing. Keep meetings focused and time-boxed.

Review failed changes. When a change causes an incident, conduct a post-incident review. Identify whether the change process was followed, where it broke down and what can be improved.

Typical audit evidence

Auditors typically expect the following evidence for A.8.32:

  • Change management policy — documented process with roles and categories (see Configuration and Change Management Policy in the Starter Kit and Change Log)
  • Change records — tickets with description, assessment, approval and results
  • CAB meeting minutes — evidence of change review
  • Post-implementation reviews — evidence of review after significant changes
  • Emergency change records — expedited changes with retrospective documentation

KPI

Percentage of changes processed through formal change management with security review

Measured as a percentage: how many changes to production systems went through the formal change management process? Target: 100%.

Supplementary KPIs:

  • Number of incidents caused by changes (target: decreasing)
  • Percentage of changes with documented rollback plans
  • Number of emergency changes per quarter (trend analysis)

BSI IT-Grundschutz

A.8.32 maps to the BSI patch and change management module:

  • OPS.1.1.3 (Patch and Change Management) — the core module. Requires a documented change management process covering planning, approval, testing, implementation, documentation and review for all changes to IT systems.

Sources

Frequently asked questions

Does every change need formal approval?

All changes to production systems need documented approval. For standard, pre-approved change types (e.g., routine patches), the approval can be pre-authorized through a standing policy. Emergency changes may use an expedited process with post-hoc documentation.

What should a change record contain?

Description of the change, reason, risk assessment, affected systems, rollback plan, testing evidence, approver, implementation date and post-implementation review results.

How do we handle emergency changes?

Define a fast-track process: verbal approval from an authorized person, immediate implementation, documented retrospective within 24-48 hours. Emergency changes still need a record — the documentation comes after the fact.