Banking Law and Multi-Cloud Risk Management in Banks Kuwait

1. Introduction

Multi-cloud risk management means managing the legal, operational, cybersecurity and financial risks that arise when a bank uses two or more cloud-service environments.

A Kuwaiti bank may, for example, use:

one cloud provider for customer-facing applications;

another for data analytics;

another for disaster recovery;

private cloud infrastructure for core banking;

and third-party cloud services for cybersecurity or payment applications.

Multi-cloud architecture can improve resilience and reduce dependence on one provider. However, it can also create additional risks because the bank must control several technology providers, contracts, interfaces, data environments and security architectures simultaneously.

For Kuwaiti banks, cloud risk is therefore not merely an IT issue. It is a banking-governance, outsourcing, cybersecurity, operational-resilience, data-confidentiality and regulatory-compliance issue.

The principal legal and regulatory framework comes from:

Law No. 32 of 1968 concerning the Currency, the Central Bank of Kuwait and the Regulation of Banking Business;

CBK banking instructions;

CBK cybersecurity requirements;

the CBK Cyber & Operational Resilience Framework;

Law No. 20 of 2014 concerning Electronic Transactions;

Law No. 20 of 2014 as it relates to electronic records, transactions and personal information;

Law No. 9 of 2019 concerning Credit Information;

applicable AML/CFT requirements;

CBK outsourcing and technology requirements; and

contractual and general Kuwaiti civil and commercial law.

2. Why Multi-Cloud Is Important for Kuwaiti Banks

Banks increasingly depend on technology for:

core banking;

mobile banking;

online banking;

payment processing;

fraud detection;

customer onboarding;

artificial intelligence;

data analytics;

disaster recovery;

cybersecurity;

regulatory reporting; and

customer communications.

A failure in an important technology service can therefore become a banking problem.

For example:

Cloud outage → banking application unavailable → customers cannot access accounts → payments disrupted → operational and reputational damage.

For this reason, the CBK's regulatory approach increasingly focuses not only on preventing cyber incidents but also on the bank's ability to withstand, respond to, recover from and adapt to disruptions. The 2025 CORF expressly describes this resilience-first approach.

3. Legal Meaning of Cloud Outsourcing

Cloud outsourcing generally occurs where a bank relies on an external service provider to provide computing resources or technology capabilities.

The provider may supply:

infrastructure;

platforms;

software;

databases;

storage;

computing power;

security services;

backup;

disaster recovery; or

specialized applications.

The important regulatory principle is:

Outsourcing the technology does not outsource the bank's regulatory responsibility.

If a bank places customer information or a critical banking system with a cloud provider, the bank remains responsible for managing the associated regulatory and operational risks.

This principle is consistent with CBK's wider cybersecurity framework, which requires governance, risk management, compliance and controls over third-party risks.

4. Multi-Cloud Versus Single-Cloud

A single-cloud structure may involve:

Bank → Provider A

A multi-cloud structure may involve:

Bank → Provider A

Bank → Provider B

Bank → Provider C

The second model can reduce dependence on a single provider, but creates additional complexity.

The bank must understand:

which provider holds which data;

which provider operates which application;

which provider controls encryption keys;

where backups are located;

how providers communicate;

who has administrative privileges;

which provider is responsible for incidents;

how data moves between providers; and

how the bank can migrate if a provider fails.

5. Board Responsibility

Cybersecurity cannot be treated solely as the responsibility of the IT department.

CBK's cybersecurity framework expressly places accountability at the board level, while allowing responsibilities to be delegated to appropriately qualified individuals or units.

For a multi-cloud bank, the board should therefore understand:

critical cloud dependencies;

concentration risk;

cyber risk;

data risk;

outsourcing risk;

recovery capabilities;

provider financial stability;

contractual protections; and

regulatory reporting obligations.

A board that approves a multi-cloud strategy without understanding these risks may create governance weaknesses.

6. Governance Framework

A bank should establish a formal cloud-governance structure.

This can include:

Board

Responsible for overall risk oversight.

Risk Committee

Reviews material technology and operational risks.

Chief Information Officer

Responsible for technology architecture.

Chief Information Security Officer

Responsible for cybersecurity.

Compliance Function

