ISMS Change Plan Template (ISO/IEC 27001 Clause 6.3)

Planned ISMS changes: classification, lifecycle, change record, integrity checklist by clause, typical changes, CB notification, register, review

ISMS 与 ISO/IEC 27001完整ISO/IEC 27001:2022 + Amd 1:2024 clauses 6.3, 8.1, A.8.32 (cited only); ISO/IEC 27006-1:2024change plan更新于 2026年11月1日

在编辑器中打开下载 .md

使用方法: Use it when a decision would change the ISMS itself: a new site, scope extension, cloud migration, reorganisation or acquisition. Fill the classification criteria first, then open one change record per change before work starts. The main pitfall is writing the record after the change, when clause 6.3 asks for planning.

预览

ISMS Change Plan: [Organization name]

Plan and record for changes to the information security management system (ISMS) itself: a new site, a scope extension, a cloud migration, a reorganisation, an acquisition or a new regulatory obligation. It supports ISO/IEC 27001:2022 + Amd 1:2024 clause 6.3 (planning of changes, new in the 2022 edition) and connects it to clause 8.1 (controlling planned changes in operation) and Annex A control A.8.32 (change management for information processing facilities). Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	DOC-ISMS-025
Version	[1.0]
Status	[Draft / In review / Approved / Superseded]
Owner	[@isms-manager]
Approvers/reviewers	[@ciso], [@coo], [@isms-steering-committee]
Last updated	YYYY-MM-DD
Classification	[Internal]
Standard and edition	ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.3, 8.1; Annex A A.8.32)
Next scheduled review	YYYY-MM-DD
ISMS scope reference	DOC-ISMS-002 (ISMS scope)
Approving body for major changes	[ISMS steering committee, DOC-ISMS-007]
Certification body notification owner	[@isms-manager]

Approvals

Role	Name	Decision	Date
ISMS manager	[@isms-manager]	[Prepared]	YYYY-MM-DD
ISMS steering committee chair	[@coo]	[Approved / Approved with changes]	YYYY-MM-DD
Top management	[@ceo]	[Approved]	YYYY-MM-DD

Revision history

Version	Date	Author	Change
1.0 (Example)	YYYY-MM-DD	[@isms-manager]	First issue: classification criteria, lifecycle, register
1.1 (Example)	YYYY-MM-DD	[@isms-manager]	Added acquisition checklist after management review action MR-2027-04
[x.y]	YYYY-MM-DD	[@author]	[Change summary]

1. Purpose and scope
2. What counts as an ISMS change
3. Change classification
4. Change lifecycle
5. Change record
6. ISMS integrity assessment
7. Typical ISMS changes
8. Certification body and interested parties
9. ISMS change register
10. Post-implementation review
11. Size tiers
12. Records and evidence
13. References
Standard and licence note

1. Purpose and scope

Clause 6.3 of ISO/IEC 27001:2022 is about not changing the ISMS by accident: a reorganisation, a new site or a migration should be thought through before it happens. This document sets out how [Organization name] recognises such a change, assesses its effect on the management system, decides, implements and reviews it, and keeps a record of each step.

The plan applies to every change that affects the ISMS scope, its context, its leadership and roles, its risk assessment and treatment, its policies and controls, its resources or its documented information. It applies whoever starts the change: top management, a project team, a business unit, a regulator's demand or a customer contract.

Item	Value
In scope	[All changes to the ISMS as defined in DOC-ISMS-002]
Out of scope	[Routine technical changes handled under the operational change process, unless they meet the criteria in section 3]
Linked processes	[Operational change management (A.8.32), project management (A.5.8), risk assessment (6.1.2, 8.2), management review (9.3)]
Who may raise an ISMS change	[Any manager, project sponsor, control owner, the ISMS manager, internal audit]
Who decides	[Per section 3: ISMS manager, steering committee or top management]

2. What counts as an ISMS change

An ISMS change alters the management system rather than a single system or service inside it. Use the test below; one "yes" makes it an ISMS change.

Question	Yes means ISMS change	Example
Does it move the scope boundary (locations, organisational units, services, technology)?	Scope statement update needed	A new office joins the scope
Does it change accountability for the ISMS or for risk ownership?	Roles and RACI update needed	The CISO now reports to the COO instead of the CTO
Does it introduce or remove a significant risk source?	Risk reassessment needed	Moving production from a colocation suite to a public cloud
Does it change whether an Annex A control is applicable or how it is implemented?	SoA update needed	Outsourcing the security operations centre
Does it change a top-level or topic-specific policy?	Policy approval needed	A new remote working model
Does it bring a new legal, regulatory or contractual obligation?	Legal register update needed	Becoming an essential entity under NIS2
Does it change the resources the ISMS depends on?	Resource plan update needed	The part-time ISMS manager role becomes full time
Does it affect the certificate (scope wording, sites, headcount)?	Certification body notification needed	An acquisition adds 200 people to a certified site

