Turkey’s KVKK: Why Your Turkish Customer Needs Another Data Contract

TL;DR: Your Turkish customer may need a KVKK transfer arrangement that your existing GDPR documents do not provide. If the parties use a Turkish standard contract, both must sign the Turkish text, provide the required supporting documents and arrange notification within five business days of both parties signing. Check that the actual service can meet the commitments before accepting the data. Filing the contract does not certify the whole service as compliant.

Imagine you run a software company in Germany. A Turkish retailer wants to use your customer-management platform. Your team sends its usual service agreement and data-processing agreement. The customer comes back with a Turkish contract, questions about your subcontractors, and a request for proof that the person signing can represent your company.

You already handle GDPR requirements. Why does this customer need another agreement?

Turkey has its own Personal Data Protection Law, Law No. 6698, commonly called the KVKK. When a Turkish business sends personal data to a provider abroad, it needs an arrangement that meets the Turkish transfer rules. Your participation may be needed to complete that arrangement.

For a foreign provider, this is worth checking before agreeing a launch date. A service can meet the customer's functional requirements while the two companies are still unable to complete the necessary contract.

Why your existing GDPR documents may not answer the request

Turkey revised its international-transfer rules in 2024. The framework provides for adequacy decisions by Turkey's Personal Data Protection Board, specified safeguards where no adequacy decision applies, and limited exceptions for incidental, non-routine transfers.

As of 23 September 2026, the Authority's Turkish transfer page states that the Board has not yet designated countries providing adequate protection. A provider should therefore ask which Turkish transfer mechanism the customer intends to use. Being based in the EU does not itself supply a Turkish adequacy decision.

A Turkish standard contract is one available safeguard. Other routes have their own conditions: a written undertaking needs Board permission, while binding corporate rules require Board approval and concern transfers within a qualifying group. Naming a route in a privacy policy does not satisfy its conditions.

If the parties choose the standard-contract route, they need the text published by the Turkish Board. An existing GDPR agreement or EU standard contractual clauses do not, by themselves, fulfil that requirement. A consent checkbox does not by itself establish that daily transfers to an overseas platform qualify for those exceptions.

The transfer mechanism also leaves the underlying processing requirements in place. There must be an applicable processing condition under Article 5 or 6; the safeguard route additionally requires enforceable rights and effective legal remedies in the destination country. The Authority publishes an English version of the amended law.

Identify the companies and the data flow first

In the retailer example, assume the Turkish company decides why it collects customer records and the German provider processes them only on its instructions. For that activity, the retailer is the controller and the provider is the processor, following the Board’s explanation of the two roles. The retailer sends the data as the exporter; the provider receives it as the importer.

Those roles matter because the Authority publishes four standard-contract types, with English translations: controller to controller, controller to processor, processor to processor, and processor to controller. Choose the type that describes the activity. Calling your company a processor in its sales terms does not settle the role for every use of the data.

Suppose instead that your group owns the retailer's Turkish operating company. If that company determines how customer or employee records are used, it has controller responsibilities for those activities, including lawful processing, transparency and security. Sending records to a separate overseas group company raises the transfer question as well. Common ownership does not make the movement domestic.

Also check access, not just storage. The transfer by-law covers making data accessible to a separate controller or processor abroad. For example, a Turkish hosting location does not resolve the transfer question if a separate overseas support company processes those records through remote access.

The position of each company depends on its actual activities. Establish which entity does what before assigning obligations.

Read the commitments before agreeing to sign

The controller-to-processor contract gives the foreign recipient substantial responsibilities. They include following the customer's instructions, restricting staff access, providing security measures, assisting with breaches and demonstrating compliance.

Its annexes describe the actual transfer: the people and data involved, purposes, frequency, retention and safeguards. Subprocessors and onward transfers have conditions of their own. The arrangement needs to account for the other companies that will receive or process the records.

The contract also provides for cooperation with the Turkish Authority, Turkish governing law and Turkish courts. Its terms prevail over conflicting provisions in other agreements between the parties. Your team must also assess whether local laws or practices conflict with those commitments. Legal and operational colleagues need to examine them together.

For example, if your platform's standard configuration gives another provider access to customer records, your team needs to establish how that provider fits the proposed arrangement. Signing a contract whose annexes describe a different service would leave the practical problem unresolved.

The internal review should include people who understand how hosting, support and deletion work in practice. They can identify promises the service can meet, changes it would require, and commitments the business cannot accept.

Why the Turkish text and company documents matter

The Authority's execution guidance explains several requests that may otherwise seem unusual to a foreign supplier:

• Both parties must sign the Turkish text. An English version can help with review, but signing only that version is insufficient. In a bilingual, two-column document, both signatures must appear in the Turkish column.
• The signatories need documented authority. Supporting documents must identify the people authorised to represent and sign for the named companies. A local reseller's involvement does not automatically give it authority to sign for an overseas provider.
• Foreign documents may need additional formalities. Foreign-language documents submitted to the Authority require notarised Turkish translations. Foreign public documents may also require an apostille or legalisation, depending on their origin and applicable exemptions.
• The standard wording cannot be freely rewritten. Changes are limited to the selectable or alternative provisions; the required service details still need to be completed.

Agree on the signature method early. Turkish law recognises a qualifying secure electronic signature as equivalent to handwriting, but recognition of foreign certificates has conditions. The Turkish communications regulator's English guidance explains that distinction. Check that the proposed method meets the contract’s execution requirements. Do not assume that every electronic-signing service qualifies, or that wet ink is the only possible route.

Decide who will file the signed contract

The parties have five business days after all signatures are completed to notify the Authority. Under the by-law, they can specify which party will handle notification; if they do not, responsibility falls to the exporter.

The standard-contract notification module provides an electronic submission route. This is notification of the executed contract, rather than a declaration of the server's country. The standard-contract route does not require separate Board permission, and filing does not certify the whole service as compliant.

Arrange the document handover before signing so the filing party has what it needs within the deadline. The by-law also requires notification of changes to the parties or contract information and when the contract ends. Someone needs to own that follow-up after onboarding.

What to settle before accepting the customer's data

Start by asking for the proposed contract and a description of the intended data flow. Then bring legal and service-delivery colleagues into the same discussion:

• Which companies are sending, receiving and processing the data, and for what purposes?
• Can the actual service meet the contract, including the arrangements for other providers?
• Can authorised representatives sign the Turkish text and supply the required evidence?
• Who will coordinate filing and changes, and can the work be completed before the planned transfer begins?

A signed transfer contract still leaves questions about lawful use, notices, consent where required, security and any sector-specific restrictions. Transfers in the other direction may also need a separate GDPR assessment. This article addresses the Turkish customer's document request, rather than every obligation involved in entering the Turkish market.

The practical value of raising these questions early is straightforward: both parties can decide whether the service is workable before migrating records or making commitments to users. If the provider cannot support the required arrangement, that belongs in the purchasing decision while alternatives are still easy to consider.