ADGM FSRA Information Technology Risk Management Guidance (VER01.201124) 5.2: Control system acquisition, development and testing: end-user computing approval, vendor due diligence and security parity, cloud responsibilities, secure development practices, code and open-source controls, and pre-deployment testing

What does 5.2 require?

Sourcing and in-house development each follow the institution's rules and the risk framework. End-user computing (macros, scripts, online tools) is approved by management after assessment of business need, security posture and performance, brought into the asset inventory, risk, compliance, configuration, patch and continuity programmes, and unauthorised EUC is discouraged with staff made aware of its risks. Procurement rules and vendor due diligence assess track record, product standards, fit with specifications and ability to deliver; sourced systems meet IT security and data protection standards at least equal to the institution's own or receive management approval for shortfalls; vendor access to the environment is stringently assessed, granted and monitored; and a process exists to replace a sourced system on failure or vendor dissolution, with escrow or manual workarounds where substitutes are scarce. For cloud, the institution is clear on its responsibilities under the shared responsibility model before subscribing, performs due diligence and strategic alignment, chooses a deployment model with at least logical segregation from other customers, knows the location of workloads and data at all times, considers cloud access security broker tools, allows for differences between clouds and gaps in abstraction tools in multi-cloud deployments, and holds the technical competence the chosen service model demands. A development framework specific to the methodology and tools sets processes and controls per stage; security is designed in with regular security assessments recording threats, risks and controls; requirements for function, non-functional quality, performance and resilience are defined with business functions and architecture fit assessed; development runs in environments separate from production; versioning and change control track releases with access limited to authorised staff; secure programming rules draw on hardening standards, code review and static or dynamic testing; code repositories are backed up, securely administered, accessed with strong authentication and scanned for vulnerabilities and secrets, with secrets stored separately; open-source components receive compatibility and vulnerability assessment and are covered by change and patch management; any open-source publication programme controls what code may be released; and third-party developers provide assurance on their practices and are monitored. Every system is tested before deployment with business and security functions against functional, performance, security and resilience requirements, the types and timing of tests (unit, validation, access, performance, integration, regression, penetration, acceptance) are chosen per project and scaled to risk for sourced systems, access to test results is controlled, testing runs in environments separate from production, issues are tracked and resolved or deviations approved by management before production, and deployment follows established procedures.