BDDK Treats Cloud as Outsourcing: What Changes for Banks
Primary and secondary systems must sit in Türkiye, and that extends to the supplier's systems. Private cloud, community cloud, and the 24-hour recovery requirement.
Short answer: Under BDDK regulation, buying cloud services counts as "outsourcing." Buying a service from a third party does not transfer the obligation; in a breach or an outage, the regulator holds the bank itself accountable, not the cloud provider. Public cloud use is also limited for banks: only private cloud and community cloud models are permitted.
The framework is set by the Regulation on Information Systems and Electronic Banking Services of Banks. This article focuses on the cloud and outsourcing side, because that is the part most often misread in practice.
The two strictest clauses: location and time
Most of the cloud debate comes down to two provisions.
Systems must be located inside Türkiye. This applies to banks' primary systems and to the secondary systems holding data and system backups. The real impact comes from the regulation's next sentence: if a bank buys an outsourced or cloud service for an activity covered by its primary or secondary systems, the information systems the provider uses to deliver that service, and their backups, are treated as being within the same scope and must also be held domestically.
So the question is not "Where is my data?" but "Where are the systems my supplier runs this service on, and where are their backups?" Those are different questions, and the second is rarely written into a contract.
Twenty-four hours after an outage. Even in disaster scenarios where primary systems are entirely out of action, operations must be able to resume within 24 hours at the latest. That turns RTO from a preference into a ceiling; we covered how to derive the target in how to calculate RPO and RTO, but in banking the upper bound is already written down.
Evidence for the 24 hours is also required, and a plan alone is not enough: you need the record of a drill. We set out the method in the disaster recovery failover test guide.
What outsourcing changes
Outsourcing a service does not relieve a bank of its legal and operational responsibility for it. In day-to-day terms: you have to know what your supplier does, and you have to be able to document it.
The most common gap we see is in the contract's technical annex. Service levels get written down, price gets written down, but audit rights, log access and incident notification times usually do not. When an audit arrives, the record demanded from the bank sits with the supplier, and the supplier's obligation to hand it over is not defined in the contract.
Four questions to ask when selecting a supplier, before you discuss price:
How quickly can I get to my records? In a security incident, how quickly and through which channel will you notify me? Can my auditor inspect your facility? Where are the systems running this service, and their backups, physically located?
Private cloud and community cloud
The regulation defines two cloud models for banks:
Private cloud, where hardware and software resources are dedicated to a single bank.
Community cloud, where resources are physically shared across several banks but logically allocated separately to each, and which serves banks only.
The critical phrase there is "serves banks only." A logically separated area inside a general-purpose cloud provider does not meet that definition. This limits how directly hyperscale providers can be used for banking workloads and favors local providers that run infrastructure dedicated to banking.
Data localization and cross-border transfer
The regulation contains provisions on the transmission and security of personal and sensitive data, on queries made against that data and the records of those queries, and on limiting cross-border transfer. We covered the general KVKK regime in KVKK and cross-border data transfer.
In practice this requires the answer to "where does our data sit" to be written into the contract at facility level, not at region-name level. The same applies to where backups are kept; an architecture that keeps production data in Türkiye and its backup abroad has solved only half the problem.
What to have ready before an audit
The four items most often found missing:
Log inventory and retention. What is collected from which system, how long it is kept, and how many hours it takes to produce on request. For the required periods, see log retention periods.
Authorization matrix. Who has what level of access to which system, and the record of periodic review. Auditors look especially closely at whether privileged accounts are separated.
Outsourcing inventory. Which service is bought from which supplier, what data it touches, what commitments the contract carries, and where the systems sit.
Recovery drill record. Proof that the plan works: drill date, measured time, and a report of whatever went wrong. The measured time must be under 24 hours.
If you work with an MSP
Using a managed service has two effects here. On the positive side, three of the four items above are outputs the supplier should already be producing. On the negative side, if the supplier does not produce them or does not give them to you, the gap stays with you at audit. We set out how to test a supplier on this basis in 10 questions to ask when choosing an MSP.
Instead of asking whether your cloud provider is secure, ask: If my auditor turned up tomorrow, which document could I get from my supplier, and how fast?
Sources
- Regulation on Information Systems and Electronic Banking Services of Banks: primary/secondary systems, the domestic location requirement, and outsourcing provisions
This article is general information, not legal advice. For the regulation text and current audit guidance, we recommend consulting BDDK's own publications and your organization's legal team.