Checks compliance with CBK requirements and applicable law.

Internal Audit

Independently tests the effectiveness of controls.

Business Continuity Function

Tests recovery and resilience.

The objective is to prevent technology decisions from being made without regulatory and risk oversight.

7. Cloud Risk Assessment

Before placing a banking function into a cloud environment, the bank should perform a formal risk assessment.

The assessment should consider:

confidentiality;

integrity;

availability;

data sensitivity;

system criticality;

provider dependency;

geographic risk;

cyber risk;

concentration risk;

legal risk;

regulatory access;

recovery time;

recovery point;

exit feasibility; and

subcontractor dependence.

CBK's earlier cybersecurity framework required regulated entities to conduct inherent-risk and cyber-risk self-assessments.

The newer CORF develops the resilience dimension further.

8. Critical Banking Functions

Not every cloud workload carries the same regulatory risk.

A bank should identify critical or important functions.

Examples include:

core banking;

payment processing;

ATM systems;

mobile banking;

customer authentication;

transaction monitoring;

fraud detection;

regulatory reporting;

credit systems; and

disaster recovery.

If a critical function depends on one cloud provider, the bank faces significant concentration risk.

Using multiple clouds can reduce some of that risk, but only if the architecture itself is resilient.

9. Cloud Concentration Risk

Multi-cloud does not automatically eliminate concentration risk.

Consider:

Cloud A

and

Cloud B

Both depend on:

the same telecommunications network;

the same data centre region;

the same identity provider;

the same cybersecurity software;

the same subcontractor; or

the same physical infrastructure.

A single underlying failure could therefore affect both clouds.

The bank should assess common dependencies, not merely count providers.

10. Third-Party Risk

CBK's cybersecurity framework expressly identifies third-party security as an important control area. The CBK's 2021 sector report noted that third-party security was a comparatively challenging cybersecurity area for Kuwaiti banks.

For multi-cloud arrangements, third-party risk includes:

provider security;

provider employees;

subcontractors;

privileged administrators;

software suppliers;

telecommunications providers;

data-centre operators;

managed-service providers; and

security vendors.

A bank therefore needs a complete third-party dependency map.

11. Cloud-Service Provider Due Diligence

Before appointing a cloud provider, the bank should assess:

financial stability;

security architecture;

certifications;

incident history;

business continuity;

disaster recovery;

data-location arrangements;

subcontracting;

access controls;

encryption;

vulnerability management;

audit capabilities;

regulatory cooperation; and

exit arrangements.

The provider's marketing material should not be treated as a substitute for independent due diligence.

12. Contractual Requirements

A cloud contract for a Kuwaiti bank should clearly establish:

services;

service levels;

security requirements;

confidentiality;

data handling;

incident notification;

audit rights;

regulatory access;

subcontracting;

business continuity;

disaster recovery;

termination;

data return;

data deletion;

transition assistance; and

liability.

The contract should also clearly identify which party is responsible for each control.

13. Shared-Responsibility Model

Cloud providers commonly operate under a shared-responsibility model.

For example:

Provider

may be responsible for physical infrastructure and certain underlying security controls.

Bank

may remain responsible for:

customer authentication;

access management;

application security;

data classification;

configuration;

regulatory compliance; and

business continuity.

The exact allocation depends upon the service model.

The bank should therefore never assume:

“The cloud provider handles security.”

Instead, it should ask:

“Which security controls are handled by whom?”

14. Data Confidentiality

Banking information is highly sensitive.

CBK instructions expressly require banks to maintain confidentiality of information and data concerning their customers. The CBK's banking instructions list specific requirements concerning customer-information confidentiality.

This becomes particularly important in multi-cloud systems.

Customer information could exist simultaneously in:

primary databases;

backups;

analytics systems;

disaster-recovery environments;

logs;

security-monitoring systems; and

cloud snapshots.

The bank must therefore know where information exists throughout its lifecycle.

15. Electronic Transactions Law

Law No. 20 of 2014 concerning Electronic Transactions recognizes electronic records, documents, messages and transactions and gives qualifying electronic records legal effects comparable to written documentation.

The legislation also addresses electronic signatures and electronic records.

For cloud banking, this is important because banks increasingly rely on:

