I. SORUNUN ÇERÇEVESİ
6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), kişisel veri işleyen her aktörü iki temel kategoriden birine yerleştirir: veri sorumlusu veya veri işleyen. Bu ayrım, bir SaaS şirketi için hangi yükümlülüklerin doğacağını, bir veri ihlalinde kimin Kurul'a muhatap olacağını ve B2B sözleşmelerde sorumluluk sınırlarının nerede çizileceğini doğrudan belirler.
Pratikte ise çok kiracılı veritabanları, entegre API'ler, kullanım analitiği katmanları gibi modern SaaS mimarileri bu iki kategorinin sınırlarını bulanıklaştırır. Örneğin bir CRM platformu, müşterisinin yüklediği kişi listeleri bakımından veri işleyen; kendi toplama inisiyatifiyle kaydettiği oturum logları ve tıklama haritaları bakımından ise veri sorumlusu konumunda olacaktır.
Bu karma yapıyı tespit etmemiş olan şirketlerin, B2B iş süreçlerinde peşinen kendilerini yalnızca veri işleyen olarak tanımladığı sıkça görülmektedir. Bu kabul, hukuki açıdan gerçeği yansıtmadığı gibi ticari açıdan problemler meydana gelebilecektir. Bu problemin ilk kez bir kurumsal müşteri tarafından tespit edilmesi, satış sürecinin tamamlanmasını kaydadeğer miktarda uzatacak veya tamamen satışın gerçekleşmemesine sebebiyet verecektir. Yatırım turlarında ise yanlış konumlandırılmış bir veri akışı, due diligence raporunda kırmızı bayrak olarak işaretlenecektir.
II. KANUNİ ÇERÇEVE
A. Veri Sorumlusu
KVKK m.3 veri sorumlusunu; kişisel verilerin işleme amaçlarını ve vasıtalarını belirleyen, veri kayıt sisteminin kurulmasından ve yönetilmesinden sorumlu olan gerçek veya tüzel kişi olarak tanımlar. Diğer bir deyişle hangi verinin, hangi amaçla, hangi teknik yöntemle toplanacağına nihai kararı veren taraf veri sorumlusudur. Bir API endpoint'inde hangi alanların zorunlu tutulacağını belirleyen taraf, veri sorumlusu olarak tanımlanacaktır.
SaaS şirketlerinde saf veri sorumluluğunun en net örnekleri, şirketin kendi ticari iradesiyle ve herhangi bir müşteri talimatından bağımsız olarak topladığı verilerdir. Kullanıcıların platforma üyelik açarken girdiği ad-soyad, e-posta adresi ve parola bilgileri, adres bilgileri, ürün geliştirme amacıyla kaydedilen ve anonimleştirilmemiş olan; oturum logları, tıklama haritaları ve hata izleme (error tracking) verileri; pazarlama amacıyla toplanan çerez verileri ve bülten abonelikleri gibi veriler bakımından SaaS şirketi tartışmasız veri sorumlusudur. Bu verilerde üçüncü bir tarafın talimatı söz konusu değildir; toplama kararı, işleme amacı ve saklama süresi tamamen şirketin kendisi tarafından belirlenmektedir.
B. Veri İşleyen
KVKK m.3/1-ğ uyarınca veri işleyen, veri sorumlusunun verdiği yetkiye dayanarak onun adına kişisel verileri işleyen taraftır. Veri işleyenin bağımsız bir işleme amacı yoktur; müşteriden gelen API çağrıları, webhook tetiklemeleri, UI komutları gibi talimatlar doğrultusunda veriyi depolar, işler veya aktarır. Müşterilerin kendi son kullanıcılarının telefon numaralarını Saas şirketinin PostgreSQL veritabanınıza kaydediyorsa, söz konusu veriler üzerindeki işleme amacı ve tasarruf yetkisi müşteriye ait olacaktır. SaaS şirketi bu verileri yalnızca müşterinin talimatları doğrultusunda işleyebilecektir.
C. Ortak Veri Sorumlusu
Kanun'un ilk metninde açıkça düzenlenmemiş olan bu kavram, Kişisel Verileri Koruma Kurulu'nun 23.12.2021 tarihli ve 2021/1303 sayılı kararıyla Türk hukuk uygulamasına girmiştir. Kurul, araç kiralama sektöründeki kara liste yazılımlarını incelediği bu kararda, yazılım şirketinin ve kiralama firmalarının veri üzerinde birlikte hakimiyet kurduğunu tespit ederek her iki tarafı ortak veri sorumlusu saymıştır. SaaS açısından bu kararın önemi büyüktür: bir marketplace platformunda alıcı verisinin hem satıcı hem de platform tarafından bağımsız amaçlarla kullanılması, aynı ortak sorumluluk yapısını doğurmaktadır.
III. SOMUT ÖRNEKLER İLE SAAS MİMARİSİNDE ROL TESPİTİ
Aşağıdaki değerlendirmeler, günümüz SaaS şirketlerinin en yaygın veri akışlarını ele almaktadır. Her bir akış için hem hukuki rol hem de KVKK m.5 kapsamındaki işleme şartı birlikte belirlenmelidir; rol tespiti işleme şartından bağımsız düşünülemez.
SaaS Şirketinin Eriştiği/Erişebildiği Veriler Bu husus, veri işleyen şirketlerin yanılgıya en fazla düştükleri noktalardan biridir. Bir SaaS şirketinin müşteri verisine rutin olarak erişmemesi, onun veri işleyen sıfatını ortadan kaldırmayacaktır. Yazılım güncellemeleri, hata giderme, veritabanı bakımı veya teknik destek süreçlerinde müşterinin kişisel verilerine erişim imkânının teknik olarak SaaS şirketinde bulunması, Saas şirketinin veri işleyen statüsünün doğması için yeterlidir. Kurul'un kararlarında da vurgulandığı üzere, yazılım şirketinin bünyesinde admin yetkisine sahip kullanıcılar ataması ve veritabanı yönetimini bünyesinde barındırması, veriye fiilen erişilmemiş olsa dahi işleyen sıfatını ve buna bağlı yükümlülükleri doğurur.
Müşterinin platforma yüklediği veriler (İK kayıtları, CRM kişi listeleri, müşteri destek geçmişi): Bu veriler bakımından SaaS şirketi veri işleyen konumundadır. Verinin mülkiyeti, işleme amacı ve kaderi müşteriye aittir; yazılım salt bir vasıta işlevi görür. İşleme şartı müşterinin kendi hukuki değerlendirmesine bağlıdır.
Platformun kendi topladığı veriler (kullanım analitiği, oturum logları, hata izleme, admin paneli yetkili bilgileri): Bu veriler bakımından SaaS şirketi veri sorumlusudur. Veriler, ürün geliştirme, SLA takibi ve güvenlik açıklarının tespiti amacıyla şirketin kendi inisiyatifiyle toplanmaktadır. Toplandığı anda anonimleştirilemeyen ve herhangi bir anda bir kullanıcı hesabına bağlanabilecek, kişisel verinin bir parçası olarak konumlanabilecek her türlü veri bu kategori içerisinde “kişisel veri” olarak tanımlanacaktır.
Müşteri verilerinin model eğitiminde kullanılması: Bu senaryo SaaS sektöründe giderek yaygınlaşan ve hukuken en riskli olan alandır. Müşterinin verisini onun talimatı dışına çıkarıp bağımsız bir ticari amaç için (örneğin yapay zeka modelinin eğitimi veya anonimleştirilmiş içgörü raporlarının satışı) kullandığınız anda, veri işleyen sıfatı kaybedilir ve veri sorumlusu statüsüne geçilir. Burada kritik bir ayrım yapılmalıdır: KVKK'da anonimleştirme, geri dönüştürülemezlik standardına tabidir. Gerçek anlamda anonimleştirilen veri kişisel veri olmaktan çıkar ve Kanun kapsamı dışına düşer; ancak bu noktada, anonim hale getirilen verinin hiçbir surette, veri sahibi kişiye bağlanamayacak konumda olması son derece kritiktir. Anonim hale getirilmiş veri, herhangi bir sürette verinin toplandığı veri kaynağı kişiye sonradan bağlanabiliyorsa, bu verinin anonim hale gelmediği kabul edilir.
Doğrudan son kullanıcıya hizmet (B2C): Sözleşme ilişkisi doğrudan şirket ile birey arasında kurulmuştur. Aydınlatma yükümlülüğü, veri güvenliğinin sağlanmasına yönelik güvenlik önlemlerinin alınması gibi veri sorumlusunun yükümlülükleri arasında sayılan tüm yükümlülükler tamamen SaaS şirketi tarafından yerine getirilmelidir.
IV. Veri İşleme Sözleşmesi (DPA)
A. Hukuki Dayanak
KVKK'da, GDPR Madde 28'deki gibi veri sorumlusu ile veri işleyen arasında yazılı sözleşme yapılmasını açıkça zorunlu kılan bir hüküm yoktur. Ancak Kanun'un 12. maddesinin ikinci fıkrası, bu boşluğu fiilen doldurmaktadır: "Veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi tarafından işlenmesi hâlinde, ayrıca bu kişi ile birlikte müştereken sorumludur."
Bu müşterek sorumluluk hükmünün SaaS şirketleri açısından iki doğrudan sonucu vardır. Birincisi, veri işleyen sıfatında olunması sebebiyle tüm sorumluluğun veri sahibinde olduğu yanılgısıdır. Bu durum tek başına geçersizdir; SaaS şirketindeki bir güvenlik açığı (hatalı S3 konfigürasyonu, eksik şifreleme, yetersiz erişim kontrolü) nedeniyle veri sızması yaşanması durumunda Kurul m.12/2 kapsamında Saas şirketine de idari para cezası uygulayabilir. İkincisi, sorumluluk sınırlarının yazılı bir DPA ile çizilmemesi durumunda, bir ihlal anında hangi tarafın hangi yükümlülüğü üstlendiği belirsiz kalır ve her iki taraf da azami cezayla muhatap olma riski ile karşı karşıya kalır.
B. DPA'in Asgari İçeriği
B2B SaaS şirketinin DPA’inde zorunlu unsurlar olarak şunlar karşımıza çıkmaktadır:
Rollerin açık beyanı (karma yapı varsa her bir veri kategorisi için ayrı ayrı);
SaaS şirketinin verileri yalnızca müşterinin belgelenmiş talimatları doğrultusunda işleyeceği taahhüdü;
Veritabanına erişimi olan tüm personelin gizlilik sözleşmesine (NDA) tabi olduğunun ve endüstri standardında teknik tedbirlerin (AES-256, RBAC, MFA, TLS/SSL) uygulandığının belirtilmesi;
Kullanılan alt işleyenlerin (AWS, SendGrid, MongoDB Atlas vb.) güncel listesinin bir URL üzerinden kamuya açık tutulması ve listeye ekleme yapılacağında müşteriye en az 30 gün önce bildirim yapılması;
Bir güvenlik ihlalinde SaaS şirketinin müşteriyi bilgilendirme süresinin kesin olarak belirtilmesi (örneğin tespitinden itibaren en geç 48 saat);
KVKK m.11 kapsamındaki ilgili kişi başvurularının (erişim, düzeltme, silme, taşınabilirlik) yönetimi için müşteriye sağlanacak API uç noktalarının veya arayüz araçlarının taahhüt edilmesi.
C. Sözleşme Sonunda Put Beyond Use İlkesi
DPA'lerde sıkça yapılan hata, sözleşme sonu prosedüründe "tüm müşteri verileri, yedekler dahil, kalıcı olarak silinecektir" şeklinde mutlak bir taahhüt verilmesidir. Bu ifade SaaS altyapısının teknik gerçeklikleriyle bağdaşmaz: AWS RDS snapshot'ları veya immutable log arşivleri içinden tek bir kiracının verisini seçerek anında silmek mümkün değildir. Bu taahhüdün verilmesi, şirketi doğrudan sözleşmeye aykırılık riskiyle karşı karşıya bırakır.
Uygulanması gereken endüstri standardı, “Put Beyond Use” ilkesidir: aboneliğin sona ermesi üzerine aktif sistemlerdeki müşteri verileri derhal silinir; yedekleme sistemlerindeki veriler ise erişime kapatılır, izole edilir ve düzenli üzerine yazılma (overwrite) döngüsü tamamlanana kadar aktif sistemlere geri yüklenmez. Bu süre boyunca söz konusu verilere erişilmez, işlenmez veya üçüncü taraflarla paylaşılmaz.
V. İHLAL ANINDA SORUMLULUK DAĞILIMI
Bir veri ihlali senaryosunda bildirim yükümlülükleri rol tespitine göre farklılaşır. Veri sorumlusu sıfatındaki taraf, ihlali öğrendiği andan itibaren en geç 72 saat içinde Kurul'a bildirim yapmakla yükümlüdür. İlgili kişilere bildirim ise ayrı bir yükümlülüktür ve "makul olan en kısa sürede" yapılmalıdır; iki süre farklı standartlara tabidir.
Veri işleyen sıfatındaki SaaS şirketinin Kurul'a doğrudan bildirim yükümlülüğü yoktur. Yasal görevi, ihlali tespit ettiği anda gecikmeksizin müşterisine (veri sorumlusu) haber vermektir. Ancak yukarıda açıklanan m.12/2 müşterek sorumluluk hükmü burada da geçerlidir: ihlale yol açan güvenlik açığı SaaS şirketinin altyapısından kaynaklanıyorsa, bu noktada bildirim yapma yükümlülüğü, müşteride olduğu kadar SaaS şirketinde de olacaktır. Bu nedenle şirket içinde yazılı bir Incident Response Plan oluşturulması, planda m.12/2 kapsamındaki tedbirlerin belgelenmesine yer verilmesi elzemdir.
VI. SONUÇ VE ÖNERİLER
SaaS şirketlerinin KVKK uyumunda atması gereken ilk adım, teknik mimariyi hukuki roller üzerinden okumak, bir Veri Akış Şeması (Data Flow Diagram), sunuculardan ve API gateway'lerden geçen her verinin kime ait olduğunu, hangi amaçla tutulduğunu ve hangi hukuki role uyduğunu veritabanı tabloları bazında etiketlemelidir.
Bu haritalama tamamlandığında, B2B müşterilere sunulan hizmet sözleşmesinin ayrılmaz bir eki olarak karma rolü açıkça tanımlayan, m.12/2 müşterek sorumluluk riskini yöneten ve sözleşme sonu prosedürünü teknik gerçekliğe uygun şekilde düzenleyen bir DPA hazırlanmalıdır. Alt işleyen listesinin şeffafça kamuya açılması, değişikliklerde müşteriye bildirim ve itiraz mekanizmasının kurulması ve alınan tüm teknik tedbirlerin bağımsız denetim raporlarıyla (ISO 27001 veya SOC 2 Tip II) belgelenmesi, hem Kurul denetimlerine hem de kurumsal satış süreçlerine hazırlık açısından zorunludur.
Son olarak, 2026-2028 dönemine ilişkin Orta Vadeli Program kapsamında KVKK'nın GDPR ile tam uyumlu hale getirilmesine yönelik mevzuat çalışmalarının 2026 yılı içinde tamamlanmasının hedeflendiği göz önünde tutulmalıdır. Bu düzenleme, veri işleyenin doğrudan cezai sorumluluğunu artırması, DPA zorunluluğunu kanun düzeyinde açık hale getirmesi ve denetim yetkisini genişletmesi beklenmektedir. Bugün yapılacak doğru yapılandırma, yarınki regülasyona hazırlık anlamına gelmektedir.
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.