Guide To Data Controller and Data Processor Agreements in Cloud Computing Under The KVKK

The fact that a cloud service can be deployed with just a few clicks does not mean that the risks concerning personal data are equally simple. When a broad set of data, ranging from customer records to employee files, is transferred to another infrastructure, technical convenience may turn into significant legal and commercial uncertainty unless the contract clearly specifies who makes decisions, who acts on instructions and who must take what action in the event of a security incident. A robust cloud agreement does more than procure a service; it governs the entire data lifecycle.

How Is the Distinction Between a Data Controller and a Data Processor Made in Cloud Computing?

Under Personal Data Protection Law No. 6698 (KVKK), a data controller is a natural or legal person who determines the purposes and means of processing personal data and is responsible for establishing and managing the data filing system. A data processor is a natural or legal person outside the data controller’s organisation who processes personal data on behalf of the data controller and in accordance with its instructions, based on the authority granted by the data controller.

This distinction is based not on labels such as ‘provider’, ‘business partner’ or ‘data processor’ in the agreement, but on actual decision-making authority. Where the customer decides which data will be collected, from whom, for what purposes, with whom they will be shared and how long they will be retained, the customer is generally the data controller. The provider’s selection of technical details concerning storage methods, infrastructure architecture or security tools does not, in itself, make it a data controller.

Indeed, in its decision dated 22 February 2024 and numbered 2024/284, the Personal Data Protection Board accepted that a technical service provider which does not determine the processing purpose, data categories or retention period may be classified as a data processor. Likewise, in the cloud computing example in the Personal Data Protection Authority’s Guideline on Data Controllers and Data Processors, a provider which stores the customer’s data solely in accordance with the customer’s instructions and cannot use them for its own purposes is a data processor.

However, the same legal entity may assume different roles in different activities. A cloud company is a data processor when hosting a customer’s data on instructions, but a data controller in relation to its own employees’ data. More importantly, if it begins using customer data for independent purposes such as product development, targeted advertising, its own analytics or training artificial intelligence models, a separate data controller role may arise in respect of such use. Such a purpose should not be concealed within a general reference to ‘improving the service’; the role, legal basis, information obligations and implications for data transfers must be assessed separately.

Can Responsibility for Data Security Be Transferred to the Cloud Provider?

Even if a data controller outsources the cloud infrastructure and a substantial part of its operations, it cannot transfer all its responsibilities under the KVKK to the provider. Article 12 of the Law imposes on the data controller the obligations to prevent unlawful processing and access, safeguard the data and ensure an appropriate level of security. Where personal data are processed by another person on behalf of the data controller, the data controller and the data processor are jointly responsible for taking the necessary measures.

Accordingly, an agreement is not a shield that eliminates statutory public-law responsibility. It defines duties, regulates audit and documentation processes, establishes the relationship between service levels and compensation and strengthens the parties’ rights of recourse against each other. The provider’s information security certification or high-availability commitment likewise does not replace the customer’s risk assessment and audit obligations.

Unlike Article 28 of the European Union General Data Protection Regulation, the KVKK does not contain a general list of mandatory clauses with the same level of detail for all data processing agreements. Nevertheless, Article 12 of the Law, the accountability approach, Board decisions and the Authority’s security guidance make the establishment of the processing relationship through written, measurable and auditable provisions a strong risk management necessity.

Contractual Structure in Cloud Service Procurement: DPA, SLA and Security Annexes

Adding a few scattered data protection provisions to a single master services agreement will not suffice for many cloud procurements. The documents may be structured in the following layers, with an order of precedence that prevents conflicts:

• List of Sub-Processors and Locations: Identifies data centres, support locations, backup regions and subproviders.
• Data Processing Agreement: Defines the roles, limits of instructions, data categories and security and compliance duties.
• Service Level Agreement (SLA): Makes availability, performance, support and remedies for service interruptions measurable.
• Master Services Agreement: Governs the scope of services, fees, term, intellectual property rights, general liability and termination.
• Information Security Annex: Specifies technical details of controls such as encryption, multi-factor authentication, logging, backups, vulnerability management and incident response.

It should be clear which document prevails in the event of a conflict between the main agreement and an online policy. The provider’s ability to amend the terms on its website unilaterally may result in changes to the security level, sub-processors or data locations without the customer’s knowledge. Establishing mechanisms for prior notification, objection or termination for cause in the event of material changes mitigates this risk.

