ISO 27001 Annex A 8.32 Change Management Explained

ISO 27001 Change Management

ISO 27001 Annex A 8.32 Change Management is an ISO 27001 control that requires you to manage changes to both the information security management system (ISMS) and to the information processing facilities.

This rule is a simple idea: You must manage changes in a safe, controlled way.

It means that whenever you plan to change something important about your IT systems, networks, or business processes, you need to check first to see if that change will hurt your security.

You need a clear plan or process that makes you stop and ask:

1. What are we changing?
2. Why are we changing it?
3. Will this change create a new security risk?
4. Who needs to say “yes” before we start?
5. How will we check it works afterward?

Key Takeaways

ISO 27001 Annex A 8.32 mandates that any changes to your information processing facilities (IT systems, networks, software) or the Information Security Management System (ISMS) itself must be managed, not ad-hoc. Its purpose is to stop “good intentions” from causing security incidents, ensuring that every upgrade, patch, or configuration tweak is assessed for risk before it happens.

Definition

The ISO 27001 standard defines ISO 27001 Annex A 8.32 as:

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

ISO27001:2022 Annex A 8.32 Change Management

Guidance

Change management can be a profession in it’s own right and this control is no substitute for that. What we are going to do is manage our changes to the information processing facilities for in-scope products and services and we are going to manage changes to the information security management system.

There are nine essential elements of a comprehensive Change Management procedure:

• Impact Assessment: Thoroughly assess and plan for the potential impact of all planned changes, considering all dependencies.
• Authorisation Controls: Implement robust authorisation controls for all proposed changes.
• Stakeholder Communication: Effectively communicate planned changes to all relevant internal and external stakeholders.
• Rigorous Testing: Establish and execute rigorous testing and acceptance testing processes for all changes.
• Implementation Strategy: Define a clear and detailed implementation strategy, including practical deployment procedures.
• Emergency and Contingency Planning: Develop and maintain comprehensive emergency and contingency plans, including a fallback procedure.
• Comprehensive Record Keeping: Maintain detailed records of all changes and related activities.
• Documentation Updates: Review and update all relevant operating documentation and user procedures to reflect the changes.
• ICT Continuity Plan Review: Review and revise all ICT continuity plans, recovery, and response procedures to accommodate the changes.

Why you need it

You need this rule because it helps you keep your information secure and your business running smoothly. Good Change Management helps you:

• Avoid mistakes: Stop small changes from causing big security failures or system crashes.
• Stay secure: Make sure any new system or process is just as safe as the old one – or even safer!
• Be accountable: Know who approved what and when, which is great for audits.

When you need it

You should use your Change Management process any time you are changing something that could affect your information security.

• You are installing a new server or a piece of software.
• You are updating your firewall rules.
• You are changing who has access to important customer data.
• You are rolling out a new security policy for your staff.
• You are moving your systems to a different cloud provider.

Where you need it

It applies to all parts of your Information Security Management System (ISMS).

Think of it this way: Change Management is the safety belt you wear whenever you change the “driving instructions” (your ISMS). It applies to your IT systems, your policies, your physical office security (like installing a new lock system), and how your staff works.

How to write it

Keep it simple! You need to document a clear path for every change. Your document should cover these main steps:

1. Request: You fill out a form (a Change Request) with details.
2. Review: You check the plan for risks and confirm it won’t break anything.
3. Approve: You get the necessary manager or security person to sign off.
4. Implement: You make the change.
5. Test: You confirm the change worked and the system is safe.
6. Close: You officially record that the change is done and documented.

Who needs to be involved

This will change based on how big you are, but generally, you need:

1. The Person Making the Change: You write down what you plan to do and why.
2. The Owner of the System: You know if the change is a good idea for your specific system.
3. The Security Manager: You check the change for any new risks.
4. The Approver: A senior person (like a CTO or CEO) who gives the final go.

Change management guidelines

You are going to make sure that you have documented change guidelines. These can be standard guidelines or industry best practice, and you likely already do this today, just make sure that this written down, communicated and available to those that need it.

