SaaS Sözleşmelerinde Dikkat Edilmesi Gerekenler

SaaS sözleşmelerinde dikkat edilmesi gerekenler; teknik performans taahhütleri, veri sahipliği, mevzuata uyum ve maliyet kontrolü parametrelerinin sözleşme metnine eksiksiz yansıtılmasını kapsar. Hizmet olarak yazılım (Software as a Service) modellerinde geleneksel yazılım lisanslarından farklı olarak altyapı, bakım ve veri depolama süreçleri tamamen tedarikçi kontrolündedir. Bu rehber; şirket yöneticileri, teknik karar vericiler ve satın alma ekipleri için hizmet seviyesi taahhütlerinden (SLA) veri koruma protokollerine, tedarikçi bağımlılığı (vendor lock-in) risklerinden otomatik yenileme tuzaklarına kadar tüm kritik sözleşme maddelerini teknik ve hukuki bağlamda inceler.

SLA (Hizmet Seviyesi Taahhütleri) ve İş Sürekliliğinin Garanti Altına Alınması

Hizmet Seviyesi Anlaşması (SLA - Service Level Agreement), SaaS sağlayıcısının sunduğu yazılımın kullanılabilirlik, performans ve destek yanıt sürelerine dair yasal bağlayıcılığı olan taahhüdüdür. Bulut tabanlı bir hizmet satın alındığında şirket altyapısı sağlayıcının sunucularına bağımlı hale gelir. Bu bağımlılık, sistem kesintilerinin doğrudan ciro kaybına, operasyonel aksamalara ve itibar zedelenmesine yol açmasına zemin hazırlar. Sözleşme müzakerelerinde SLA metinleri standart matbu formlar olarak kabul edilmemeli, her bir parametre şirketin iş modeliyle uyumlu hale getirilmelidir.

Teknik açıdan SLA yalnızca bir uptime yüzdesinden ibaret değildir. Sistem yanıt süresi (latency), planlı bakım pencerelerinin zamanlaması, kritik hata bildirimlerinde ilk yanıt ve çözüm süreleri (MTTR - Mean Time to Resolve) gibi operasyonel metrikler sözleşmeye dahil edilmelidir. Tedarikçinin taahhüt ettiği oranların ölçüm yöntemi şeffaf olmalı; üçüncü taraf izleme araçlarının (Pingdom, Datadog vb.) raporları resmi delil niteliği taşımalıdır.

Uptime (Kesintisiz Çalışma) Oranları ve Esneklik Payı

SaaS sektöründe uptime oranları genellikle %99 ile %99,99 arasında ifade edilir. İlk bakışta bu oranlar birbirine çok yakın görünse de yıllık bazda izin verilen kesinti süreleri arasında ciddi farklar bulunur. Sözleşmede yer alan uptime oranının hangi zaman aralığı (aylık, çeyreklik, yıllık) üzerinden hesaplandığı ve "kesinti" tanımının neyi kapsadığı açıkça belirtilmelidir.

Aşağıdaki tablo, farklı uptime taahhütlerinin operasyonel kesinti karşılıklarını göstermektedir:

Tedarikçiler sıklıkla "planlı bakım" sürelerini kesinti hesaplamalarından muaf tutmak ister. Müzakere aşamasında planlı bakımların iş saatleri dışında (örneğin hedef pazarın saat dilimine göre Pazar 01:00 - 05:00 arasında) yapılması, ayda toplam 4 saati geçmemesi ve en az 5 iş günü önceden yazılı olarak bildirilmesi şart koşulmalıdır. Bildirilmeyen veya iş saatleri içinde yapılan bakımlar doğrudan plansız kesinti olarak kabul edilmelidir.

Kesinti Durumlarında Uygulanacak Ceza ve İade Mekanizmaları

Uptime taahhüdünün ihlal edilmesi durumunda devreye girecek yaptırımlar sözleşmede netleştirilmelidir. Sektör standardı uygulama "Hizmet Kredisi" (Service Credit) mekanizmasıdır. Hizmet kredisi, kesintinin yaşandığı fatura dönemindeki abonelik bedelinin belirli bir yüzdesinin bir sonraki faturadan düşülmesini sağlar.