2.1 How ISMS changes relate to other change processes

An ISMS change often creates several operational changes (for example a cloud migration creates dozens of change requests). Keep one ISMS change record and link the operational change IDs to it, so the planning at management-system level stays visible.

3. Change classification

Class	Criteria (any one applies)	Decision authority	Minimum planning
Minor	Document wording, a role holder replaced by a trained successor, a control implementation detail with no SoA change	ISMS manager	Change record, document update, communication to affected owners
Significant	A new or retired control, a policy change, a new critical supplier, a change in risk owner, a High risk created or removed	ISMS steering committee	Change record, risk reassessment of affected scenarios, SoA review, plan with dates and owners
Major	Scope change, new or closed site, merger, acquisition or divestment, change of ISMS leadership structure, cloud or data centre migration, new regulatory regime	Top management on steering committee recommendation	Full change record, integrity assessment (section 6), resource approval, communication plan, certification body notification check, post-implementation review

Rules:

When in doubt, classify one level higher.
A change that creates a Critical risk (score 17 to 25, in practice 20 and 25, on the 5 x 5 scale in DOC-ISMS-010) is Major, because a Critical risk can only be retained untreated by a documented top management decision (DOC-ISMS-015).
Emergency changes (for example a site closure after a disaster) may start before approval; the record is completed within [5] working days and reviewed at the next steering committee meeting.

4. Change lifecycle

Step	What happens	Output	Owner
1. Raise	The requester describes the change and its purpose	Draft change record	Requester
2. Classify	The ISMS manager applies section 3	Class and decision authority	ISMS manager
3. Assess	Integrity checklist (section 6), affected risks re-scored, affected controls listed	Completed assessment	ISMS manager with risk and control owners
4. Plan	Actions, owners, resources, dates, communication, fallback	Change plan section of the record	Change owner
5. Decide	The decision authority approves, rejects or asks for rework	Dated decision with conditions	Decision authority
6. Implement	Actions carried out; linked operational changes raised	Action status, linked change IDs	Change owner
7. Update	Scope, SoA, risk register, policies, RACI, register of documents updated	New document versions	Document owners
8. Review	Planned results compared with actual; side effects found	Review entry (section 10)	ISMS manager

5. Change record

Field	Content
Change ID	ISMS-CHG-NNN
Title	[Short name]
Requester and date raised	[@requester], YYYY-MM-DD
Change owner	[@owner, a manager with authority to act]
Class	[Minor / Significant / Major]
Description	[What changes, in plain words]
Purpose and expected benefit	[Why the change is needed, the business or compliance driver]
Potential consequences	[Effects on information security, on customers, on operations, including what happens if the change is not made]
ISMS integrity assessment	[Reference to the section 6 checklist and its result]
Risks affected	[Risk IDs from DOC-ISMS-016, before and after scores]
Controls affected	[Annex A and additional controls, SoA rows to change]
Resources	[People, budget, tools, external support, with approval reference]
Responsibilities	[Who does what; RACI changes in DOC-ISMS-006]
Timing and milestones	[Start, key milestones, completion, freeze periods such as an audit window]
Communication	[Audiences and messages, reference to DOC-ISMS-027]
Fallback	[How to stop or reverse the change and keep the ISMS working]
Certification body notification	[Required yes or no, date sent, reference]
Decision	[Approved / Rejected / Deferred], by [@authority], YYYY-MM-DD, conditions
Linked operational changes	[Change request IDs]
Post-implementation review	[Date, result, reference]
Status	[Raised / Assessing / Awaiting decision / Approved / In progress / In review / Closed / Rejected]

5.1 Worked record: cloud migration (Example)

