KVKK Cross-Border Data Transfer: What to Check When Using the Cloud

Short answer: Using a cloud service whose servers sit abroad is a data transfer under KVKK, Türkiye's personal data protection law, and it needs its own legal basis. The most commonly missed point is backups: an architecture with production data in Türkiye and its backup in another country has solved only half the problem.

We hear "our data is in Türkiye" often. When we ask, it usually refers to where the production database lives. So we keep going: where are the backups? Which service do the logs go to? Where does the support team connect from? The answers frequently point to different countries.

This article covers where an organization using the cloud should look, from a transfer perspective.

Where a transfer begins

Writing personal data to a server abroad is a transfer. But it is not the only one. Four channels get missed in practice:

Backups and replicas. If your disaster recovery copy is abroad, the data is abroad. Most organizations get production right and skip this side.

Logs and telemetry. Error tracking services, product analytics, even some monitoring tools can carry personal data, and they usually send it abroad. If an error record contains an email address or an IP, that record contains personal data.

Remote support access. If your vendor's support team abroad connects to the system and accesses data, that is a transfer too, even when the data never physically moves.

SaaS integrations. CRM, email, file sharing, even a forms tool. Most are hosted abroad, and nobody files them mentally under "data transfer".

Which mechanism are you transferring under?

An important change landed here in 2024, and many organizations are still working from the old picture. The Regulation on Procedures and Principles for the Cross-Border Transfer of Personal Data was published in the Official Gazette on July 10, 2024 and entered into force on publication, clarifying the transfer instruments.

The order matters. An adequacy decision comes first: if you are transferring to a country the Board considers to provide adequate protection, no further instrument is needed. Where no such decision exists, you move to instruments providing appropriate safeguards:

Standard contracts. Four models were developed by the Board's decision of June 4, 2024, chosen according to the parties' roles: controller to controller, controller to processor, processor to processor, and processor to controller. The text cannot be modified.Binding corporate rules. For transfers within the same group of undertakings, subject to Board approval.An undertaking with Board authorization. The slower route.

The standard contract carries an operational trap, and this is where most organizations stumble: signing it is not enough. Notification to the Board is mandatory within five business days of signature. Miss that window and the basis itself becomes questionable. Because cloud contracts are signed in the legal department and brought into service on the IT side, the notification falls between the two and gets forgotten.

The practical consequence: cross-border transfer is no longer a one-off legal matter but a process with a clock. Every new SaaS subscription may also start a five-business-day counter.

Two further warnings:

Explicit consent is not an operational solution. Consent can always be withdrawn, and if an employee withdraws it you have to remove that person's data from your cloud system. Basing an infrastructure decision on a revocable permission produces a fragile arrangement. The regulation reserves explicit consent for exceptional and occasional cases.

Mechanism selection is not a one-time exercise. Country assessments and Board decisions can change; a basis that is valid today may need review in two years.

What to insist on in the contract

These clauses, written into the contract with your cloud vendor, are what will serve you in an audit:

Country and facility where data resides. Not at region level, at facility level where possible. "European region" does not tell you which country.

Backup location. As a separate clause. Do not assume it falls under the same commitment as production.

Sub-processor list and change notification. Your vendor may use its own vendors. That list should be provided, and changes to it notified to you.

Support access policy. Who can access your data, from which country, under what circumstances. Whether that access is itself logged.

Breach notification window. How quickly you are told about a data breach. You have your own notification deadline to the Board; if your vendor tells you late, you cannot meet it.

Return and deletion at contract end. How your data comes back when you leave, when copies are deleted, and how that deletion is evidenced.

None of it works without a data inventory

Every clause above assumes you know which data sits where. In most organizations that inventory either does not exist or was built once and never updated.

The most practical way to build one is to start from process rather than system: which systems does a customer record enter, which teams see it, where does it get copied? The technical inventory sits on top of that map.

Eclit's view

Data localization is regulation that favors providers operating local infrastructure in Türkiye, and we are on that side of it, so let us say so plainly. But "keep everything in Türkiye" is not the right advice.

The right approach is to classify the data: personal data and regulated data stay local, everything else goes wherever cost and capability are best. Pulling everything local creates unnecessary cost for workloads that have no compliance exposure; pushing everything abroad creates a compliance debt you cannot settle.

Drawing that line at the start is both cheaper and safer than separating later.

This article is general information, not legal advice. Determine your transfer mechanism and its legal basis with your own counsel, and consult the Turkish Data Protection Authority's own publications for current Board decisions.