Change Management Policy

Policy defines change control procedures to ensure the integrity of Corporate Group’s developed services and products from the early design stages through all subsequent maintenance efforts.

Scope

This Policy applies to all parties operating within the EClaims Group’s network environment or utilizing Information Assets.

It covers the data networks, LAN servers and personal computers (stand-alone or network-enabled), located at Corporate Group offices and production related locations, where these systems are under the jurisdiction and/ or ownership of the Company or Subsidiaries, and any personal computers, laptops, mobile device and or servers authorized to access the Corporate Group’s data networks.

This Policy applies throughout the Corporate Group as part of the information security management system framework.

Policy

Operational Procedures

  • The change control process is defined and documented.

  • A change control process is in place to control Change to all Critical Information Assets (such as hardware, software, system documentation and operating procedures). This documented process shall include management responsibilities and procedures.

Documented Change

  • All Change requests are logged whether approved or rejected on a standardized and central system. The approval of all Change requests and the results thereof shall be documented.

  • A documented audit trail, containing relevant information shall be always maintained. This should include Change request documentation, Change authorization and the outcome of the Change.

  • No single person should be able to effect Change to production system without the approval of other authorized personnel.

Risk Management

  • A risk assessment shall be performed for all Changes and dependent on the outcome, an impact assessment should be performed.

  • The impact assessment shall include the potential effect on other information resources and potential cost implications. The impact assessment should, where applicable consider compliance with legislative requirements and standards.

Change Classification

All Change requests shall be prioritized in terms of benefits, urgency, effort required and potential impact on operations.

Testing

  • Change shall be tested in an isolated, controlled, and representative environment (where such an environment is feasible) prior to implementation to minimize the effect on the relevant business process, to assess its impact on operations and security and to verify that only intended and approved changes were made. Separation must be enforced at least with access controls.

  • Separation of duties must be established between isolated, controlled, and representative environment and production environment.

  • Production data must not be used for testing or development.

Changes affecting SLA's

  • Any software Change and/or update shall be controlled with version control.

  • Older versions shall be retained in accordance with Corporate Group retention and storage management policies.

Version control

  • Any software change and/or update shall be controlled with version control.

  • Older versions shall be retained in accordance with Company retention and storage management policies.

Approval

  • All Changes shall be approved prior to implementation.

  • Approval of Change shall be based on formal acceptance criteria i.e., the Change request was done by an authorized user, the impact assessment was performed, and proposed Change were tested.

Communicating changes

  • All users, significantly affected by a Change, shall be notified of the Change.

  • The user representative shall sign-off on the Change.

  • Users shall be required to make submissions and comment prior to the acceptance of the Change.

Implementation

  • Implementation will only be undertaken after appropriate testing and approval by stakeholders.

  • All major Changes shall be treated as new system implementation and shall be established as a project.

  • Major Changes will be classified according to effort required to develop and implement.

Rollback and Back-Out

Rollback and Back-Out plans should be developed for each new Change and include:

  • Strategy

  • Load testing and user acceptance testing Considerations

  • Criteria

  • Risks

  • Authority

  • Verification procedure

  • Other procedures

Documentation

  • Information resources documentation shall be updated on the completion of each Change and old documentation shall be archived or disposed of as per the documentation and data retention policies

  • Information resources documentation is used for reference purposes in various scenarios

  • It is therefore imperative that information resources documentation is complete, accurate and kept up to date with the latest Change

  • Policies and procedures, affected by software changes, shall be updated on completion of each change

Business Continuity Plans (BCP)

  • Business continuity plans shall be updated with relevant Changes, managed through the Change control process

  • Business continuity plans rely on the completeness, accuracy, and availability of BCP documentation

  • BCP documentation is the road map used to minimize disruption to critical business processes where possible, and to facilitate their rapid recovery in the event of disasters

Emergency Change

  • Specific procedures to ensure the proper control, authorization, and documentation of emergency Change shall be in place

  • Specific parameters will be defined as a standard for classifying changes as Emergency changes

Change Monitoring

  • All Changes will be monitored once they have been rolled-out to the production environment

  • Deviations from design specifications and test results will be documented and escalated to the solution owner for ratification

Information Confidentiality

Information including personal information during the Change process meets the Corporate Group's objectives related to confidentiality.

Patch Management

  • Patches are managed according to this Policy

  • Periodically scans are made to detect system components missing patches

  • If patching is not possible to implement, the residual risk is evaluated

  • Based on risk evaluation, either the risk is accepted or mitigating measures must be taken

Review

This Policy is maintained in accordance with the Information Security Policy.

Revision History

Version
Author
Approved By
Revision date
Approval date

0.1

GK

2023-05-20

2023-05-23

0.2

DM

2023-11-02

2023-11-02

0.3

GK

DM

2024-09-10

2024-09-10

Last updated