Field	Content
Change ID	ISMS-CHG-007 (Example)
Title	Move the scheduling platform from the colocation suite to a public cloud
Requester and date raised	[@cto], 2027-01-11
Change owner	[@head-of-infrastructure]
Class	Major (technology boundary of the scope changes, new critical supplier)
Description	Quillmere Health Systems moves its clinical scheduling platform from its colocation suite to one public cloud provider in two regions. The colocation contract ends after a parallel run.
Purpose and expected benefit	Retire ageing hardware, gain regional failover, shorten recovery time for the managed service
Potential consequences	Shared responsibility model replaces direct physical control; A.7 physical controls for the suite become supplier-assured; new identity and key management design; hospital contracts may require notification of a new subprocessor; if not done, hardware end of support in 2028
ISMS integrity assessment	Completed 2027-01-25; 9 of 12 checklist areas affected (section 6)
Risks affected	RISK-014 cloud misconfiguration created at 4 x 4 = 16 (High), target 2 x 4 = 8 (Medium); RISK-009 hardware failure in the suite reduced from 3 x 4 = 12 (High) to retired after exit
Controls affected	A.5.23 cloud service use (new implementation), A.5.19 to A.5.22 supplier controls for the provider, A.8.13 backup redesign, A.8.24 key management, A.7.x rows rejustified for the exited suite
Resources	2 cloud engineers for 6 months, external architecture review, budget approved in steering committee minute SC-2027-02
Responsibilities	Head of infrastructure (delivery), ISMS manager (documents and risk), privacy lead (subprocessor notices)
Timing and milestones	See the plan below; no cutover during the surveillance audit window
Communication	Hospitals notified at least 60 days before the planned cutover, as contracts require (Example); staff briefing; certification body informed
Fallback	Colocation suite kept running until 30 days after cutover
Certification body notification	Required (technology and location change in scope wording); sent 2027-02-05
Decision	Approved by top management, 2027-02-03, condition: external architecture review before cutover

6. ISMS integrity assessment

For each area, record whether the change affects it, what must be done and who owns the action. An area marked "affected" needs an action with a date before the change is closed.

Area	Clause	Question	Affected?	Action and owner
Context and interested parties	4.1, 4.2	Are there new internal or external issues, new interested parties or new requirements (including climate-related ones, as Amd 1:2024 asks you to consider)?	[Yes / No]	[Update DOC-ISMS-003]
Scope	4.3	Do boundaries, interfaces or dependencies change?	[Yes / No]	[Update DOC-ISMS-002]
Leadership and policy	5.1, 5.2	Does the information security policy still fit the purpose?	[Yes / No]	[Policy review DOC-ISMS-001]
Roles and authorities	5.3	Do accountabilities, reporting lines or risk owners change?	[Yes / No]	[Update DOC-ISMS-006]
Risk assessment	6.1.2, 8.2	Which scenarios are created, changed or retired?	[Yes / No]	[Reassess in DOC-ISMS-016]
Risk treatment and SoA	6.1.3, 8.3	Which controls change applicability or implementation?	[Yes / No]	[Update DOC-ISMS-013, DOC-ISMS-011]
Objectives	6.2	Do objectives or their targets need to change?	[Yes / No]	[Update DOC-ISMS-024]
Resources and competence	7.1, 7.2	Are new skills or more people needed?	[Yes / No]	[Update DOC-ISMS-026, DOC-ISMS-031]
Awareness and communication	7.3, 7.4	Who must be told what, and when?	[Yes / No]	[Update DOC-ISMS-027]
Documented information	7.5	Which documents and records are created, changed or retired?	[Yes / No]	[Update DOC-ISMS-028]
Operation	8.1	Do outsourced processes or operational controls change?	[Yes / No]	[Update procedures and supplier records]
Performance evaluation	9.1, 9.2, 9.3	Do metrics, the audit programme or review inputs change?	[Yes / No]	[Update DOC-ISMS-080, DOC-ISMS-082]

7. Typical ISMS changes

Change type	Usual class	Main ISMS effects	Points that are often missed
New site or office	Significant or Major	Scope, physical controls (A.7), local legal requirements, asset inventory, access rights	Visitor management, local emergency contacts, multi-site sampling by the certification body
Scope extension (new service, unit or country)	Major	Scope statement, risk assessment, SoA, audit programme, certificate wording	Interfaces with out-of-scope parts, competence of the new unit, internal audit before the certification body visit
Cloud migration	Major	Supplier controls, A.5.23, shared responsibility, backup, logging, keys, exit planning	Updating physical control justifications, customer subprocessor notices, disposal of old equipment (A.7.14)
Reorganisation	Significant or Major	Roles and RACI, risk ownership, segregation of duties, access rights	Orphaned risks and controls when a manager leaves, policy owners who no longer exist
Acquisition or merger	Major	Context, scope, legal register, integration of controls, supplier inventory, incident handling	Inherited incidents and vulnerabilities, different classification schemes, transition period before integration
Divestment or site closure	Major	Scope reduction, asset return and disposal, access removal, record retention	Records that must outlive the closure, transitional service agreements
Outsourcing a security function	Significant	Supplier controls, monitoring, incident interfaces, competence retained in house	Right to audit, log access, exit plan
New regulation (for example NIS2 or DORA in scope)	Significant or Major	Legal register, incident reporting timelines, governance duties, supplier contracts	Management body training duties, reporting contacts
Change of ISMS manager	Minor or Significant	Roles, handover of open actions, certification body contact	Access to the document system, audit schedule ownership

