Skip to main content
Custom print
Download Original PDF

3.4.1 System Change Governance

No: 43028139 Date(g): 4/11/2021 | Date(h): 29/3/1443

Effective from 2021-11-04 - Nov 03 2021
To view other versions open the versions tab on the right

Principle

A Change Management process should be established to ensure that changes to the Member Organization's information assets are classified, tested and approved before their deployment into production environments

Control Requirements

1.System change management process should be defined, approved, implemented and communicated within the Member Organizations.
 
2.The effectiveness of the system change management process should be measured and periodically evaluated.
 
3.System change management process should be governed by the change management policy and procedure that should be approved, monitored, reviewed and updated on periodic basis and/or whenever significant changes occurs in the IT environment or changes in laws and regulatory requirements.
 
4.System change management process should address the following, but not limited to:
 
 a.change requirement definition and approval;
 
 b.change severity and priority;
 
 c.change risk and impact assessment;
 
 d.change development;
 
 e.change testing;
 
 f.change roll-out and roll-back;
 
 g.change roles and responsibilities;
 
 h.change documentation;
 
 i.change awareness and/or training for users; and
 
 j.change advisory board (CAB) input, if applicable.
 
5.A workflow system should be implemented to automate the change management process by the Member Organizations to the maximum extent possible.
 
6.Any changes in the information assets should be logged, monitored and documented.
 
7.System environments (i.e. development, testing, production, etc.) should be technically and logically segregated.
 
8.Access to different system environments should be strictly controlled and monitored. In order to do so, segregation of duties (‘SoD’) should be ensured so that no individual have two conflicting responsibilities such as (develop, compile, test, migrate and deploy) at the same time.
 
9.Emergency changes in the information assets should be performed in ه strictly controlled manner and should consider the following:
 
 a.the number of emergency changes should be least preferred over planned changes in order to keep such changes as minimum as possible;
 
 b.emergency changes should be assessed for their impact on the systems;
 
 c.emergency changes should be approved by the Emergency Change Advisory Board ('ECAB');
 
 d.minimum level of testing should be acceptable to implement the emergency changes;
 
 e.formal documentation of emergency changes should be completed post implementation;
 
 f.post implementation review should be conducted for all emergency changes; and
 
 g.root cause analysis should be conducted to determine the cause due to which emergency change was required, as well as maintaining a register to reflect lesson learned and report to all concerned staff, management and ITSC.
 
10.Sufficient auditing should be enabled to log emergency changes related to information assets for future reference or investigation purposes.