Sanjiv Mitragotri

ISMS Change Management Policy ISMS Change Management Policy Release RESTRICTED Version 1.0 Page 1 of 7 ISMS Change Management Policy Table of Contents I. Introduction 3 A. Purpose 3 B. Scope 3 C. Intended Audience 3 D. Definitions 3 II. Roles and Responsibilities III. 4 Change Management Process 4 A. Change Request Submission 4 B. Change Categorisation 4 C. Risk Assessment and Impact Analysis 4 D. Approval Process 4 E. Implementation 5 F. Post-Implementation Review 5 Documentation Requirements 5 IV. V. Security Considerations 5 VI. Emergency Change Management 6 VII. Review and Audit 6 VIII. Related Documents 6 IX. Policy Review and Updates 6 Annexure – A: Change Management Form 7 RESTRICTED Page 2 of 7 ISMS Change Management Policy I. Introduction A. Purpose The purpose of this policy is to establish guidelines for managing changes to information systems in a controlled manner, ensuring the Confidentiality, Integrity and Availability (CIA) of information assets is always maintained as mandated in ISO 27001:2022 standard. More specifically: ● Ensure that changes to information systems are managed and documented. ● Minimise the risk of incidents and service disruptions resulting from changes. ● Maintain compliance with the ISO 27001:2022 standards and other relevant regulations. ● Safeguard information security by assessing the impact of changes on security controls. B. Scope This policy applies to all employees, contractors, and third parties who initiate, review, approve, or implement changes to the organisation’s information assets, systems and infrastructure. C. Intended Audience This policy is intended to be used by the following personas: ● All Team Members (Employees, Vendor staff, Contractor staff) ● Stakeholders (as relevant depending on the nature of the change) D. Definitions ● Change: Any modification to an IT asset, configuration item (CI), or information system component. ● Emergency Change: A change that must be implemented immediately to address a critical issue or security vulnerability. ● ISG: Information Security Group - A group of stakeholders responsible for reviewing and approving / rejecting proposed changes. RESTRICTED Page 3 of 7 ISMS Change Management Policy II. Roles and Responsibilities ● Change Initiator: Identifies the need for a change, submits a change request, and provides relevant documentation. ● Change Owner: Responsible for overseeing the change from initiation to completion, including risk assessment and implementation. ● ISG: Evaluates the impact of changes on information security controls and compliance with ISMS/ SOC 2 / ISO 27001:2022. Review and provide recommendations on proposed changes, ensuring risks are understood and managed ● Change Implementer: Executes the change as per the approved change plan and ensures documentation and validation. III. Change Management Process A. Change Request Submission A Change Request (CR) must be submitted for every proposed change, including details such as change description, reason, affected assets, potential risks, and roll-back plan. The CR must include a risk assessment and impact analysis. (Refer Annexure A - for the template) B. Change Categorisation The following categories are associated with the change request: ● Standard Change: Changes which are planned or pre-approved with adequate notice for the nature of the change. ● Emergency Change: Requires expedited approval due to the urgent nature of the issue. C. Risk Assessment and Impact Analysis Every change identified shall undergo evaluation of the change’s potential impact on information security, system performance, and compliance. This includes changes to assets which are categorised as non IT/ Information systems as well. The ISG at the organisation level needs to ensure that any change in the organisation is evaluated for its impact on Information security systems and assets. The expected outcomes are to identify any risks associated with the change and define mitigation actions. D. Approval Process All the changes shall be reviewed by ISG and approved without exception. The process and timing of the review however may vary depending on the category of the change being implemented. RESTRICTED Page 4 of 7 ISMS Change Management Policy ● Standard changes are pre-approved and are usually associated with well planned and scheduled changes. ● Emergency changes are usually in response to any reported incident and the change is critical to restore normalcy at the earliest. An endeavour should be made to review these changes prior to its roll out – to ensure that the changes will address the current emergency situation at a minimum. A detailed and thorough review post-implementation should also be carried out to assess the impact and ensure no residual risks exist or have not resulted in a completely new risk as a result of the emergency change applied. E. Implementation The CR Implementer (individual or the team) shall be responsible to implement the change following the CR approval. The CR implementer shall ensure that the CR is implemented within the scheduled timeframe by following the process /steps approved in the CR form. The team shall document the implementation process, including testing, validation, and any deviations from the plan, that may be necessitated during implementation. F. Post-Implementation Review Verify that the change achieved its objectives without introducing new risks or issues. Document lessons learned and update relevant policies or procedures as necessary. The timing of this review shall vary depending on the severity and the nature of the change implemented. Emergency changes shall perform this review immediately after it is implemented. IV. Documentation Requirements A change log shall be maintained to log all change requests. It shall include details such as initiator, date, purpose/ reasons for change, change approval decision, implementation status and the outcome post implementation. It shall also capture the results of risk assessments, testing, and post-implementation reviews. V. Security Considerations All changes must be assessed for potential impacts on security controls and compliance. Ensure that critical data and configurations are backed up before implementing changes. Implement additional security controls if necessary to mitigate risks identified during the risk assessment. RESTRICTED Page 5 of 7 ISMS Change Management Policy VI. Emergency Change Management This type of change management is usually applicable for Information technology related assets. A separate IT Change management process and procedure shall be created to address the specific requirements of IT Change management, including ‘Emergency Change Management’. All emergency changes are logged and reviewed postimplementation by the ISG to identify and address any security or compliance concerns. VII. Review and Audit Conduct periodic audits of the Change Management process to ensure compliance with ISO 27001:2022. Review and update this policy annually or as needed to reflect changes in regulatory requirements or organisational structure. Non-compliance with this policy may lead to disciplinary action. The policy is designed to meet ISO 27001:2022 standards, and non-compliance may impact the organisation’s certification status. VIII. Related Documents ● ● ● ● Risk Assessment Policy Incident Management Policy Information Security Policy Business Continuity and Disaster Recovery Plans IX. Policy Review and Updates The Information Security committee is responsible for reviewing this policy annually. The policy shall be updated as per organisational or regulatory changes as and when necessary and shall be approved by management before rolling out to members. RESTRICTED Page 6 of 7 ISMS Change Management Policy Annexure – A: Change Management Form template Note: The format/ template below is a basic minimum format. Different departments can further customize this form or use additional documents to support this basic template to initiate and manage the Changes in the organisation. (e.g. IT department may have some specific details about the program’s/ modules/ UI/ UX changes that will be covered in the Change management form). Part – II (Post Approval) Part – I (Pre-Approval) Change request for – [Change Title] Change Initiator (Name/ Email id / Dept) Change Owner (Name/ Email id) Type of Change Change description (1 line title/ desc) Detailed description of the change ISG decision Changes To: (Impacted Department/ Processes/ Workflows / Systems / Apps Personnel etc.) Proposed Start date Proposed completion date Change Implementer RESTRICTED Standard / Emergency (Select any one) If necessary, a separate document can be created for large / complex changes. For smaller / simpler changes, the description can be described in this form. Provide filename(s) [exact filename(s)] in case separate document(s) is/are created for describing the change. If it’s filled in this form, then the following details should be provided: • Reason for change: • Risks Identified (if any) along with Mitigation plans Approved / On Hold / Rejected (Select any one) List of impacted entities/ information assets to be described. Repeating here is fine even if the same is covered in a separate Change document. This can be same as Change initiator/ Change Owner or someone different as well. (Usually same as Change Owner) Page 7 of 7