Ceza mekanizmasında kademeli bir yapı kurulmalıdır:

• Aylık uptime %99,9 altına düştüğünde aylık ücretin %10'u,

• %99,5 altına düştüğünde aylık ücretin %25'i,

• %99,0 altına düştüğünde aylık ücretin %50'si hizmet kredisi olarak tanımlanmalıdır.

Sözleşmede yer alması gereken kritik bir diğer madde ise "Kronik Kesinti Nedeniyle Fesih" (Chronic Failure Termination) hakkıdır. Tedarikçi ardışık 3 ay veya 1 yıl içinde herhangi 4 ay boyunca taahhüt ettiği uptime oranını karşılayamazsa, alıcı şirkete sözleşmeyi herhangi bir ceza veya erken fesih bedeli ödemeksizin derhal feshetme ve peşin ödenen kullanılmamış dönemin ücretini iade alma hakkı tanınmalıdır.

Bakım Süreleri ve Felaket Kurtarma (Disaster Recovery) Planları

İş sürekliliği, yalnızca günlük çalışma stabilitesini değil, büyük ölçekli altyapı çökmeleri, fidye yazılımı (ransomware) saldırıları veya doğal afetler sonrasında sistemin nasıl ayağa kaldırılacağını da kapsar. Bu doğrultuda sözleşmede Felaket Kurtarma (DR - Disaster Recovery) ve İş Sürekliliği (BCP - Business Continuity Plan) standartları bağlayıcı kılınmalıdır.

Bu kapsamda sözleşmeye iki temel teknik metrik eklenmelidir:

• RPO (Recovery Point Objective - Kurtarma Noktası Hedefi): Bir felaket anında tolere edilebilecek maksimum veri kaybı süresidir. Kritik iş sistemlerinde RPO süresinin 1 saati veya 15 dakikayı aşmayacağı, yedeklemelerin coğrafi olarak yedekli (geo-redundant) sunucularda tutulduğu belirtilmelidir.

• RTO (Recovery Time Objective - Kurtarma Süresi Hedefi): Sistemin çöktükten sonra yeniden çalışır hale getirilmesi için taahhüt edilen maksimum süredir. Bu sürenin 4 ila 8 saat aralığını geçmemesi hedeflenmelidir.

Sağlayıcının ISO 22301 (İş Sürekliliği Yönetim Sistemi) ve SOC 2 Type II sertifikasyonlarına sahip olması ve bu denetim raporlarının özetlerini yılda en az bir kez müşteriyle paylaşmayı taahhüt etmesi talep edilmelidir.

Veri Sahipliği, Güvenlik ve KVKK/GDPR Uyumu

SaaS mimarilerinde şirketinize ait müşteri kayıtları, finansal tablolar, çalışan verileri ve ticari sırlar üçüncü taraf sunucularda işlenir ve saklanır. Bu durum, "veri sahipliği" (data ownership) ve "veri güvenliği" (data security) konularını sözleşmenin en kritik hukuki unsurları haline getirir. Sözleşme metninde veri mülkiyetinin alıcı şirkette kaldığı şüpheye yer bırakmayacak şekilde tanımlanmadığı takdirde, tedarikçinin bu verileri anonimleştirerek kendi yapay zeka modellerini eğitmesi, analiz raporlarında kullanması veya üçüncü taraflarla paylaşması riski doğar.

Veri güvenliği taahhütleri genel ifadelerden ("sektör standartlarında güvenlik sağlanacaktır") arındırılmalı; şifreleme standartları (aktarım sırasında TLS 1.3, bekleme durumunda AES-256), kimlik doğrulama protokolleri (SAML tabanlı SSO, MFA zorunluluğu) ve rol tabanlı erişim kontrolü (RBAC) net olarak yazılmalıdır.

Sözleşmede "Veri Sahipliği" (Data Ownership) Maddesinin Önemi