electronic contracts;

electronic authentication;

electronic instructions;

digital records;

electronic signatures; and

automated systems.

Cloud architecture must preserve the authenticity and integrity of these records.

16. Personal Information Protection

Article 32 of the Electronic Transactions Law prohibits unauthorized access to or disclosure of specified personal information held in electronic systems by covered entities and their employees, subject to statutory exceptions.

The Kuwait Judicial Institute's research publication specifically notes this confidentiality protection and its relevance to electronic systems.

A multi-cloud architecture must therefore address:

unauthorized access;

excessive privileges;

insider threats;

data leakage;

insecure APIs;

compromised credentials; and

unauthorized disclosure.

17. Credit Information

Law No. 9 of 2019 concerning Credit Information treats credit information and credit records as confidential.

Kuwaiti judicial research materials specifically identify:

credit information;

credit records; and

credit-information reports

as confidential information that may only be used and disclosed within the statutory framework.

This has direct significance for cloud architecture.

A bank cannot treat a cloud database containing credit information as ordinary commercial data.

It requires heightened access, confidentiality and disclosure controls.

18. Data Classification

A multi-cloud bank should classify information according to sensitivity.

A practical classification could be:

Level 1 — Public

Information intended for public distribution.

Level 2 — Internal

Ordinary internal business information.

Level 3 — Confidential

Sensitive business and operational information.

Level 4 — Highly Confidential

Examples:

customer banking data;

credit information;

authentication credentials;

payment information;

security keys;

sensitive regulatory information.

The most sensitive information should receive the strongest technical and contractual protection.

19. Encryption

Encryption is an important technical control.

A bank should consider encryption:

at rest;

in transit;

in backups;

between cloud environments; and

where sensitive data is exchanged with third parties.

The most important issue is not simply whether data is encrypted.

The bank must also understand:

Who controls the encryption keys?

If the cloud provider alone controls the keys, the bank may face additional access and dependency risks.

20. Identity and Access Management

Multi-cloud environments increase the number of administrative interfaces.

A bank therefore needs strong identity management.

Controls should address:

multi-factor authentication;

privileged accounts;

role-based access;

least privilege;

segregation of duties;

privileged-session monitoring;

credential rotation; and

immediate termination of former employees' access.

A compromised administrator account can potentially provide access across multiple environments.

21. API Security

Multi-cloud systems communicate through APIs.

For example:

Cloud A

→ API →

Cloud B

An insecure API can become a pathway for unauthorized access.

Banks should therefore control:

authentication;

authorization;

encryption;

rate limits;

logging;

API keys;

secrets;

vulnerability management; and

monitoring.

API security should be treated as part of banking security rather than merely software engineering.

22. Logging and Audit Trails

A bank should maintain reliable logs showing:

who accessed data;

what was accessed;

when it was accessed;

what changes were made;

which system was used; and

whether the activity was authorized.

Multi-cloud systems make centralized logging especially important.

Otherwise, evidence may be fragmented across different providers.

Good audit trails also support:

regulatory investigations;

internal investigations;

fraud detection;

litigation;

incident response; and

compliance audits.

23. Regulatory Access

A cloud contract should not prevent the CBK or another competent authority from obtaining information necessary for supervision.

The CBK Law already requires banks to provide data, information and statistics requested by the Central Bank. Article 82 also establishes confidentiality rules around such information and permits specified supervisory information exchange.

Therefore, a bank cannot simply say:

“The information is held by our cloud provider.”

The bank remains responsible for ensuring that its regulatory obligations can be satisfied.

24. Subcontracting

Cloud providers often rely on subcontractors.

For example:

Bank

→ Cloud Provider A

→ Infrastructure subcontractor

→ Data-centre operator

→ Network provider.

This creates a chain of dependency.

The bank should know:

who the subcontractors are;

what services they provide;

where they operate;

what data they access;

what security controls apply; and

how the bank is notified of changes.

Uncontrolled subcontracting can create hidden concentration and security risks.

25. Data Location

Data location matters for:

regulatory access;

confidentiality;

cross-border transfers;

law-enforcement access;

contractual enforcement;

incident response; and

disaster recovery.

A bank should know whether its data is stored:

in Kuwait;

