3.4 System Change Management
System change management is a process of defining, designing, testing and implementing changes related to information assets including but not limited to application, software, device and data. Thus, risks factors related to system change management should be addressed by the Member Organizations through adequate implementation of required IT controls.
3.4.1 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).
3.4.3 System Acquisition
Principle
System acquisition process should be established to ensure risks associated with the system acquisition and related vendor service level are adequately assessed and mitigated prior acquiring system.
Control Requirements
1. System acquisition process should be defined, approved, implemented and communicated by the Member Organizations.
2. The effectiveness of the system acquisition process should be measured and periodically evaluated.
3. System requirements (i.e. functional and non-functional) should be formally defined and approved as part of system acquisition.
4. A feasibility study should be conducted to assess functional and non-functional requirements of the new system particularly in conformance with SAMA regulatory requirements, and other applicable regulatory requirements.
5. Vendor evaluation should be incorporated in the system acquisition process to assess vendor for their offering and capabilities to support system during and post implementation.
6. The system acquisition should be supported with a detail implementation plan describing the following, but not limited to:
a. system implementation milestones (including requirement gathering, development or customization, testing, go-live etc.);
b. timeline for each milestone and their dependencies; and
c. resources assigned to milestones.
7. The off-the-shelf system or package should be evaluated based on the following, but not limited to:
a. system conformance with the requirements of the Member Organization;
b. system creditability and market presence, if required; and
c. vendor evaluation and service level.
3.4.4 System Development
Principle
System development methodology should be documented, approved and implemented to ensure that the development of Member Organization's system is performed in a strictly controlled manner.
Control Requirements
1. The system development methodology should be defined, approved, implemented and communicated.
2. The effectiveness of the system development methodology should be monitored and periodically evaluated.
3. The system development methodology should address the following, but not limited to:
a. system development approach such as agile, waterfall, etc.;
b. secure coding standards;
c. testing types and approaches such as unit testing, regression testing, stress testing, etc.;
d. version controlling;
e. quality control;
f. data migration;
g. documentation; and
h. end user training.
4. The system design document should be defined, documented and approved.
5. The system design document should address the low level design requirements for the intended system, which includes but not limited to following:
a. configurations requirements;
b. integration requirements;
c. performance requirements;
d. cyber security requirements; and
e. data definition requirements.
6. Member organizations relevant IT function or development team should conduct secure code review for:
a. applications developed internally; and
b. externally developed applications if the source code is available.
7. Member Organizations should ensure that the secure code review report (or equivalent, such as an independent assurance statement) is formulated in case the source code is not available with the member organization.
8. Cyber security controls should be embedded in the system development process in line with SAMA Cyber Security Framework.
9. Version control system should be utilized to keep track of source code or build versions between various system environments (i.e. development, test, production, etc.).
3.4.5 Testing
Principle
All changes to information systems should be comprehensively tested on the test environment based on the defined and approved test cases to ensure that changes meets the business requirements as well as to identify defects or vulnerabilities before releasing changes to the production environment.
Control Requirements
1. Test plan should be formally defined, approved and documented for the changes.
2. Test case should be defined, approved and documented for the changes. In addition, test case should address the following, but not limited to:
a. test case name and unique ID;
b. test case designed by and tested by;
c. test case description with clear identification of negative and positive test cases;
d. test priority;
e. date of the test execution;
f. data use to test the cases;
g. status of the test case (i.e. pass or fail);
h. expected outcome of the test case; and
i. third party testing certification requirement, if applicable, i.e. MADA, Tanfeeth, etc.
3. At a minimum, the following types of testing should be considered as part of system change management.
a. unit testing;
b. system integration testing (SIT);
c. stress testing (if applicable);
d. security testing; and
e. user acceptance testing (UAT).
4. All changes to information system should be thoroughly tested on a separate test environment in accordance with the approved test cases.
5. All changes should be formally tested and accepted by the concern business users.
6. Testing should include positive and negative test cases scenarios.
7. The results of UAT should be documented and maintained for future reference purposes.
8. The production data should not be utilized for system testing in the test environment. Only sanitized data should be used for testing purposes.
3.4.6 Change Security Requirements
Principle
Cyber security requirements should be defined and thoroughly tested for all changes in the information system in a testing environment in order to identify and mitigate security vulnerabilities therein prior introducing them into the production environment.
Control Requirements
1. System change management process should consider SAMA Cyber Security Framework for defining, testing and implementing security requirements for any changes in the information assets.
3.4.7 Change Release Management
Principle
Change release management process should be defined to ensure that system changes are adequately planned and released to the production environment in a strictly controlled manner.
Control Requirements
1. The release management process should be defined, approved, implemented and communicated.
2. The release management process should be monitored and periodically evaluated.
3. The release management process should address the following, but not limited to:
a. change release strategy and approach;
b. roles and responsibilities to carry out change releases;
c. change release schedule and logistics;
d. change roll-out and roll-back procedures; and
e. data migration, where applicable.
4. The changes should be released in the corresponding system in disaster recovery site upon successful implementation of changes in the production environment at main site.
5. Change should be introduced as part of an agreed change window, exceptions has to have their own approval process and seldom allowed without compelling reasons.
3.4.8 System Configuration Management
Principle
System Configuration Management Process should be defined, approved, communicated and implemented to maintain a reliable and accurate information about configuration items ('CIs') for Member Organization's information assets.
Control Requirements
1. The configuration management process should be defined, approved, implemented and communicated by the Member Organizations.
2. The configuration management process should be monitored and periodically evaluated.
3. The configuration management process should address the following, but not limited to:
a. roles and responsibilities for carrying out configuration management;
b. identification and recording of configuration items and their criticality with respect to its supporting business processes;
c. interrelationships between configuration items among various information assets; and
d. periodic verification of configuration items.
4. Member Organizations should implement configuration management database (‘CMCB’) to identify, maintain, and verify information related to Member Organization's Information assets.
3.4.9 Patch Management
Principle
Patch management process should be defined and implemented to ensure up-to-date with latest applicable and relevant patches (i.e. functional or non-functional) are installed in a timely manner to avoid technical issues including security breaches due to existing vulnerabilities in the system.
Control Requirements
- The patch management process should be defined, approved, implemented and communicated by the Member Organizations.
- The effectiveness of the patch management process should be monitored, measured and periodically evaluated.
- All patches should be thoroughly assessed for impact by relevant stakeholders including cyber security before being implemented into the production environment.
- All systems should be periodically scanned or inspected to identify any outdated patches and vulnerabilities in the systems.
- Deployment of patches should follow a formal change management process.
- All patches should be thoroughly tested in a separate test environment prior introducing to the production environment to avoid any compatibility issue with the system and related components.
- Patches should be rolled out to systems and related components systematically.
- Following deployment of patches to the production environment, systems should be monitored for any abnormal behavior and, if such behavior identified should be thoroughly investigated to identify the root cause and fix them properly.
- Patch deployment window (i.e. schedule) should be communicated to business and relevant stakeholders in advance and preferable should be done during non-peak hours and non-freezing periods to avoid any business disruption.
- The external feeds from software vendors or other acknowledged sources should be monitored to identify any new vulnerabilities in the system and to be patched accordingly.
3.4.10 IT Project Management
Principle
Formal process should be defined, approved and implemented to effectively manage IT project and related risks throughout the lifecycle of the project.
Control Requirements
1. The IT project management process should be defined and approved by the Member Organizations.
2. The IT project management process should be governed with a formally defined and approved IT project management framework, policy and procedure to manage IT project lifecycle from initiation till closure.
3. The effectiveness of the IT project management process should be monitored, measured and periodically evaluated.
4. All IT projects should be provided with detail project plan, which include the following, but not limited to:
a. detail scope of work including activities for a project or each phase of the project;
b. priorities, milestones and timelines associated with project or each phase of the project;
c. deliverables;
d. roles and responsibilities; and
e. risks associated with any IT projects.
5. Necessary documentations for the IT project should be defined, approved and maintained for future reference purposes including but not limited to following:
a. project charter;
b. requirement analysis, business information flow and technical information flow;
c. feasibility as well as cost-benefit analysis; and
d. detail project plan.
6. IT project steering committee should be established having representation from relevant business and technical teams to oversee plan, progress and risks associated with the IT projects.
7. All IT projects should be assessed for the risks that could impact the scope, timeline and quality of the projects. Any identified risks should be mitigated and monitored throughout the project lifecycle.
8. Any significant risks associated with the IT project should be reported to IT project steering committee and to senior management or board of directors of the member organization in a timely manner.
9. All project deliverables should be reviewed by an independent quality assurance function or an independent person provided with such responsibly prior commencing project to the production environment.
10. Post-implementation reviews should be planned and executed to determine whether IT projects delivered the expected benefits, met business/user requirements, and complied with the IT project management framework.
11. The Member Organizations should inform 'General Department of Cyber Risk Control' for any major IT transformation projects, such as core system implementation, after the approval from the senior management.
12. Cyber security should be involved during various phases of the IT project management lifecycle in line to the control considerations provided in SAMA Cyber Security Framework.
3.4.11 Quality Assurance
Principle
The quality assurance process should be defined, approved, communicated and implemented to independently ascertain quality of the changes or development in the information assets in line with the business/user requirements prior moving them to the production environment.
Control Requirements
1. The quality assurance process should be defined, approved, implemented and communicated by the Member Organizations.
2. The quality assurance process should be monitored and periodically evaluated.
3. The quality assurance process should address the following, but not limited to:
a. clear roles and responsibilities for personnel carrying out quality assurance activities;
b. minimum quality requirements sets by the Member Organizations including business and any other applicable regulatory requirements; and
c. process for identification, maintenance and retirement of quality related records.
4. The quality assurance function/department should have independent existence and reporting with authority to provide objective evaluation.
5. All changes or development to information system should be assessed by the quality assurance team prior releasing to the production environment.
6. The quality assurance function should report the reviewed results to the relevant stakeholder(s) within the Member Organizations and initiate improvements where appropriate.