7.1 Acquisition checklist (Example)

Before signing: security due diligence on the target (incidents, certifications, open audit findings, regulatory exposure).
Day one: who handles incidents at the target, emergency contacts, privileged access inventory.
First 90 days: risk assessment of the target, decision whether it joins the ISMS scope now or later, interim controls for connections.
Integration: classification scheme, policies, access management, supplier contracts aligned; scope extension raised as its own change.
Certification: certification body informed; scope extension audited before the certificate covers the acquired entity.

8. Certification body and interested parties

Inform the certification body when a change may affect the ability of the ISMS to keep meeting the standard or the accuracy of the certificate. Typical triggers, to be checked against your certification agreement:

changes to the legal status, ownership or name of the organisation;
changes to the scope, the sites or the activities covered;
significant changes to headcount, organisation or key management;
major changes to the ISMS or to critical processes and technology;
a major incident or regulatory action that questions the ISMS.

The certification body decides whether a special audit, a scope extension audit or a change to the audit time is needed (it sets audit time under ISO/IEC 27006-1:2024). Record the notification date, the reply and any resulting audit in the change record.

Other interested parties to consider: customers with contractual notification clauses (for example subprocessor changes), regulators, insurers, and staff representatives where consultation is required. Use the communication plan (DOC-ISMS-027) to plan these messages.

9. ISMS change register

Change ID	Title	Class	Raised	Decision	Status	CB notified	PIR done
ISMS-CHG-001 (Example)	Part-time ISMS manager role confirmed for Quillmere Analytics	Minor	2027-01-05	Approved 2027-01-06	Closed	No	Yes
ISMS-CHG-002 (Example)	Remote working model extended to all staff	Significant	2027-01-07	Approved 2027-01-21	Closed	No	Yes
ISMS-CHG-007 (Example)	Scheduling platform moved to public cloud	Major	2027-01-11	Approved 2027-02-03	In progress	Yes, 2027-02-05	No
ISMS-CHG-009 (Example)	Plant 2 joins the group ISMS scope	Major	2027-04-02	Approved 2027-04-20	In progress	Yes, 2027-04-22	No
ISMS-CHG-010 (Example)	SOC outsourced to a managed detection provider	Significant	2027-05-10	Deferred to Q4 budget	Deferred	No	No
[ISMS-CHG-NNN]	[title]	[class]	YYYY-MM-DD	[decision and date]	[status]	[Yes, date / No]	[Yes / No]

The example rows draw on all three fictional settings (Quillmere Analytics Ltd, Quillmere Health Systems, Quillmere Group) to show each class; a real register holds one organisation's changes.

10. Post-implementation review

Within [30] days after implementation (or after the first full operating cycle for Major changes), the ISMS manager and the change owner answer:

Question	Answer
Did the change achieve its stated purpose?	[Yes / Partly / No, with evidence]
Were all affected areas in section 6 updated?	[List of updated documents and versions]
Did residual risks reach their target scores?	[Risk IDs, actual vs target]
Were there unintended effects on security, operations or customers?	[Description and actions]
Were all communications sent and acknowledged?	[Reference to the communication log]
Does the certification body need further information?	[Yes / No]
Lessons for the next change of this type	[Lessons, added to section 7]

Unintended adverse effects are raised as nonconformities or improvements in DOC-ISMS-087 or DOC-ISMS-088. A summary of closed Significant and Major changes is an input to management review (DOC-ISMS-085), since changes in external and internal issues are a required review input.

11. Size tiers