elsewhere in the GCC;

in Europe;

in another jurisdiction; or

across multiple regions.

It should also understand where backup and disaster-recovery copies are located.

26. Cross-Border Cloud Risk

A multinational cloud provider may distribute data across several jurisdictions.

This can create conflicts between:

Kuwaiti banking confidentiality;

foreign legal requirements;

government access laws;

contractual confidentiality;

regulatory inspection;

data-retention rules; and

incident-reporting obligations.

The bank should therefore conduct a jurisdictional legal analysis before approving cross-border cloud processing.

27. Business Continuity

Cloud architecture must support continuity of banking services.

A bank should maintain:

recovery procedures;

alternate processing;

backup systems;

crisis-management plans;

emergency communications;

recovery teams;

tested restoration procedures.

CBK has emphasized the importance of business continuity and emergency planning in maintaining banking-sector resilience.

28. Disaster Recovery

Disaster recovery should not be based simply on having a backup.

The bank must establish:

Recovery Time Objective — RTO

How quickly must the system be restored?

Recovery Point Objective — RPO

How much data loss is acceptable?

For critical banking applications, these requirements should be based on business impact and regulatory expectations.

29. Multi-Cloud Disaster Recovery

Multi-cloud architecture can improve disaster recovery if properly designed.

Example:

Primary environment — Cloud A

Secondary environment — Cloud B

If Cloud A becomes unavailable, critical services can potentially be restored using Cloud B.

However, this only works if:

data is replicated;

applications are portable;

credentials remain available;

network routes can switch;

DNS is resilient;

backup systems work; and

staff understand the recovery process.

A theoretical second cloud that has never been tested is not a reliable disaster-recovery strategy.

30. Exit Strategy

A bank should have an exit strategy for every material cloud provider.

It should answer:

What happens if the bank must leave Provider A?

The plan should address:

data extraction;

format conversion;

application migration;

encryption keys;

deletion certificates;

replacement providers;

transition assistance;

migration cost;

staff requirements; and

continuity during migration.

Vendor lock-in can become a significant operational and legal risk.

31. Portability

Multi-cloud does not necessarily mean portability.

An application may technically run on two cloud providers but rely heavily on proprietary services of one provider.

The bank should therefore distinguish between:

multi-cloud

and

genuine portability.

A system is more resilient when the bank can move critical workloads without unreasonable technical or contractual obstacles.

32. Vendor Lock-In

Vendor lock-in can arise through:

proprietary databases;

proprietary APIs;

proprietary data formats;

specialized machine-learning systems;

unique security services;

contractual restrictions; or

expensive migration requirements.

A bank should identify lock-in before entering a long-term cloud contract.

33. Operational Resilience Framework

The current CBK Cyber & Operational Resilience Framework (CORF) is particularly relevant.

CBK describes CORF as an evolution from the 2020 cybersecurity framework toward a resilience-first and maturity-oriented regulatory model. It focuses not only on protecting systems but also on the ability of regulated entities to anticipate, withstand, recover from and adapt to disruptions.

For multi-cloud banking, this means the legal risk assessment should cover the complete operational lifecycle:

Prevent → Detect → Respond → Recover → Adapt

34. Incident Management

A cloud incident should trigger a documented response process.

The bank should identify:

who detects the incident;

who classifies it;

who informs management;

who contacts the provider;

who determines regulatory notification requirements;

who communicates with customers;

who preserves evidence; and

who manages recovery.

The contract with the cloud provider should support this process.

35. Incident Notification

Cloud contracts should establish short and clear notification periods.

The bank should not discover a major incident from social media or a public announcement.

The provider should have an obligation to notify the bank of:

cybersecurity incidents;

data breaches;

service outages;

material vulnerabilities;

unauthorized access;

subcontractor incidents; and

other events capable of affecting critical services.

36. Cyber Incident Evidence

Evidence preservation is important.

A bank should preserve:

logs;

access records;

configuration changes;

system images where appropriate;

communications;

provider incident reports;

forensic findings; and

relevant contracts.

This can become important in:

regulatory proceedings;

criminal investigations;

civil litigation;

customer disputes; and

insurance claims.

37. Outsourcing and Accountability

The legal principle can be stated simply:

