I. SCOPE OF THE ISSUE

Law No. 6698 on the Protection of Personal Data (KVKK) classifies every actor that processes personal data into one of two fundamental categories: data controller or data processor. This distinction directly determines which obligations arise for a SaaS company, who will be accountable to the Board in the event of a data breach, and where liability boundaries are drawn in B2B contracts.

In practice, modern SaaS architectures such as multi-tenant databases, integrated APIs, and usage analytics layers blur the boundaries of these two categories. For example, a CRM platform will be a data processor with respect to the contact lists uploaded by its customer, while being a data controller with respect to the session logs and click heatmaps that it records on its own initiative.

It is frequently observed that companies that have not identified this hybrid structure preemptively designate themselves solely as data processors in their B2B business processes. This assumption does not reflect the legal reality and may give rise to commercial problems. The first-time identification of this problem by a prospective enterprise customer will considerably prolong the completion of the sales process or will result in the sale not materializing entirely. During investment rounds, an incorrectly structured data flow will be flagged as a red flag in the due diligence report.

II. LEGAL FRAMEWORK

A. Data Controller

Article 3 of the KVKK defines a data controller as the natural or legal person who determines the purposes and means of processing personal data and is responsible for the establishment and management of the data filing system. In other words, the party that makes the ultimate decision regarding which data will be collected, for what purpose, and by what technical method is the data controller. The party that determines which fields will be mandatory in an API endpoint will be classified as the data controller.

The clearest examples of pure data controllership in SaaS companies are data collected by the company\'s own commercial will and independently of any customer instruction. The SaaS company is indisputably the data controller with respect to data such as the first name, surname, email address, and password information entered by users when creating a platform membership, address information, non-anonymized session logs, click heatmaps, and error tracking data recorded for product development purposes, as well as cookie data and newsletter subscriptions collected for marketing purposes. No third-party instruction is involved in these data; the collection decision, processing purpose, and retention period are determined entirely by the company itself.

B. Data Processor

Pursuant to Article 3/1-g of the KVKK, a data processor is the party that processes personal data on behalf of the data controller based on the authority granted by the data controller. The data processor does not have an independent processing purpose; it stores, processes, or transfers data in accordance with instructions received from the customer, such as API calls, webhook triggers, and UI commands. If a customer\'s end users\' telephone numbers are being stored in the SaaS company\'s PostgreSQL database, the processing purpose and disposal authority over such data shall belong to the customer. The SaaS company may only process this data in accordance with the customer\'s instructions.

C. Joint Data Controller

This concept, which was not explicitly regulated in the original text of the Law, was introduced into Turkish legal practice by the Personal Data Protection Board\'s Decision No. 2021/1303 dated 23.12.2021. In this decision, in which the Board examined blacklist software in the vehicle rental sector, it determined that the software company and the rental firms jointly exercised control over the data, deeming both parties to be joint data controllers. The significance of this decision for SaaS is substantial: the use of buyer data by both the seller and the platform for independent purposes on a marketplace platform gives rise to the same joint controllership structure.

III. ROLE DETERMINATION IN SAAS ARCHITECTURE WITH PRACTICAL EXAMPLES

The following assessments address the most common data flows in contemporary SaaS companies. For each flow, both the legal role and the processing condition under Article 5 of the KVKK must be determined together; role determination cannot be considered independently of the processing condition.

Data Accessed/Accessible by the SaaS Company: This is one of the points where data processing companies most frequently fall into error. The fact that a SaaS company does not routinely access customer data does not eliminate its data processor status. The technical availability of access to the customer\'s personal data during software updates, bug fixes, database maintenance, or technical support processes is sufficient for the SaaS company\'s data processor status to arise. As emphasized in the Board\'s decisions, the assignment of users with admin privileges within the software company and the hosting of database management within its infrastructure gives rise to the processor status and associated obligations, even if the data has not been actually accessed.

Data uploaded by the customer to the platform (HR records, CRM contact lists, customer support history): The SaaS company is in the position of data processor with respect to such data. The ownership of the data, the processing purpose, and the fate of the data belong to the customer; the software serves merely as a means. The processing condition depends on the customer\'s own legal assessment.

Data collected by the platform itself (usage analytics, session logs, error tracking, admin panel authorized user information): The SaaS company is the data controller with respect to such data. This data is collected at the company\'s own initiative for the purposes of product development, SLA monitoring, and detection of security vulnerabilities. Any data that cannot be anonymized at the point of collection and that can at any time be linked to a user account, and thus can be positioned as part of personal data, shall be classified as "personal data" within this category.

Use of customer data in model training: This scenario is an increasingly common and legally the most risky area in the SaaS sector. The moment customer data is taken beyond the scope of the customer\'s instructions and used for an independent commercial purpose (e.g., training an artificial intelligence model or selling anonymized insight reports), data processor status is lost and data controller status is assumed. A critical distinction must be made here: anonymization under the KVKK is subject to the standard of irreversibility. Data that is genuinely anonymized ceases to be personal data and falls outside the scope of the Law; however, it is critically important at this point that the anonymized data cannot under any circumstances be linked back to the data subject. If data that has been rendered anonymous can subsequently be linked to the data source individual by any means whatsoever, it shall be deemed that the data has not been anonymized.