Sözleşmede "Müşteri Verisi" (Customer Data) tanımı mümkün olan en geniş kapsamda yapılmalıdır. Şirket tarafından platforma yüklenen tüm girdiler, bu girdilerden üretilen çıktılar, meta veriler ve kullanıcı hareket kayıtları müşteri mülkiyeti altında kabul edilmelidir.

Tedarikçiye yalnızca hizmetin sunulması için zorunlu olan sınırlı, devredilemez ve münhasır olmayan bir kullanım lisansı verilmelidir. Özellikle son dönemde yaygınlaşan yapay zeka tabanlı SaaS çözümlerinde, "Sağlayıcı, algoritmalarını geliştirmek amacıyla müşteri verilerini işleyebilir" şeklindeki maddeler tamamen çıkarılmalı veya açık bir "opt-out" (kapsam dışı kalma) seçeneğine bağlanmalıdır. Fikri mülkiyet haklarının korunması adına, müşterinin verisi üzerinde tedarikçinin herhangi bir rehin, mülkiyet veya telif hakkı iddia edemeyeceği kesin hükme bağlanmalıdır.

KVKK Kapsamında Veri İşleyen ve Veri Sorumlusu İlişkisi

Türkiye pazarında faaliyet gösteren şirketler için 6698 sayılı Kişisel Verilerin Korunması Kanunu (KVKK), Avrupa Birliği pazarı için ise Genel Veri Koruma Tüzüğü (GDPR) bağlayıcıdır. SaaS sağlayıcısı kural olarak "Veri İşleyen" (Data Processor), hizmeti alan şirket ise "Veri Sorumlusu" (Data Controller) konumundadır. Bu ilişkiyi düzenlemek üzere ana sözleşmenin ayrılmaz bir parçası olarak Veri İşleme Sözleşmesi (DPA - Data Processing Agreement) imzalanmalıdır.

KVKK ve GDPR uyumu kapsamında sözleşmede yer alması zorunlu unsurlar şunlardır:

1. Veri Lokasyonu: Verilerin hangi ülkelerde ve hangi veri merkezlerinde (AWS Frankfurt, Azure TR vb.) tutulacağı açıkça listelenmelidir. KVKK uyarınca kişisel verilerin yurt dışına aktarımı özel izin ve şartlara bağlı olduğundan, yurt dışı sunucu kullanımı açıkça onaylanmalıdır.