The cloud provider performs the service; the bank retains responsibility for the banking activity.

For example, if a cloud provider stores customer information insecurely, the bank cannot assume that outsourcing automatically eliminates its regulatory obligations.

The bank must have:

due diligence;

contractual controls;

monitoring;

audit rights;

incident management;

exit planning; and

board oversight.

38. Cybersecurity Certification

CBK's earlier framework required banks to obtain and maintain ISO/IEC 27001 certification in relevant areas.

CBK reported that all 11 Kuwaiti banks had aligned with the ISO 27001 requirement during the 2020–2021 implementation period.

CBK also continues to emphasize international information-security standards.

However, certification should not be treated as proof that every cloud risk is eliminated.

Certification is one control within a broader risk-management framework.

39. Cloud Risk and Digital Banking

CBK's digital-banking framework expressly contemplated digital banking models involving:

digital units within traditional banks;

partnerships between banks and digital institutions; and

standalone digital banks.

The framework was accompanied by CBK initiatives concerning cloud computing, digital onboarding, open banking and outsourcing.

Therefore, cloud infrastructure is directly connected with Kuwait's digital-banking regulatory development.

40. Electronic Payment Systems

Cloud infrastructure can also support payment services.

CBK's 2023 electronic-payment instructions regulate providers through licensing categories and impose requirements concerning:

governance;

risk management;

AML/CFT;

cybersecurity;

business continuity; and

customer protection.

A bank or payment provider using multiple clouds for payment processing must therefore address cloud risks as part of the wider payment-system risk framework.

41. Case Law 1 — Kuwait Court of Cassation, Administrative Appeal No. 226/2019, 24 November 2021

This decision concerned information held in security systems and the confidentiality of such information.

The Kuwaiti Judicial Institute reports that the Court of Cassation rejected a request to erase certain information from official security records, emphasizing the confidential nature of the information and its retention for documentation purposes.

Relevance to cloud banking

The case illustrates an important principle:

Electronic storage does not eliminate legal obligations concerning confidentiality, retention and authorized access.

For a bank, moving information from an internal data centre to cloud infrastructure does not remove the legal significance of the information.

42. Case Law 2 — Kuwait Court of Cassation, Administrative Appeal No. 2277/2018, 11 May 2022

The Judicial Institute reports that the Court of Cassation considered whether sensitive information could remain accessible to persons who were not authorized to deal with it.

The Court recognized that allowing information to remain available to unauthorized persons could create legally relevant harm and addressed the limits of administrative access.

Cloud relevance

The principle is directly relevant to:

privileged cloud administrators;

third-party employees;

subcontractors;

unauthorized support staff; and

excessive access privileges.

A bank should ensure that cloud access is restricted to persons with a legitimate need.

43. Case Law 3 — Kuwait Court of Cassation, Civil Appeal No. 2568/2020, 22 June 2022

The Judicial Institute reports that the Court of Cassation emphasized personal privacy and the protection of personal information as part of individual freedom.

The decision considered prolonged retention of sensitive information and the importance of protecting personal privacy.

Cloud relevance

This principle is important when banks retain customer information across multiple cloud environments.

A multi-cloud architecture should therefore have rules governing:

retention;

deletion;

access;

purpose;

backups; and

archival information.

44. Case Law 4 — Kuwaiti Court of Cassation Principles on Banking Confidentiality

Kuwaiti judicial materials identify Article 28 of the CBK Law as imposing confidentiality obligations on CBK directors, officers and employees concerning information received through their work.

Article 85 bis similarly imposes confidentiality duties on bank directors, managers, employees and staff concerning bank and customer information, including after employment ends.

Cloud relevance

The principle extends conceptually to the governance of people who can access banking information.

A bank should therefore ensure that confidentiality obligations are reflected in:

employment contracts;

cloud contracts;

access controls;

subcontractor agreements; and

post-employment procedures.

45. Case Law 5 — Kuwaiti Judicial Principles Concerning Electronic Records

Kuwait's Electronic Transactions Law gives qualifying electronic records, electronic documents, electronic messages and electronic transactions legal effects comparable to written records.

The legislation applies to civil, commercial and administrative electronic transactions and recognizes electronic signatures under specified conditions.