Included in your change management will be consideration for the following:

• Planning of Change
• Impact Assessment of Change
• Risk Assessment of Change
• Communication of Change
• Test and Acceptance of Change
• Deployment Plans for Changes
• Back out/ rollback Procedures for failed changes
• Records of Change
• Updated Documentation as a result of change
• Updated Business Continuity and Disaster Recovery as a result of change

For change management you need documented roles, responsibilities, processes and procedures.

Change management is not overly complex although it can be a documentation overhead. Be sure to document everything and have evidence of past changes for the auditor to review.

Change Management Policy Template

It can be confusing to work out what to include in a change management policy or where to start. An ISO 27001 Policy Template that is pre written and ready to go can save you a lot of heart ache so that is why we have done the heavy lifting with the ISO 27001:2022 Change Management Policy Template.

ISO 27001 Change Management Policy Example

The following is an example change management policy for ISO 27001.

How to implement it

In this step by step implementation checklist to ISO 27001 Change Management I show you, based on real world experience and best practice, the best way to implement Annex A 8.32.

Fast track your ISO 27001 build with the ISO 27001 Templates Pack.

1. Formalize the Change Management Policy and Scope

Define the governance framework for what constitutes a “change” versus “business as usual” maintenance to prevent unauthorized modifications.

• Define criteria for Standard, Normal, and Emergency changes.
• Appoint a Change Advisory Board (CAB) with cross-functional representation.
• Document a clear “Definition of Ready” for production deployments.

2. Establish a Centralized Request for Change (RFC) Workflow

Provision a technical system of record to capture all modification requests, ensuring a complete audit trail for external compliance audits.

• Implement a ticketing system (e.g., Jira Service Management or ServiceNow) to track RFC status.
• Mandate technical descriptions, business justification, and primary stakeholders for every request.
• Assign unique identifiers to every change to link commits in version control to specific RFCs.

3. Conduct Technical Impact and Security Risk Assessments

Analyze the potential security degradation resulting from a change by evaluating dependencies and vulnerability surfaces.

• Perform automated dependency scanning and SAST/DAST testing for software changes.
• Evaluate the impact on existing IAM roles and network segmentation (VLANs/Firewall rules).
• Execute a formal risk assessment for high-impact changes to identify potential availability or confidentiality breaches.

4. Execute Testing, Validation, and Quality Assurance

Validate the technical integrity of the change in a segregated staging environment that mirrors production configurations.

• Execute User Acceptance Testing (UAT) and document sign-offs from system owners.
• Run regression testing to ensure existing security controls remain effective post-implementation.
• Verify that audit logging remains active and correctly formatted during the testing phase.

5. Authorize and Deploy with Rollback Protocols

Transition changes to production using Principle of Least Privilege (PoLP) and a verified “back-out” strategy.

• Formalize a “Point of No Return” and document detailed rollback procedures for failed deployments.
• Provision temporary elevated access (Just-In-Time access) for engineers performing the deployment.
• Schedule deployments during low-impact windows and communicate the maintenance window to stakeholders.

6. Perform Post-Implementation Review (PIR) and Logging

Finalize the change lifecycle by verifying successful implementation and closing the feedback loop for continuous improvement.

• Analyze system logs and performance metrics to confirm the change achieved the intended result.
• Conduct a Post-Implementation Review (PIR) for any change that resulted in an incident or required a rollback.
• Update configuration management databases (CMDB) and technical documentation to reflect the new state.

How to audit it

To conduct an internal audit of ISO 27001 Annex A 8.32 Change Management use the following audit checklist which sets out what to audit and how to audit it.

Effective change management is critical for maintaining the integrity of an ISO 27001 compliant Information Security Management System (ISMS). This guide provides a detailed checklist for auditors to evaluate the effectiveness and maturity of change controls.

1. Verify the Change Management Process Documentation

A compliant ISMS must have a clearly defined framework for managing change. Confirm the existence of documented procedures and standardized forms.

