Information Technology Governance Framework

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.).