Version: 3.0

Valid until: 2025-04-12

Classification: Low

Version Management

Purpose & background

In the interest of all the stakeholders, the top management of anDREa B.V. (hereafter called anDREa) is actively committed to demonstrably maintain and continually improve an information management system in accordance with the requirements of the ISO 27001:2017.

The purpose of this document is to describe the change management policy of anDREa and the associated controls, checks and administrations.

This document will be reviewed at least annually and when significant change happens.

Objectives

The objectives of this control are:

• To ensure correct and secure operations of information processing facilities (A.12.1).

Scope

The scope of this document corresponds to Clause 4 Context of the organisation.

Availability

This document is:

• required reading for:

• all employees and contractors of anDREa.

• available for all interested parties as appropriate.

Norm elements

A.12.1.2 Change management

• A request for a change is submitted as a ticket (feature or outside-SLA requests), and decisions and updates are tracked in the ticket. See Appendix.
  

• The ticket is transferred to the Innovation Lab department in Zoho.
  

• The request is evaluated by the Support & Assurance team in order to determine the impact of the change, whether a change would lead to changes in existing processes and whether it impacts security. Necessary assessments are made per request.

• If anDREa chooses to proceed with the request for a change, a product backlog item (PBI) is created and an item is picked up accordingly based on priority, the planning and capacity of the development team (see Guidelines for changes during development cycle below). The PBI is added to the ticket and vice versa to keep track of the progress. Progress is discussed during daily standups and the monthly sprint rituals.

The development team works within the scrum framework. Changes are part of the general scrum development cycle. The operating procedures are described in A.12.1.1 Documented operating procedures and the development team works in accordance with A.14.2.1 Secure development policy. When a PBI requires a change, it is discussed with the scrum master and Operations Manager and the necessary steps are evaluated on a case-by-case basis.

When a change is required, the following guidelines are followed:

• The impact of the change is evaluated on a case-by-case basis and whether the change would affect the current (security) processes or the architecture.

• During the preparation of a major change, a risk assessment is always performed following the method of Clause 6 Planning. Moreover, a Security Impact Assessment (SIA) needs to be present.

• When a change requires a major adjustment in the current processes or the architecture, a new PBI is planned and evaluated according to the operating procedures in the design phase of the PBI. 

• When a major change involves the purchase/replacement of a critical application and/or ICT service, the instructions from A.15 Supplier relationships are always followed and the supplier requirements list is completed in full.

• When a major change relates to the IT infrastructure and/or software development, the policies as laid down in A.13 Communications security and A.14.2.1 Secure development policy will remain in force.

Changes to the ISMS:

The following guidelines apply when changes to the ISMS are made:

• The purpose and consequences of the change are identified.

• The impact of the change on the coherence of the ISMS are identified.

• Sufficient resources are made available for the change.

• New and/or services tasks and responsibilities are identified and assigned.

The Security Officer is responsible for registering the above.

Administrations

• Relevant PBIs.

• Security Impact Assessments.

• If needed, DPIAs.

• Supplier assessment reports (in case of a new supplier).

Appendix

Flow-chart Change management for changes requested by customer