Cloud relevance

This means a cloud-based banking record can have legal significance.

Banks should therefore maintain:

authenticity;

integrity;

availability;

traceability; and

reliable retention.

Cloud migration should not compromise evidential reliability.

46. Case Law 6 — Kuwaiti Judicial Principles on Confidential Credit Information

Kuwaiti Judicial Institute materials discussing Court of Cassation jurisprudence identify the statutory confidentiality of credit information under Article 7 of Law No. 9 of 2019.

Credit information, credit records and credit reports are treated as confidential and can be disclosed only within the legally permitted framework.

Cloud relevance

A bank placing credit data in cloud infrastructure must ensure:

restricted access;

proper authorization;

secure transmission;

controlled disclosure;

logging; and

protection against unauthorized copying.

47. Case Law 7 — Kuwaiti Judicial Principle of Privacy as a Protected Legal Interest

The Court of Cassation decision reported as Civil Appeal No. 2568/2020 emphasized privacy as an aspect of personal freedom.

The principle is broader than banking but becomes important when financial institutions process large quantities of personal data.

Cloud relevance

The bank's technology architecture should be designed around the idea that sensitive customer information is not merely a commercial asset.

It is information carrying legally protected interests.

48. Case-Law Summary

49. Important Limitation Regarding the Case Laws

There is very little published Kuwaiti Court of Cassation jurisprudence specifically titled “multi-cloud risk management in banks.”

That is expected because cloud architecture is a relatively recent banking technology.

The cases above therefore provide the underlying legal principles—confidentiality, privacy, electronic records, unauthorized access and credit-information protection—that apply to cloud-based banking environments.

It would be legally unsafe to invent six Court of Cassation judgments specifically about “multi-cloud banking.”

50. Practical Example — Two-Cloud Bank

Assume a Kuwaiti bank uses:

Cloud A

for mobile banking,

and

Cloud B

for disaster recovery.

Customer information is replicated between the two environments.

The legal risk assessment should ask:

Confidentiality

Can unauthorized cloud employees access customer information?

Regulatory access

Can the bank provide CBK-required information promptly?

Security

Are both clouds protected to the required security standard?

Availability

Can customers continue banking if Cloud A fails?

Data integrity

Can the bank prove that replicated information has not been altered?

Privacy

Is sensitive information retained longer than necessary?

Exit

Can the bank migrate away from either provider?

Subcontracting

Does either provider use undisclosed subcontractors?

51. Multi-Cloud Contract Checklist

A Kuwaiti bank's cloud agreement should ideally address:

service description;

data ownership;

confidentiality;

security standards;

encryption;

access controls;

location of data;

subcontractors;

audit rights;

regulatory access;

incident notification;

business continuity;

disaster recovery;

service levels;

data portability;

termination;

data return;

secure deletion;

transition assistance; and

liability and indemnity.

52. Multi-Cloud Risk Register

A bank can maintain a specific cloud risk register covering:

53. Stress Testing

Banks should test scenarios such as:

Scenario 1

Cloud A becomes unavailable for 12 hours.

Scenario 2

Cloud A suffers a cybersecurity incident.

Scenario 3

Both Cloud A and Cloud B lose access to the same telecommunications provider.

Scenario 4

A cloud provider becomes insolvent.

Scenario 5

A foreign jurisdiction issues a legal order concerning stored banking data.

Scenario 6

A cloud subcontractor suffers a security breach.

Scenario 7

Encryption keys become inaccessible.

Scenario 8

The bank must migrate a critical application within a short period.

These tests reveal whether multi-cloud resilience is real or merely theoretical.

54. Internal Audit

Internal audit should independently evaluate:

cloud governance;

risk assessments;

contracts;

security controls;

access;

logging;

incident response;

business continuity;

recovery testing;

vendor monitoring; and

exit planning.

The audit should not merely review whether the cloud provider has a certification.

It should examine whether the bank's own controls actually work.

55. Regulatory Reporting

A material cloud incident can become a regulatory issue.

Banks should therefore maintain procedures for determining:

whether an incident is material;

whether CBK notification is required;

what information must be supplied;

who approves the notification; and

how follow-up reporting is handled.

The bank should also maintain evidence showing when the incident was discovered and how it was handled.