Key Provisions Recommended for Inclusion in a Cloud Data Processing Agreement (DPA)

Purpose of Processing, Limits of Instructions and Prohibitions on Secondary Data Use

The agreement should describe the subject matter of processing, duration of services, purposes, types of processing, categories of data subjects and categories of data. It should specify who may issue instructions, through which channels and how the provider should act when it considers an instruction to be contrary to applicable law.

It should expressly state that the provider will use the data solely to deliver the service; secondary purposes such as product development, advertising, independent profiling or artificial intelligence training should either be prohibited or made subject to a separate legal assessment. References to aggregation and anonymisation must not create uncontrolled permission for use; data that can be reversed or linked to individuals are not considered anonymous.

Access Controls, MFA and Technical and Organisational Security Measures

Access to data should be restricted to persons with a need to know for their duties; authorisation, periodic access reviews and staff confidentiality obligations should be regulated. The support team’s access to production data should not be taken for granted but should be subject to approval and logging mechanisms.

Technical and organisational measures should not be left to an abstract reference to ‘industry standards’. Depending on the level of risk, the following matters may be set out in measurable terms:

• Encryption of data in transit and at rest and key management
• Vulnerability, patch, malware and penetration-testing processes
• Backups, restoration tests and controls against synchronisation errors
• Business continuity, disaster recovery objectives and periodic exercises
• Monitoring of access and administrator activities through tamper-proof logs
• Multi-factor authentication, privileged-account controls and role-based access management

The audit clause should cover the provision of certificates and independent reports, additional information and reasonable on-site audits in high-risk situations or following an incident and deadlines for remediation of findings. Audit rights may be exercised through a proportionate procedure that does not jeopardise other customers’ confidential information or system security.

Management of the Sub-Processor Chain and Mechanisms for Objecting to Changes

Cloud services often rely on a chain comprising data centres, call centres, monitoring, email and support companies. Existing sub-processors, their responsibilities and the locations of their activities should therefore be listed in an annex. The agreement should establish a prior notice period for appointing a new sub-processor, the customer’s right to object on reasonable grounds and the possibility of termination or an alternative service where the risk cannot be resolved.

The principal provider should impose on its sub-processors data protection and security obligations at least equivalent to those it has undertaken. The existence of a subcontract should not make the customer’s primary counterparty unclear; the principal provider should retain contractual responsibility for management of the chain and breaches within it.

Cloud Data Breach Notification: The 72-Hour Rule and Incident Response

Where personal data are obtained by others through unlawful means, the obligation to notify the Board rests with the data controller. Under Board Decision No. 2019/10, the data controller must notify the Board without undue delay and within no more than 72 hours of becoming aware of the breach. This 72-hour period should not be drafted as though it were an independent Board notification deadline directly imposed on the data processor.

As the customer has very little time to assess and report a breach, the data processor should notify the data controller ‘without undue delay’ and within a short period, specified in hours in the agreement, from the moment it becomes aware of the breach. Even if the initial notification does not contain every detail, it should specify the time of the incident, affected systems and data, possible consequences, measures taken and a contact person. The preservation of logs, system images and other evidence, root-cause analysis, updates, support in notifying data subjects and coordination with public authorities should also be contractually regulated.

Provider Assistance with Data Subject Requests and Board Audits

Rather than responding to a data subject request in its own name, the provider should forward it promptly to the data controller and assist with locating, exporting, rectifying, restricting access to or deleting data. If response times, fees and technical capacity are determined in advance, workflows will not need to be redesigned when a request arrives.

The same assistance should be provided for Board information requests, audits, impact and risk assessments and breach investigations. The agreement should make clear which records the provider must produce, within what period and how it will communicate with the authorised teams.

Data Return, Secure Deletion and Destruction of Backups at the End of the Agreement

The retention period should comply with the customer’s instructions and legal requirements. Upon termination, the agreement should specify the open and usable format in which data will be returned and when data will be deleted from active systems, backups, replicated environments and sub-processors. For backups that cannot technically be deleted immediately, provisions may address isolation, non-reuse, the period for overwriting during the normal cycle and confirmation of deletion.

A record stating ‘account closed’ does not, by itself, prove that all copies have been securely deleted. The file should contain a deletion report or confirmation from an authorised person, the legal basis for any retention exception and access restrictions applicable during the exception period.

International Data Transfers and Standard Contracts in Cloud Computing

