Change management

Updated: 2026-02-17

Plain English Translation

Organizations must establish a formal procedure for managing changes to their IT systems, software, and infrastructure. This control ensures that every modification is properly requested, assessed for potential risks, thoroughly tested, and explicitly approved before being deployed into a production environment. By enforcing strict change management, organizations prevent unauthorized or faulty updates from causing unintended downtime, data loss, or security vulnerabilities.

Executive Takeaway

Formal change management procedures minimize the risk of operational disruptions and security breaches caused by unapproved or poorly tested system modifications.

ImpactHigh
ComplexityHigh

Why This Matters

  • Prevents self-inflicted outages by ensuring all changes undergo risk assessment, testing, and approval before impacting live customer environments.
  • Provides a clear audit trail of who made a change, why it was made, and who approved it, which is critical for incident investigation and regulatory compliance.

What “Good” Looks Like

  • All production changes require a documented Request for Change (RFC), peer review, and successful automated testing before deployment, with supporting evidence tracked in tools like WatchDog Security's Compliance Center.
  • Emergency changes follow an expedited but formalized approval path, ensuring critical patches can be deployed quickly without bypassing core security logging, with exceptions and follow-up actions tracked in tools like WatchDog Security's Risk Register.

ISO 27001 change management control 8.32 requires organizations to formalize how changes to information processing facilities and systems are handled. This IT change management process ensures that modifications are planned, tested, and approved to prevent outages or security issues.

An ISO 27001 change management procedure example typically includes steps for submitting an RFC, conducting risk assessments, performing QA testing, gaining formal approval, deploying the change, and executing a rollback plan if necessary. A comprehensive change management policy dictates these steps for all system modifications.

For change management audit evidence ISO 27001, auditors look for a documented change control procedure for IT systems, approved tickets for recent changes, code commit logs showing peer reviews, and records of acceptance testing confirming security requirements were met before release. Tools like WatchDog Security's Compliance Center can help map each change to A.8.32 and flag missing approvals, test artifacts, or rollback documentation. For auditor collaboration, WatchDog Security's Secure File Sharing can provide controlled, logged access to evidence packages.

Organizations evaluate the potential effect on confidentiality, integrity, and availability using a change management risk assessment template. This assessment determines the change's priority, the level of testing required, and whether a dedicated Change Advisory Board (CAB) review is necessary.

An RFC is a formal proposal for modifying a system. An effective RFC change request template should contain the change description, business justification, risk assessment, implementation plan, testing results, and a detailed rollback strategy if the deployment fails.

Yes, all modifications, including security patches and configuration updates, must follow the change management process. However, organizations often use pre-approved standard changes for routine updates to expedite the process without sacrificing oversight.

An emergency change process ISO 27001 allows for expedited approvals to address critical incidents quickly. Even if implemented rapidly, the change must be fully documented, logged, and retroactively reviewed by management to ensure it did not introduce new vulnerabilities.

A Change Advisory Board (CAB) is a cross-functional group of stakeholders responsible for evaluating high-risk or high-impact changes. A change approval workflow CAB is typically required when a proposed modification significantly impacts business operations, compliance boundaries, or core infrastructure.

For DevOps CI/CD change management compliance, organizations automate the change control steps. Approvals are often handled via peer code reviews, while automated SAST and DAST scanning satisfy the assessment and testing requirements before the pipeline automatically deploys the code. Tools like WatchDog Security's Compliance Center can track required change-control evidence (e.g., PR approvals and pipeline results) per release as audit-ready artifacts. WatchDog Security's Vulnerability Management can ingest scan findings to support the testing and risk assessment steps.

Change log and change record requirements dictate that evidence of approvals and testing must be retained according to the organization's data retention policy. Keeping these records for at least one year is standard practice to satisfy annual external audit reviews and support historical incident investigations.

Change management often fails during audits because approvals, test results, and rollout notes live in separate places. Tools like WatchDog Security's Compliance Center can map A.8.32 requirements to each change record and help collect and track the supporting evidence as an audit-ready package.

Policies drift when teams ship faster than documentation updates, creating gaps between “what we do” and “what we say we do.” WatchDog Security's Policy Management can support version control, review workflows, and acceptance tracking so procedure updates are documented and acknowledgement is measurable.

ISO-27001 A.8.32

"Changes to information processing facilities and information systems shall be subject to change management procedures."

VersionDateAuthorDescription
1.0.02026-02-17WatchDog Security GRC TeamInitial publication