Information Technology Governance Framework

System Change Governance 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. 3.4.2 Change Requirement Definition and Approval Principle Changes to information assets should be formally defined, documented and approved by relevant asset owner prior to implementing the change in the information assets. Control Requirements 1. Change requirements should be formally initiated by the requestor of the change. 2. Change requirements should specify both functional and non-functional requirements, where applicable. 3. Change requirements should be formally reviewed and approved by the concern asset owner. 4. Any changes in the information assets should be assessed for their impact on the systems prior to implement the change. 5. Any change in the information assets should be endorsed by the Change Advisory Board (48") prior deploying to the production environment. 6. Any changes in the information assets should be reviewed and approved by the cyber security function before submitting to ‘CAB’ (required as per SAMA Cyber Security Framework, 3.3.7 Change Management , Control Requirements, 4 - d).