Direct service to the end user (B2C): The contractual relationship is established directly between the company and the individual. All obligations classified among the data controller\'s obligations, including the disclosure obligation and the implementation of security measures to ensure data security, must be fulfilled entirely by the SaaS company.

IV. Data Processing Agreement (DPA)

A. Legal Basis

Unlike Article 28 of the GDPR, the KVKK does not contain an express provision mandating a written agreement between the data controller and the data processor. However, the second paragraph of Article 12 of the Law effectively fills this gap: "Where personal data is processed by another natural or legal person on behalf of the data controller, the data controller shall also be jointly liable with such person."

This joint liability provision has two direct consequences for SaaS companies. First, the misconception that all liability rests with the data owner due to the data processor status is, on its own, invalid; in the event of a data leak caused by a security vulnerability at the SaaS company (misconfigured S3 bucket, inadequate encryption, insufficient access controls), the Board may also impose an administrative fine on the SaaS company under Article 12/2. Second, where the boundaries of liability are not delineated by a written DPA, it remains uncertain in the event of a breach which party assumes which obligation, and both parties face the risk of being held liable for the maximum penalty.

B. Minimum Content of the DPA

The following mandatory elements must be included in a B2B SaaS company\'s DPA:

Express declaration of roles (separately for each data category if a hybrid structure exists);

The SaaS company\'s undertaking that it will process data solely in accordance with the customer\'s documented instructions;

Confirmation that all personnel with database access are bound by confidentiality agreements (NDA) and that industry-standard technical measures (AES-256, RBAC, MFA, TLS/SSL) are implemented;

Maintenance of a current list of sub-processors used (AWS, SendGrid, MongoDB Atlas, etc.) publicly available via a URL, and notification to the customer at least 30 days prior to any additions to the list;

Express stipulation of the SaaS company\'s timeframe for informing the customer in the event of a security breach (e.g., no later than 48 hours from detection);

Commitment to provide the customer with API endpoints or interface tools for the management of data subject requests under Article 11 of the KVKK (access, rectification, erasure, portability).

C. Put Beyond Use Principle at Contract Termination

A frequent error in DPAs is the inclusion of an absolute undertaking at the end-of-contract procedure stating that "all customer data, including backups, will be permanently deleted." This statement is incompatible with the technical realities of SaaS infrastructure: it is not possible to selectively and immediately delete a single tenant\'s data from AWS RDS snapshots or immutable log archives. Making such an undertaking directly exposes the company to a risk of breach of contract.

The industry-standard approach that should be applied is the "Put Beyond Use" principle: upon termination of the subscription, customer data in active systems is deleted immediately; data in backup systems is rendered inaccessible, isolated, and not restored to active systems until the regular overwrite cycle is completed. During this period, such data shall not be accessed, processed, or shared with third parties.

V. LIABILITY DISTRIBUTION IN THE EVENT OF A BREACH

In a data breach scenario, notification obligations differ according to role determination. The party in the capacity of data controller is obligated to notify the Board within 72 hours at the latest from the moment it becomes aware of the breach. Notification to data subjects is a separate obligation and must be made "within the shortest reasonable time"; the two periods are subject to different standards.

The SaaS company in the capacity of data processor does not have a direct notification obligation to the Board. Its legal duty is to inform its customer (the data controller) without delay upon detecting the breach. However, the joint liability provision of Article 12/2, as discussed above, also applies here: if the security vulnerability that caused the breach originates from the SaaS company\'s infrastructure, the notification obligation shall rest with the SaaS company to the same extent as with the customer. For this reason, it is essential to establish a written Incident Response Plan within the company and to include documentation of the measures under Article 12/2 in such plan.

VI. CONCLUSION AND RECOMMENDATIONS

The first step that SaaS companies must take toward KVKK compliance is to read their technical architecture through the lens of legal roles, preparing a Data Flow Diagram that labels, at the database table level, the ownership of every data element passing through servers and API gateways, the purpose for which it is retained, and the legal role to which it corresponds.

Once this mapping is completed, a DPA must be prepared as an integral annex to the service agreement offered to B2B customers, one that expressly defines the hybrid role, manages the joint liability risk under Article 12/2, and regulates the end-of-contract procedure in a manner consistent with technical reality. The transparent public disclosure of the sub-processor list, the establishment of a notification and objection mechanism for customers upon changes, and the documentation of all technical measures taken through independent audit reports (ISO 27001 or SOC 2 Type II) are mandatory for preparedness in both Board audits and enterprise sales processes.

Finally, it should be noted that under the Medium-Term Programme for the 2026-2028 period, legislative efforts to bring the KVKK into full alignment with the GDPR are targeted for completion within 2026. This regulation is expected to increase the data processor\'s direct criminal liability, make the DPA requirement explicit at the level of statutory law, and expand supervisory powers. Proper structuring undertaken today represents preparation for tomorrow\'s regulation.