56. Relationship With Operational Risk

Cloud failure is a classic operational-risk issue.

It can affect:

systems;

people;

processes;

third parties;

data;

payments; and

customer service.

The newer CBK CORF's focus on operational resilience therefore makes cloud risk a central part of broader banking-risk management.

57. Relationship With Cybersecurity

Cybersecurity is one component of cloud risk.

A bank can have a secure cloud environment and still experience:

contractual failure;

provider insolvency;

data-location problems;

regulatory-access problems;

portability failure;

operational concentration; or

recovery failure.

Therefore:

Cloud risk ≠ cybersecurity alone.

It includes legal, operational, financial, contractual and regulatory dimensions.

58. Current 2026 Regulatory Position

The most significant recent development is the CBK's Cyber & Operational Resilience Framework, launched for local banks and financial institutions in December 2025.

CBK describes it as an updated framework replacing the foundational 2020 cybersecurity approach with a resilience-first model.

In 2026, CBK has continued emphasizing cloud-security capability. Its Advanced Cybersecurity Leaders Program specifically includes cloud-environment security and training designed to strengthen the banking sector's resilience to risks associated with modern information systems.

This indicates that cloud security is now firmly integrated into Kuwait's broader banking-resilience strategy.

59. Legal Principles for Multi-Cloud Banking

The Kuwait framework can therefore be reduced to ten principles:

Principle 1 — Accountability

The bank remains responsible for outsourced banking functions.

Principle 2 — Confidentiality

Customer and banking information must remain protected.

Principle 3 — Controlled Access

Only authorized persons should access sensitive information.

Principle 4 — Resilience

Critical banking services must be capable of surviving disruption.

Principle 5 — Third-Party Oversight

Cloud providers and subcontractors must be monitored.

Principle 6 — Regulatory Access

Cloud arrangements must permit the bank to satisfy CBK requirements.

Principle 7 — Data Integrity

Electronic records must remain reliable and authentic.

Principle 8 — Business Continuity

The bank must be capable of restoring critical services.

Principle 9 — Exit Capability

The bank should not become irreversibly dependent on one provider.

Principle 10 — Board Oversight

Cloud risk must form part of enterprise-level banking risk governance.

60. Conclusion

Multi-cloud risk management in Kuwaiti banking is governed by a combination of CBK banking supervision, cybersecurity and operational-resilience requirements, electronic-transactions law, credit-information confidentiality, banking secrecy and general contractual law.

The regulatory environment has become significantly more sophisticated. The original CBK Cybersecurity Framework emphasized governance, risk management, compliance, technology and operations, third-party security, electronic-payment protection and cyber-risk assessment.

The newer Cyber & Operational Resilience Framework moves further toward a resilience-first model requiring regulated entities to anticipate, withstand, recover from and adapt to operational and cyber disruptions.

For a Kuwaiti bank using multiple cloud providers, the principal legal obligations can be summarized as follows:

The bank retains responsibility even when technology is outsourced.

Customer and banking information must remain confidential.

Credit information receives specific statutory confidentiality protection.

Electronic records must remain reliable and legally usable.

Cloud-provider access must be strictly controlled.

Third-party and subcontractor risks must be actively managed.

The CBK must be able to obtain information required for supervision.

Critical banking functions require tested continuity and recovery arrangements.

Multi-cloud architecture should address common dependencies and concentration risk.

The bank should maintain a practical exit and migration strategy.

The relevant Kuwaiti judicial principles include the Court of Cassation decisions reported as Administrative Appeals Nos. 226/2019 and 2277/2018 and Civil Appeal No. 2568/2020, together with established banking-confidentiality, electronic-record and credit-information principles. These cases do not purport to be “multi-cloud cases”; rather, they establish the underlying legal principles that become applicable when those protected interests are processed through cloud infrastructure.

The central legal proposition is therefore:

A Kuwaiti bank may outsource computing infrastructure, but it cannot outsource its responsibility for confidentiality, security, regulatory compliance, operational resilience and protection of customers.

Multi-cloud architecture can strengthen resilience, but only when it is supported by effective governance, contractual controls, security measures, regulatory access, tested recovery arrangements and a credible exit strategy.