Aspect	Small: Quillmere Analytics Ltd (46 staff)	Medium: Quillmere Health Systems (320 staff)	Large: Quillmere Group (2,400 staff, 6 sites)
Typical changes	New SaaS tools, a new cloud region, growth past a team size, a first enterprise customer contract	Cloud migration of the colocation suite, 27701 extension, new hospital contracts	Phased site onboarding, acquisitions, OT network changes, integration with ISO 9001 and ISO 22301 change processes
Who classifies	The part-time ISMS manager (0.5 FTE, Head of Engineering Operations)	The full-time ISMS manager	The CISO's security office, with site ISMS coordinators
Who decides Major changes	The managing director in the monthly leadership meeting	Top management on steering committee recommendation	Group executive committee; site directors for local Significant changes
Record format	One table per change in this document	Change records in the document system, linked to the operational change tool	Integrated management system change register shared with quality and continuity
Certification body contact	Before the 6-month certification target, confirm the scope wording if the product changes	Notify for the cloud migration and for the 27701 extension	Plan each site's scope extension with the certification body; multi-site sampling under ISO/IEC 27006-1 and IAF MD 1:2023, now re-issued by Global ACI as Global ACI-TECH-3-001 (check the current issue)
Frequency (Example)	3 to 6 ISMS changes a year	8 to 15 a year	20 or more a year, tracked as a portfolio

12. Records and evidence

Record	Proves	Owner	Location	Retention (Example)
ISMS change register (section 9)	Changes are identified and tracked	ISMS manager	[Document system path]	Life of the ISMS plus [3] years
Change records with decisions	Changes are planned and approved before implementation	Change owner	[Document system path]	[3] years after closure (one certification cycle)
Integrity assessments	The effect on the whole ISMS was considered	ISMS manager	Attached to the change record	Same as the change record
Updated scope, SoA, risk register versions	Documented information was kept current	Document owners	Document register DOC-ISMS-028	Per DOC-ISMS-028
Certification body notifications and replies	The certificate stays accurate	ISMS manager	[Certification folder]	Certificate cycle plus [3] years
Post-implementation reviews	Results and side effects were checked (8.1)	ISMS manager	Attached to the change record	Same as the change record
Management review input summary	Changes reach top management (9.3)	ISMS manager	DOC-ISMS-085	Per DOC-ISMS-028

Map these records to clause 6.3, clause 8.1 and control A.8.32 in the control evidence matrix (isms/control-evidence-matrix, DOC-ISMS-033).

13. References

Reference	Edition	Use
ISO/IEC 27001:2022 + Amd 1:2024	Current; Amd 1 published 2024-02-23	Clauses 4.1, 4.2, 6.3, 8.1, 9.3; Annex A A.5.8, A.8.32 (cited only)
ISO/IEC 27002:2022	Current	Guidance for A.8.32 change management
ISO/IEC 27003:2017	Current; a revision is in progress, check for a newer edition	ISMS implementation guidance
ISO/IEC 27006-1:2024	Current	Certification body audit time and multi-site rules
ISO/IEC 17021-1:2015	Current	Certification body obligations, special audits
IAF MD 1:2023, re-issued as Global ACI-TECH-3-001	Global ACI replaced IAF on 2026-01-01; TECH-3-001 v1.0 issued 2026-07-10, in force 2026-08-28; check the current issue on the Global ACI site	Multi-site certification sampling

Related templates: ISMS scope (compliance/ms-scope, DOC-ISMS-002), Scope extension and multi-site plan (isms/scope-extension-multisite-plan, DOC-ISMS-095), Change enablement policy (ops/change-enablement-policy), Change request (ops/change-request), Risk register (compliance/risk-register, DOC-ISMS-016), Statement of Applicability (compliance/statement-of-applicability, DOC-ISMS-011), Communication plan (isms/isms-communication-plan, DOC-ISMS-027), Documented information register (isms/isms-documented-information-register, DOC-ISMS-028), Cloud exit plan (isms/cloud-exit-plan, DOC-ISMS-076).

Official texts: ISO/IEC 27001:2022 https://www.iso.org/standard/82875.html, Amd 1:2024 https://www.iso.org/standard/88435.html, ISO/IEC 27002:2022 https://www.iso.org/standard/75652.html, ISO/IEC 27003:2017 https://www.iso.org/standard/63417.html, ISO/IEC 27006-1:2024 https://www.iso.org/standard/82908.html, ISO/IEC 17021-1:2015 https://www.iso.org/standard/61651.html.

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clauses 6.3 and 8.1, Annex A control A.8.32) and informed by ISO/IEC 27003:2017, ISO/IEC 27006-1:2024 and ISO/IEC 17021-1:2015. Clause and control numbers are cited with original short descriptions; the text, classification criteria, checklists and examples of this template are original, and no ISO/IEC text is reproduced. You need the official standards to implement and audit the requirements. Check the current editions before use: ISO/IEC 27003 is under revision. Quillmere organisations and all figures are fictional examples. Template licence: MIT.