Planning of changes
Plain English Translation
Clause 6.3 requires that any significant changes to the Information Security Management System (ISMS) be carried out in a deliberate, planned manner rather than ad-hoc. Whether you are introducing a new security policy, migrating to a new cloud provider, or restructuring the security team, you must assess the purpose, potential consequences, and resource availability before executing the change. This ensures that improvements or modifications do not accidentally disrupt existing security controls or business operations.
Technical Implementation
Use the tabs below to select your organization size.
Required Actions (startup)
- Use a simple ticketing system to track major changes to security tools or policies
- Discuss and approve changes in weekly engineering/leadership meetings
- Notify all staff of changes via email or Slack
Required Actions (scaleup)
- Implement a formal Change Advisory Board (CAB) for significant changes
- Require a 'rollback plan' for all proposed infrastructure changes
- Link ISMS changes to updated risk assessments
Required Actions (enterprise)
- Automate change freeze windows during critical business periods
- Integrate change management with GRC tools to auto-trigger compliance reviews
- Conduct post-implementation reviews (PIR) for all major ISMS changes
It is a requirement ensuring that any modifications to the ISMS (like scope, policies, or major controls) are executed in a planned, controlled manner to maintain the system's integrity and effectiveness.
Define a process where changes are identified, their purpose and consequences are evaluated, necessary resources are allocated, and authority/responsibility is assigned before the change occurs.
Changes to the ISMS scope, information security policy, organizational structure, risk assessment methodology, or major technology migrations require planned implementation under Clause 6.3.
Clause 6.3 refers to high-level changes to the management system itself (policies, scope, governance). Annex A 8.32 (Change Management) refers to operational changes to information processing facilities (systems, software, networks).
Document the plan, the risk assessment of the change, the approval decision (e.g., meeting minutes or ticket approval), and the outcome/evaluation of the change after implementation.
It means the change is not impulsive. You have considered the 'who, what, when, why, and how', allocated budget/people, and assessed what could go wrong before starting.
Yes, while the complexity scales with the organization, there must be a defined mechanism to ensure changes are not made arbitrarily and that their impacts are considered.
Update your risk assessment to consider if the change introduces new threats (e.g., new vendor) or vulnerabilities (e.g., new software bugs) and if existing controls are sufficient.
Planning ISMS changes often breaks down when approvals, risk reviews, and evidence are scattered across tickets, emails, and meeting notes. A GRC tool helps by turning each significant change into a traceable workflow with required steps (purpose, impact, resources, approvals, and review) and a clear audit trail. For example, WatchDog Security's Compliance Center can link the change record to Clause 6.3, attach approvals and meeting minutes as evidence, and flag gaps if a risk review or post-change evaluation is missing.
Risk analysis can drift from reality if it is not updated when you change scope, vendors, cloud environments, or key controls. The practical approach is to require a risk update before implementation and then confirm the residual risk after rollout as part of the change close-out. For example, WatchDog Security's Risk Register can tie each planned ISMS change to the affected risks, record treatment decisions and owners, and produce board-ready summaries showing what changed, why it was approved, and how the risk posture was adjusted.
| Version | Date | Author | Description |
|---|---|---|---|
| 1.0.0 | 2025-05-27 | WatchDog Security GRC Team | Initial publication |
