How to Audit ISO 27001 Clause 6.3 Planning of Changes

Auditing ISO 27001 Clause 6.3 is a formal governance verification process that evaluates how organizational changes impact the management system. This audit satisfies the Primary Implementation Requirement of structured change planning, providing the Business Benefit of maintaining continuous security integrity and operational resilience during transitions.

Auditing Clause 6.3 requires a focus on the “Planning of Changes” within the ISMS. An auditor must verify that modifications to the system are not ad-hoc but follow a structured methodology that considers the purpose of the change and potential impacts on information security. This involves examining the intersection of change management, resource availability, and the reassignment of authorities.

1. Audit the Change Management Framework

Verify that the organisation has a formalised process for planning changes to the ISMS. This ensures that any modification to policies, scope, or controls is documented and reviewed before implementation.

• Inspect the ISMS Change Management Policy for specific planning requirements.
• Confirm that the “Purpose of Change” is documented for at least three recent modifications.
• Verify that changes are logged in a centralised register rather than in siloed department notes.

2. Evaluate ISMS Integrity Assessments

Assess how the organisation ensures the integrity of the ISMS is maintained during a change. This step prevents security gaps from appearing when shifting from one state to another, such as during a cloud migration or office relocation.

• Check for impact assessments that specifically mention “ISMS Integrity”.
• Verify that a rollback or contingency plan is defined for major system changes.
• Audit the link between change logs and the Risk Register to ensure new risks are identified.

3. Provision Resource Availability Evidence

Examine evidence that the organisation considers the availability of resources before committing to a change. A change without adequate funding, staff, or tools is a high-risk activity that can lead to control failure.

• Inspect budget approvals or resource allocation emails for significant project changes.
• Verify that the “Change Request” form includes a field for resource verification.
• Check that technical staff availability was considered in the project timeline.

4. Formalise the Reallocation of Responsibilities

Verify that authorities and responsibilities are formally reallocated during organisational changes. This prevents “orphaned” controls where no one is responsible for a security task after a restructure.

• Inspect the updated Responsibility Matrix or IAM role assignments post-change.
• Confirm that individuals affected by the change have formally acknowledged their new duties.
• Verify that the Asset Register has been updated to reflect new Asset Owners.

5. Audit Communication of Planned Changes

Review evidence that planned changes were communicated to relevant interested parties. This ensures that stakeholders, such as employees or service providers, are aware of their shifting obligations.

• Check internal newsletters, Slack announcements, or email logs regarding ISMS changes.
• Verify that third-party suppliers were notified if the change affected their Rules of Engagement (ROE).
• Inspect training logs to see if staff received briefing on new policy requirements.

6. Validate Management Sign-off for ISMS Modifications

Ensure that Top Management has reviewed and approved changes to the ISMS. This step confirms management commitment and prevents unauthorised alterations to the security framework.

• Inspect meeting minutes from the ISMS Steering Committee or Management Review.
• Verify that sign-off occurs before the implementation phase of the change.
• Confirm that the approver has the appropriate authority level as defined in Clause 5.3.

7. Inspect Post-Implementation Reviews

Check for evidence of post-implementation reviews to verify that the change achieved its purpose without compromising security. This provides proof of a “Plan-Do-Check-Act” (PDCA) approach to change management.

• Review the “Completion” section of change requests for outcome summaries.
• Check for incident logs that occurred immediately following a change.
• Verify that any unexpected security impacts were fed back into the Risk Management process.

8. Audit Technical Asset Tagging and Inventory Updates

Verify that the technical Asset Register is updated immediately following a change. This ensures that the organisation maintains visibility of its attack surface during and after transitions.

• Sample the Asset Register to confirm that new cloud instances or hardware are tagged.
• Verify that MFA was enforced on new user roles created during the change.
• Check that decommissioning records exist for assets removed during the change.

9. Review Legal and Regulatory Alignment

Confirm that the organisation assessed whether the planned change impacted its legal or regulatory compliance. This is vital for maintaining compliance with UK GDPR or industry-specific mandates.