Selecting a data centre in Türkiye does not guarantee that all access will remain within Türkiye. If support personnel abroad, a global management console, a foreign sub-processor, a disaster recovery centre or a backup region can access personal data, an analysis of international transfers under Article 9 of the KVKK may be necessary. The data-residency option should therefore be examined together with the access map.

A commercial data processing agreement and the standard contract that constitutes one of the appropriate safeguards under Article 9 of the KVKK are not the same document. The former governs the allocation of roles, security, instructions and responsibilities within the service relationship; the latter establishes the legal mechanism for a particular international transfer. The Authority has published four types of standard contracts based on the roles of the parties to the transfer: controller to controller, controller to processor, processor to processor and processor to controller.

The appropriate standard contract should be selected according to the specific transfer chain and notified to the Authority within 5 business days following its execution. The applicability of an adequacy decision, binding corporate rules and other transfer mechanisms under the Law may also be assessed. Amending the text or merely referring to the provider’s foreign-law agreement does not, in itself, satisfy the formal and notification requirements under the KVKK.

Processing of Special Categories of Personal Data in the Cloud

Where health, biometric and genetic data, or other special categories of personal data listed in the Law, are processed, a general security package should not be regarded as sufficient. In line with the framework established by Board Decision No. 2018/10, separate policies and procedures, role-based authorisation, regular training, confidentiality undertakings and more frequent access reviews are required.

Data in electronic environments should be encrypted; cryptographic keys should be stored in secure, separate environments, and at least two-factor authentication and secure transmission channels should be used for remote access. Particular attention should be paid to the cloud provider’s access to keys, support sessions, administrator accounts and incident records. Use of the service in a high-risk process such as healthcare or human resources requires the security annex and specific contractual commitments to be tailored accordingly.

KVKK Compliance and Information Security Due Diligence Checklist for Cloud Provider Selection

A marketing presentation or a list of certifications does not, by itself, explain the actual data flow. Before accepting an offer, the business, legal, information security and procurement teams should complete at least the following checks:

• Have service levels been defined for data subject requests, Board requests and audits?
• Have encryption, key management, multi-factor authentication and logging been evidenced?
• Have the locations of data centres, backups, support access and sub-processors been mapped?
• Has data export been tested using an actual example, and are the format, time and cost acceptable?
• Is there a right to exit in the event of price changes, service interruptions or changes of sub-processors?
• Have the categories of data and data subjects to be processed been matched against the data inventory?
• Does any licence or product-development provision allow the provider to use the data for its own purposes?
• Is the breach notification process sufficiently prompt and effective to meet the customer’s 72-hour time frame?
• Have the international transfer mechanism and, where required, the type of standard contract been determined?
• Have the respective roles of the customer and provider been determined separately for each processing activity?

The answers to these questions reveal not only legal compliance but also operational sustainability and the total cost of migration.

Preventing Vendor Lock-in: Termination and Transition Management in Cloud Agreements

The most critical point in a cloud agreement is sometimes not entering into the service, but leaving it. The risk of vendor lock-in, also known as dependence on a provider, may effectively force a customer to remain bound by the agreement due to data being held in a proprietary format, high export fees, an inability to migrate application integrations or uncertainty regarding transition assistance.

The agreement should provide exit scenarios for ordinary termination, security breaches, repeated service interruptions, unlawful transfers and unacceptable changes of sub-processors. Parallel operation during the transition period, technical support, data format, integrity verification, delivery of logs and the period of cooperation should be determined in advance. Deletion should not begin until the completeness of the transfer to the new system has been verified.

Liability limitations should also be structured consistently with this stage. Whether a compensation clause capped at the total amount of fees is sufficient for risks such as a data breach, breach of confidentiality, unlawful independent use or failure to delete data should be separately negotiated. The scope, exclusions and policy limit of cyber risk insurance should be reviewed, and the existence of insurance should not replace contractual liability.

Manage Data Risks in Cloud Agreements from the Outset with Esenyel Partners

Unclear roles, undisclosed sub-providers and an ineffective exit plan may turn the cost advantage of cloud services into risks of data breaches, regulatory non-compliance and business continuity disruptions. These risks should be managed when data flows are being designed, rather than after procurement has been completed.

Esenyel Partners can assess the legal structure of cloud service procurement in conjunction with business needs, from role and transfer analyses to the preparation of data processing agreements and security annexes, and from supplier negotiations to incident and termination planning.

Before moving to a new cloud service or renewing your existing provider agreement, you may contact Esenyel Partners to review your data flows and contractual arrangements.

Contact