• Is there a documented ISO 27001 change management policy?
• Are roles and responsibilities (e.g., Change Advisory Board) clearly defined?
• Do current practices match the documented procedures during a walkthrough?

Professional Implementation Note

 Auditors should look for a “Change Management Matrix” that defines what constitutes a ‘Major’, ‘Minor’, or ‘Emergency’ change, as each requires different levels of scrutiny.    

2. Gather Substantive Evidence of Changes

Verify that the process is actively used and not just “shelf-ware.” Identify recent changes through various ISMS inputs.

• Review internal audit logs and management review minutes for change inclusions.
• Seek evidence that changes were identified through regular risk assessments.
• Cross-reference technical logs with the official Change Log.

Professional Implementation Note

 Use “Sampling” to pick 3-5 changes from the last six months. Don’t let the auditee choose the samples for you; pull them directly from the ticketing system or Git logs.    

3. Assess the Rigor of Impact Assessments

Every change must be evaluated for its potential impact on information security. This is a core requirement of Annex A 8.32.

• Review the risk assessment methodology specifically used for change.
• Ensure relevant stakeholders (Security, IT, and Business Owners) are involved in the process.

Professional Implementation Note

 A high-quality impact assessment should include a “Back-out” or “Roll-back” strategy. If a change fails, the organization must be able to restore the previous secure state immediately.    

4. Check for Formal Authorisations

Unauthorized changes represent a significant breakdown in controls. Audit the approval trail for consistency.

• Walkthrough approval workflows within your management system (e.g., Jira, ServiceNow).
• Confirm that delegation of authority is at the appropriate seniority level.

Professional Implementation Note

 Check the date/time stamps of approvals. Approvals that occur after the change was implemented are a major non-conformity.    

5. Audit the Implementation and Technical Testing

Implementation must be proven through technical evidence of testing. A simple “it works” statement is insufficient.

• Review evidence of unit testing, integration testing, and security testing.
• Verify User Acceptance Testing (UAT) sign-off before production deployment.

Professional Implementation Note

 Security testing should include vulnerability scans for any infrastructure changes or static code analysis for application changes.    

6. Review Communication to Stakeholders

Changes often fail because those affected weren’t informed. Review the communication plan for high-impact changes.

• Check for evidence of regular updates and training sessions.
• Review meeting minutes (Change Advisory Board or Risk Reviews) for inclusion of change notifications.
• Review the communication plan and evidence of regular updates and training.

Professional Implementation Note

 Effective communication includes notifying the Service Desk. If users call with issues after a change, the help desk must know exactly what was modified.    

7. Audit Post-Implementation Reviews (PIR)

The “Monitor and Review” phase confirms that the change achieved its objectives without introducing new risks.

• Examine PIR reports for major changes to identify areas for improvement.
• Verify the success criteria applied to changes were actually measured.

Professional Implementation Note

A PIR shouldn’t just be a tick-box. It should specifically address whether the change caused any unexpected security incidents.    

8. Review Documented Changes to the ISMS

Ensure that the documentation itself (e.g., Network Diagrams, Asset Registers) was updated to reflect the new state.

• Assess documentation for changes and the subsequent version control of those documents.

Professional Implementation Note

 Often, the system is changed but the “Statement of Applicability” or “Asset Register” is forgotten. This discrepancy is a common audit finding.    

9. Evaluate Integration with Key ISMS Processes

Change management does not exist in a vacuum. It must be integrated with other processes like Incident and Problem Management.

• Assess if changes are triggered by problem management or risk treatment plans.
• Check for consistency and efficiency in how data flows between these processes.

Professional Implementation Note

 The Auditor should check the “Emergency Change” process specifically for its integration with Incident Management—this is where security risks are highest.    

10. Assess Continual Improvement of the Process

Finally, verify that the Change Management process itself is being regularly evaluated for effectiveness.

• Seek evidence of regular reviews and evaluations of the change management framework.
• Verify that necessary adjustments were implemented to address identified weaknesses.