2. Alt Veri İşleyenler (Sub-processors): Tedarikçinin hizmeti sunarken kullandığı alt yüklenicileri (barındırma sağlayıcıları, e-posta gönderim API'leri vb.) listelemesi ve yeni bir alt işleyen eklemeden önce müşteriye en az 30 gün önceden yazılı bildirim yaparak itiraz hakkı tanıması gereklidir.

3. Denetim Hakkı: Müşterinin veya bağımsız bir denetçinin yılda en az bir kez sağlayıcının güvenlik ve veri koruma uygulamalarını denetleme hakkı (Right to Audit) güvenceye alınmalıdır.

Veri İhlali Durumunda Bildirim Süreleri ve Tazminat Sınırları

Herhangi bir siber saldırı, veri sızıntısı veya yetkisiz erişim durumunda zamanlama hayati önem taşır. KVKK uyarınca Veri Sorumlusu, bir veri ihlalini öğrendikten sonra en geç 72 saat içinde Kişisel Verileri Koruma Kurulu'na bildirimde bulunmak zorundadır (GDPR Madde 33 kapsamında da bu süre 72 saattir).

Bu nedenle SaaS sözleşmesinde tedarikçinin olası bir güvenlik ihlalini müşteriye bildirme süresi en geç 24 veya 48 saat olarak belirlenmelidir. Bildirim içeriğinde ihlalden etkilenen veri kategorileri, yaklaşık kişi sayısı ve alınan önleyici tedbirler detaylandırılmalıdır.

+-----------------------------------------------------------------------------------+
|               VERİ İHLALİ VE SORUMLULUK MÜZAKERE MATRİSİ                          |
+------------------------------------+----------------------------------------------+
| Tedarikçi Standart Taslağı         | Müzakere Edilmesi Gereken İdeal Hüküm        |
+------------------------------------+----------------------------------------------+
| İhlal "makul sürede" bildirilir.   | İhlal tespitinden itibaren en geç 24 saat    |
|                                    | içinde yazılı ve detaylı bildirim yapılır.   |
+------------------------------------+----------------------------------------------+
| Tazminat sorumluluğu son 12 aylık  | Veri ihlali ve gizlilik maddeleri genel      |
| abonelik ücretiyle sınırlıdır.     | sorumluluk sınırından (Liability Cap) muaf   |
|                                    | tutulur veya bu sınır 3-5 katına çıkarılır.  |
+------------------------------------+----------------------------------------------+
| İdari para cezaları kapsam dışıdır.| Kusur oranında KVKK/GDPR idari para cezaları |
|                                    | ve bildirim masrafları tedarikçiye rücu eder.|
+------------------------------------+----------------------------------------------+

Tedarikçinin kusurundan kaynaklanan bir ihlal sonucunda kesilen idari para cezaları ve veri sahiplerine yapılacak tebligat/çağrı merkezi masrafları tedarikçinin tazminat yükümlülükleri (indemnification) kapsamına dahil edilmelidir.

Vendor Lock-in (Tedarikçi Bağımlılığı) Riski ve Çıkış Stratejileri

Vendor Lock-in (Tedarikçi Bağımlılığı), bir şirketin kullandığı SaaS platformundan ayrılmak istediğinde karşılaştığı teknik, operasyonel ve finansal engeller nedeniyle sağlayıcıyı değiştirememesi durumudur. Sağlayıcılar, müşterileri ekosistemlerinde tutabilmek için kapalı veri formatları, kısıtlı API'ler ve yüksek veri dışa aktarım maliyetleri uygulayabilir. Bir sözleşme imzalanırken ayrılık sürecinin nasıl yürütüleceği (Exit Strategy) ilk günden planlanmalı ve sözleşmeye yazılmalıdır.

Çıkış stratejisinin bulunmaması, sağlayıcının ilerleyen yıllarda yapacağı fahiş fiyat artışlarına veya düşen hizmet kalitesine karşı şirketin pazarlık gücünü tamamen sıfırlar. Bu nedenle veri taşınabilirliği (data portability) ve geçiş desteği maddeleri bağlayıcı hükümlerle yapılandırılmalıdır.

Fesih Sonrası Veri Dışa Aktarımı (Data Migration) Standartları

Sözleşme herhangi bir nedenle (süre bitimi, haklı fesih, karşılıklı anlaşma) sona erdiğinde, müşterinin verilerini hangi formatta ve ne kadar sürede alabileceği belirlenmelidir. Sağlayıcının verileri yalnızca okunması zor PDF raporları veya özel (proprietary) formatlarda sunması engellenmelidir.

Sözleşmede yer alması gereken veri dışa aktarım şartları:

• Veri Formatı: Veriler ilişkisel bütünlüğü korunmuş olarak standart, açık formatlarda (JSON, CSV, XML veya ilişkisel SQL veritabanı dump'ı) teslim edilmelidir.

• Erişim Süresi: Fesih tarihinden itibaren müşteriye verilerini indirmesi ve doğrulaması için en az 30 ila 60 günlük "Yetkisiz / Ücretsiz Erişim Süresi" (Grace Period) tanınmalıdır.

• API ve İndirme Hızları: Veri çekme süreçlerinde API limitleri (rate limits) kaldırılmalı veya yüksek bant genişliği tahsis edilmelidir.

• Maliyet: Standart veri dışa aktarım süreçleri için ek bir "veri çıkarma ücreti" (data egress fee) talep edilmeyeceği açıkça belirtilmelidir.

Verilerin Kalıcı Olarak Silinmesi ve İspat Yükümlülüğü

Verilerin taşınması tamamlandıktan sonra, eski tedarikçinin elinde kalan yedeklerin, logların ve veritabanı kopyalarının güvenli bir şekilde yok edilmesi yasal bir zorunluluktur. Bu durum KVKK Madde 7 ve GDPR Madde 17 (Unutulma Hakkı) kapsamında veri güvenliğinin tamamlayıcı bir parçasıdır.

Sözleşmede, geçiş süresinin tamamlanmasının ardından en geç 30 gün içinde sağlayıcının birincil sunucularından ve 90 gün içinde tüm soğuk yedeklerinden (cold backups) müşteri verilerini kalıcı olarak sileceği ve üzerine yazılamaz hale getireceği belirtilmelidir. Süreç tamamlandığında sağlayıcının C-Level yöneticisi veya Veri Koruma Görevlisi (DPO) tarafından imzalanmış bir "Veri İmha Sertifikası" (Certificate of Destruction) sunulması zorunlu tutulmalıdır.

Geçiş Sürecinde (Transition Period) Tedarikçinin Destek Taahhütleri

Yeni bir yazılıma geçiş haftalar veya aylar sürebilir. Ani bir kesinti yaşanmaması için sözleşmeye "Geçiş Dönemi Desteği" (Disentanglement / Transition Assistance) maddesi eklenmelidir.

Bu madde uyarınca:

• Müşterinin talebi halinde sağlayıcı, mevcut sözleşme şartları ve fiyatlandırması üzerinden 3 ila 6 aya kadar uzatılmış hizmet sunmaya devam etmelidir.

• Sağlayıcı, yeni yazılıma veri aktarımı sırasında teknik ekibe bilgi aktarımı (knowledge transfer) sağlamalı ve veri şemalarını (database schema / API documentation) eksiksiz teslim etmelidir.

• Geçiş desteği için uygulanacak saatlik veya günlük teknik danışmanlık ücretleri sözleşme başlangıcında sabitlenmelidir.

Fiyatlandırma Modelleri ve Gizli Maliyetlerin Önlenmesi

SaaS alımlarında ilk yıl teklif edilen cazip fiyatlar, sonraki yıllarda kontrolsüz maliyet artışlarına ve bütçe aşımına dönüşebilir. Şirketler sıklıkla sadece temel kullanıcı başı lisans ücretine odaklanır; ancak uygulama (onboarding), API kullanım limitleri, veri depolama sınırları ve birinci sınıf destek gibi yan hizmetler toplam sahip olma maliyetini (TCO - Total Cost of Ownership) ikiye katlayabilir. Sözleşme aşamasında tüm maliyet kalemleri detaylandırılmalı ve sözleşme süresince geçerli olacak tavan fiyatlar yazılı hale getirilmelidir.

Fiyatlandırma modelleri kullanıcı bazlı (per-seat), tüketim bazlı (usage-based) veya özellik bazlı (tier-based) kurgulanabilir. Hangi model seçilirse seçilsin, aşım (overage) maliyetlerinin nasıl hesaplanacağı net olmalıdır.

Lisans Esnekliği: Kullanıcı Sayısı (Seat) Artış ve Azalış Şartları

Kurumsal SaaS sözleşmeleri genellikle 1 ila 3 yıllık taahhütlerle imzalanır ve toplu lisans alımlarında indirim sağlanır. Ancak şirketlerin personel sayısı dönemsel olarak dalgalanabilir.

Lisans maddelerinde şu esneklikler talep edilmelidir:

• True-Down (Lisans Düşürme) Hakkı: Yıllık sözleşmelerde dahi yıl ortasında veya her yenileme döneminde kullanılmayan lisansların belirli bir oranda (örneğin %15-20) cezasız olarak iptal edilebilmesi sağlanmalıdır.

• Pro-Rata Lisans Artırımı: Yıl içinde yeni lisans eklendiğinde, bu lisansların ücreti sözleşmenin kalan gün sayısı üzerinden (pro-rata) hesaplanmalı ve başlangıçta alınan indirim oranı yeni lisanslar için de geçerli olmalıdır.

• Lisans Değiştirilebilirliği (Floating / Reallocation): İşten ayrılan veya rolü değişen personelin lisansı anında başka bir personele ek bir yönetim ücreti ödenmeksizin atanabilmelidir.

Gizli Entegrasyon, Destek ve Veri Depolama Ücretleri

Satış görüşmelerinde belirtilmeyen ancak canlıya geçiş sürecinde ortaya çıkan ek giderler bütçeleri sarsabilir. Bu kalemlerin her biri sözleşme ekinde (Order Form / Statement of Work) sabitlenmelidir.

Sık karşılaşılan gizli maliyet kalemleri ve önlemleri:

+-----------------------------------------------------------------------------------+
|                     SAAS GİZLİ MALİYET KALEMLERİ VE ÖNLEMLERİ                     |
+--------------------------+--------------------------------------------------------+
| Potansiyel Risk Alanı    | Sözleşmeye Eklenecek Koruyucu Madde                   |
+--------------------------+--------------------------------------------------------+
| API Çağrı Limitleri      | Aylık API limiti aşıldığında sistem durdurulamaz; aşım |
|                          | birim maliyeti başlangıçta sabitlenmelidir.            |
+--------------------------+--------------------------------------------------------+
| Veri Depolama Aşımı      | GB/TB başına ek depolama ücretleri açıkça yazılmalı;   |
|                          | log verileri otomatik arşivleme ile temizlenebilmeli. |
+--------------------------+--------------------------------------------------------+
| Onboarding & Kurulum     | Zorunlu profesyonel hizmet (PS) bedelleri ve kapsamı  |
|                          | net iş tanımlarıyla (SOW) sınırlandırılmalıdır.       |
+--------------------------+--------------------------------------------------------+
| Destek Seviyesi (Support)| 7/24 kritik destek için ek "Premium Destek" ücreti     |
|                          | talep edilmeyeceği sözleşmede teyit edilmelidir.       |
+--------------------------+--------------------------------------------------------+

Enflasyon veya Kur Farkına Bağlı Fiyat Artış Sınırları (Price Caps)

Çok yıllı veya otomatik yenilenen sözleşmelerde sağlayıcılar, ilk dönemin ardından fahiş fiyat artışları uygulama eğilimindedir. Müşterinin yazılıma olan operasyonel bağımlılığı arttığı için bu artışlara itiraz etmek güçleşir.

Bu riski bertaraf etmek için sözleşmeye "Fiyat Artış Tavanı" (Price Cap) maddesi eklenmelidir.

Örnek formülasyon:

• Yabancı para birimli sözleşmelerde: "Yenileme dönemlerindeki fiyat artışı, ilgili ülkenin Tüketici Fiyat Endeksi (TÜFE/CPI) oranını veya maksimum %5'i (hangisi düşükse) geçemez."

• TL bazlı sözleşmelerde: "Yıllık fiyat artışı, Türkiye İstatistik Kurumu (TÜİK) tarafından açıklanan 12 aylık ortalama Yİ-ÜFE ve TÜFE ortalaması ile sınırlandırılacaktır."

Bu sınırın üzerinde bir artış talep edilmesi durumunda müşteriye sözleşmeyi derhal ve cezasız feshetme hakkı tanınmalıdır.

Sözleşme Süresi, Otomatik Yenileme ve Fesih Şartları

SaaS sözleşmelerinde şirketleri en çok mağdur eden alanların başında otomatik yenileme (auto-renewal / evergreen) maddeleri ve tek taraflı fesih hakkının kısıtlanması gelir. Birçok yazılım sağlayıcısı, bildirim süresinin sadece 24 saat kaçırılması durumunda dahi sözleşmeyi tam bir yıl daha aynı veya daha yüksek fiyattan uzatacak maddeler ekler. Sözleşmenin yürürlük süresi (term), yenileme mekanizması ve fesih prosedürleri şirketin çıkarlarını koruyacak şekilde yeniden kaleme alınmalıdır.

Hukuki açıdan sözleşmelerde iki temel fesih türü bulunur: Haklı nedenle fesih (Termination for Cause) ve Sebepsiz/Keyfi fesih (Termination for Convenience). Her iki durum için de mali ve operasyonel sonuçlar netleştirilmelidir.

Opt-out (Çıkış) Opsiyonları ve Otomatik Yenileme (Auto-renewal) Tuzakları

Otomatik yenileme maddeleri, sözleşme bitiminden belirli bir süre önce fesih ihbarı yapılmadığı takdirde aboneliğin kendiliğinden uzamasını öngörür. Tedarikçiler bu ihbar süresini 60 veya 90 gün gibi uzun tutarak müşterinin bildirim penceresini kaçırmasını hedefler.

Otomatik yenileme risklerini yönetmek için:

1. İhbar Süresi: Fesih bildirim süresi maksimum 30 gün ile sınırlandırılmalıdır.

2. Yazılı Hatırlatma Yükümlülüğü: Sağlayıcının, otomatik yenileme tarihinden en az 30 gün önce müşterinin yetkili e-posta adresine yenileme tarihini ve güncel fiyat politikasını bildiren yazılı bir hatırlatma göndermesi şart koşulmalıdır. Bu hatırlatma yapılmazsa otomatik yenileme geçersiz sayılmalıdır.

3. Opt-in Alternatifi: Mümkünse sözleşmenin otomatik olarak değil, ancak tarafların yazılı onayı ile (Opt-in) uzayacağı kuralı getirilmelidir.

Haklı Nedenle Fesih Koşulları ve İhbar Süreleri

Haklı nedenle fesih, taraflardan birinin sözleşme yükümlülüklerini ağır şekilde ihlal etmesi durumunda sözleşmenin tazminatsız olarak derhal sona erdirilmesidir.

Müşteri lehine sözleşmeye eklenmesi gereken haklı fesih nedenleri:

• Giderme Süresi (Cure Period): Sözleşme ihlali durumunda karşı tarafa ihlali gidermesi için standart 30 günlük yazılı süre (cure period) tanınır. İhlal bu sürede giderilmezse fesih derhal gerçekleşir.

• Güvenlik ve Gizlilik İhlalleri: Veri sızıntısı, KVKK ihlali veya gizlilik maddelerinin çiğnenmesi durumlarında 30 günlük süre beklenmeksizin "Derhal Fesih" (Immediate Termination) hakkı geçerli olmalıdır.

• İflas ve Tasfiye: Sağlayıcının iflas etmesi, konkordato ilan etmesi veya faaliyetlerini durdurması halinde sözleşme doğrudan feshedilebilmeli ve müşteri verileri derhal iade edilmelidir.

• Geri Ödeme Yükümlülüğü: Haklı fesih durumunda, peşin ödenmiş ancak kullanılmamış gelecek dönem lisans bedelleri 14 iş günü içinde yasal faiziyle iade edilmelidir.

Fikri Mülkiyet Haklarının İhlali Durumunda Sözleşmenin Feshi

SaaS sağlayıcısının kullandığı teknolojinin, kod kütüphanelerinin veya algoritmaların üçüncü bir tarafın patent veya telif hakkını ihlal etmesi durumunda müşteri de yasal davalarla karşı karşıya kalabilir. Sözleşmede "Fikri Mülkiyet Tazminatı" (IP Indemnification) maddesi eksiksiz yer almalıdır.

Bu madde uyarınca sağlayıcı; yazılımın üçüncü şahısların fikri mülkiyet haklarını ihlal ettiği iddiasıyla müşteriye karşı açılabilecek tüm davaları finanse etmeyi, avukatlık masraflarını karşılamayı ve hükmedilecek tüm tazminatları üstlenmeyi kabul etmelidir. İhlal kesinleşirse sağlayıcı müşteriye şu üç seçenekten birini sunmakla yükümlü olmalıdır:

1. Müşterinin yazılımı kullanmaya devam edebilmesi için gerekli lisansı masrafları üstlenerek temin etmek,

2. Yazılımı ihlale yol açmayacak eşdeğer bir fonksiyonellikle değiştirmek veya güncellemek,

3. Bunlar mümkün değilse sözleşmeyi feshedip peşin ödenen tüm ücretleri iade etmek.