• Inspect the “Compliance Check” field on the change request form.
• Verify if the Data Protection Officer (DPO) was consulted for changes involving PII.
• Check for updates to the Legal Register if the change involved a new jurisdiction.

10. Audit Training and Competence Records

Verify that staff affected by a change have been provided with the necessary training to maintain security. Competence must be reassessed when tools or processes evolve.

• Review training certificates for staff using new security software or hardware.
• Check that “Standard Operating Procedures” (SOPs) were updated and distributed.
• Verify that competence gaps identified during the change were addressed through a training plan.

ISO 27001 Clause 6.3 Audit Steps and Evidence

Table 1: Detailed Audit Steps, Execution Methods, and Evidence Examples for Clause 6.3

Audit Step	How To Execute	Common Examples of Evidence
1. Process Review	Examine the Change Management Policy for clauses specific to ISMS governance.	Documented ISMS Change Policy, Change Request (CR) templates.
2. Integrity Check	Ask the IT Manager how they ensure the firewall remains secure during a version upgrade.	UAT test results, firewall rule review logs, rollback procedures.
3. Resource Audit	Review a major change and check if the ISMS Manager had a dedicated budget.	Capital expenditure (CAPEX) approvals, project resource plans.
4. Authority Check	Trace a role change from HR to the IAM system to see who took over the security duties.	Updated IAM role matrix, Asset Owner field in the Asset Register.
5. Communication Log	Search for company-wide emails regarding changes to the Password Policy.	Slack channel announcements, all-hands meeting minutes.
6. Approval Verification	Check for the CISO’s signature on the last three “High Risk” changes.	Signed Change Board minutes, digital approvals in Jira/ServiceNow.
7. Post-Change Review	Examine a PIR document for a completed office move.	Post-Implementation Review (PIR) reports, incident report zero-results.
8. Asset Inventory	Verify if a newly purchased server appears on the inventory list within 24 hours.	CMDB logs, tagged AWS instances with ownership metadata.
9. Compliance Review	Check if the change form requires a “Privacy Impact Assessment” (PIA) checkbox.	DPIA documentation, updated Legal Register entries.
10. Training Audit	Interview a staff member on a new security tool to check their understanding.	LMS records, signed-off Standard Operating Procedures (SOPs).

Common SaaS and GRC Platform Audit Failures

Table 2: Why automated SaaS and GRC platforms often fail ISO 27001 Clause 6.3 audits

Failure Mode	The SaaS / GRC Platform Bias	Audit Consequence
Generic Workflows	Platforms provide a “Change” module that is not tailored to the organisation’s actual tech stack.	Non-conformity for failing to implement a process that reflects business reality.
Automated Approval Blindness	Systems auto-approve low-level changes without verifying if “ISMS Integrity” is at risk.	Major finding for lack of management oversight and risk assessment.
Resource Assumption	GRC tools track that a change happened but never verify if there was a budget or staff to support it.	Compliance failure as the auditor cannot verify resource planning (Clause 6.3c).
Siloed Change Data	Changes happen in Jira/ServiceNow but are never mirrored or assessed in the GRC tool.	Inability to prove that ISMS changes are managed in a centralised, planned way.
“Set and Forget” Roles	Software maps responsibilities once, but fails to trigger a review when people change jobs.	Orphaned security roles are identified during the audit interview.
Lack of Human Context	OCR/AI tools might log a change but cannot judge the “Purpose” (Clause 6.3a) of that change.	Auditor identifies a lack of strategic intent and professional judgement.
Implicit Integrity Gaps	Platforms assume that if a task is “Done,” the system is secure, ignoring the transition state.	Incident occurrences during the “change window” highlight a failure in integrity planning.
Disconnected HR Sync	Many GRC tools do not sync with HR, so authorities are reallocated in the tool but not in reality.	The “paper ISMS” does not match the actual organisational authority.
Compliance Over-Reliance	Staff assume the software’s change log is enough evidence, neglecting to document the plan.	A finding for “lack of planning” despite having a record of the result.
Proprietary Audit Trails	Change histories are trapped in a platform UI that is difficult to export for an external auditor.	Auditor frustration and potential delays in verifying the 3-year audit cycle.

About the author