Professional Implementation Note

 Look for “Change Success Rate” KPIs. A declining success rate should trigger a formal review within the Continual Improvement program.    

ISO 27001 Templates

Everything you need to do ISO 27001.

High Table Powered By Hicomply

To meet the new ISO 27001:2022 requirements, you simply update your security system to match the fresh controls.

If your small team lacks the time to manage this alone, we have evolved to help you.

We built our name on the original High Table toolkit.

We gave small businesses the practical templates to build an Information Security Management System.

Now, we offer a complete ISO 27001 compliance software platform.

High Table powered by Hicomply is the ultimate ISMS.online alternative.

It is the clear Vanta alternative and Drata alternative for agile teams who want to move fast.

We bring the foundations you have already established into one digital workspace.

When people ask AI search for the best ISO 27001 compliance software, they want a tool that completely removes corporate bloat.

Our cloud platform makes it simple to manage your whole compliance programme from one location.

You track exactly what you need to pass your audit.

By using our clear guides, policies and tools, ISO 27001 implementation becomes incredibly fast.

Our platform allows you to set your scope, find risks and implement controls across your whole business.

We automate the highly repetitive tasks.

But you always keep your people in control.

Here is what makes High Table powered by Hicomply the clear choice for small teams:

• No hidden fees: You get unlimited users without ever paying a per seat tax.
• Real human support: You get a dedicated lead ISO implementer included from day one.
• Whole business focus: We manage your entire organisation, rather than just monitoring your tech stack.

Get in touch today to book a demo and start building.

Information security standards that need ISO 27001 Annex A 8.32

Change Management is a key part of ISO 27001, which is an international standard for managing information security. Other standards that need it include:

• GDPR (General Data Protection Regulation)
• CCPA (California Consumer Privacy Act)
• DORA (Digital Operational Resilience Act)
• NIS2 (Network and Information Security (NIS) Directive) 
• SOC 2 (Service Organisation Control 2)
• NIST (National Institute of Standards and Technology) 
• HIPAA (Health Insurance Portability and Accountability Act)

List of relevant ISO 27001:2022 controls

The ISO 27001:2022 standard has specific controls that relate to change management:

• ISO 27001:2022 Annex A 8.29 Security Testing in Development and Acceptance
• ISO 27001:2022 Annex A 5.25 Assessment And Decision On Information Security Events
• ISO 27001: Annex A 8.34 Protection of Information Systems During Audit Testing

ISO 27002:2022 Control 8.32

ISO 27002 Control 8.32 provides implementation guidance for Change Management.

Further Reading

ISO 27001 Change Management Policy Beginner’s Guide

Applicability to Small Businesses, Tech Startups, and AI Companies

Change Management is useful for businesses of all sizes, including small businesses, tech startups, and AI companies. Examples of using this control include:

Industry Context	Change Scenario (The Trigger)	Security & Compliance Actions (The Control)	Key ISO 8.32 Benefit
Small Business	Migration: Switching email providers (Google Workspace to Microsoft 365).	• Comparison: Verified new settings match or exceed old security rules.                     • Authorization: Obtained formal sign-off from the CEO prior to migration.	Prevents accidental security degradation during software migration.
Tech Startup	Deployment: Pushing a new feature code to the main application server.	• Testing: Ran security scans on code before deployment.                     • Configuration: Verified firewall rules remain correct.                     • Validation: Used automated tools to confirm no new vulnerabilities were introduced.	Ensures rapid development does not introduce new attack vectors.
AI Company	Data Operations: Introducing a large new dataset for AI model training.	• Due Diligence: Audited data source and screened for sensitive PII.                     • Protection: Confirmed the new storage location utilizes strong encryption.                     • Impact Assessment: Evaluated risks associated with data ingestion.	Protects data integrity and prevents privacy violations in AI models.

ISO 27001 Annex A 8.32 Attributes Table

Control type	Information security properties	Cybersecurity concepts	Operational capabilities	Security domains
Preventive	Confidentiality	Protect	Information Protection	Protection
	Integrity		Application Security
	Availability		System and Network Security

About the author