SaaS sözleşmesi öncesinde hizmet kapsamı, veri sahipliği ve işleme, güvenlik, kimlik, SLA, olay bildirimi, alt işleyenler, denetim kanıtı, ürün değişiklikleri, fiyat artışı, veri taşınabilirliği, silme ve çıkış desteği kontrol edilmelidir. Hukuki inceleme teknik ve iş kanıtıyla birlikte yapılmalıdır.
SaaS sözleşmesi ürün demosundan önce başlamalıdır
SaaS sözleşmeleri standart görünse de kurumun veri ve iş kritikliği farklıdır. Düşük etkili bir araçta kabul edilebilir hüküm, temel müşteri sistemi için yetersiz olabilir.
Sözleşme, ürünün mevcut halini değil yaşam döngüsünü yönetmelidir. Tedarikçi özellik, fiyat, alt işleyen veya veri bölgesi değiştirebilir; kurumun bildirim ve itiraz hakları açık olmalıdır.
Teknik ekip ve iş sahibi sözleşme incelemesine katılmazsa hukuki metin gerçek operasyon ve entegrasyon riskini yansıtmayabilir.
Sözleşmede netleşmesi gereken altı alan
Maddeler kritiklik ve pazarlık gücüne göre önceliklendirilmelidir. Her risk aynı derecede müzakere edilemez; kabul edilen istisna kayıt altına alınmalıdır.
| Ölçüt | Sorulacak soru | Kanıt |
|---|---|---|
| Kapsam | Satın alınan hizmet ve sınırlar açık mı? | Sipariş formu ve teknik ek |
| Veri | Sahiplik, bölge, alt işleyen ve silme nasıl düzenlenmiş? | DPA ve veri akışı |
| SLA | Kullanılabilirlik ve destek nasıl ölçülüyor? | Ölçüm ve telafi hükmü |
| Değişiklik | Ürün veya şart değişirse bildirim ve itiraz var mı? | Değişiklik maddesi |
| Çıkış | Veri hangi formatta, ne sürede alınabilir? | Taşıma ve silme planı |
Sonradan pahalıya dönen eksik hükümler
En sık hata çıkışın yalnız fesih maddesi olarak görülmesidir. Veri formatı, aktarım süresi, geçiş desteği, hesap kapatma ve yedek silme birlikte planlanmalıdır.
- Pazarlama sayfasındaki özellikleri sözleşmede güvence altına almamak.
- SLA ölçümünü yalnız tedarikçi verisine bırakmak.
- Alt işleyen ve veri bölgesi değişikliklerinde bildirim hakkı bulunmaması.
- Fiyat artışı ve kullanıcı/işlem ölçümünün belirsiz olması.
- Veri dışa aktarma formatı ve çıkış desteğinin tanımlanmaması.
- Sorumluluk sınırının kritik veri ve güvenlik etkisiyle uyumsuz olması.
Teknik kanıtı sözleşme maddesine dönüştürün
Sözleşme kontrolü, tedarikçi güvenlik değerlendirmesi ve mimari testlerle aynı risk kaydında yürütülmelidir.
- İş, veri ve teknik gereksinimleri sözleşme öncesi yazın.
- Tedarikçi teklifini gerçek kullanım ve istisnalarla doğrulayın.
- Güvenlik ve veri değerlendirme bulgularını sözleşme koşuluna dönüştürün.
- SLA, destek, bakım ve değişiklik hükümlerini ölçülebilir hale getirin.
- Fiyat ve kullanım ölçüm senaryolarını modelleyin.
- Çıkış, veri alma, silme ve geçiş desteğini test edin.
- Sözleşme sonrası sahiplik ve periyodik gözden geçirme takvimi kurun.
İş, hukuk, güvenlik ve satın alma rolleri
Sözleşme sahibi canlı sonrası değişiklikleri ve yenileme tarihini takip etmelidir. Hukuk yalnız imza anında devreye giren ekip olmamalıdır.
İş sahibi
Hizmet sonucu ve kritik gereksinimi tanımlar.
Satın alma
Ticari şart ve müzakere sürecini yönetir.
Hukuk
Sorumluluk, veri ve sözleşme haklarını düzenler.
Güvenlik/KVKK
Teknik kontrol ve veri işleme şartlarını belirler.
BT/mimari
Entegrasyon, SLA ve çıkış uygulanabilirliğini test eder.
Finans
Toplam maliyet, fiyat artışı ve bütçe riskini değerlendirir.
Sözleşmenin işlemesini hangi göstergeler kanıtlar?
Sözleşme performansı SLA, olay, maliyet ve değişiklik göstergeleriyle izlenmeli; yenileme kararı otomatik verilmemelidir.
İzlenmesi gereken göstergeler
SLA ihlali
Fiyat sapması
Alt işleyen değişikliği
Açık sözleşme riski
Çıkış testi
Olay bildirim süresi
Sözleşmeyi “çıkış günü” üzerinden test edin
SaaS sözleşmesinin kalitesi yalnız hizmet normal çalışırken değil, ilişki sona erdiğinde anlaşılır. İmza öncesinde varsayımsal bir çıkış günü çalışması yapın.
- Veri teslimi: Hangi formatta, kaç gün içinde, hangi ek ücretle alınacak?
- Silme kanıtı: Ana sistem, yedekler ve alt işleyenlerde silme nasıl doğrulanacak?
- Geçiş desteği: API, dokümantasyon ve uzman desteği ne kadar süre sağlanacak?
- Kimlik ve erişim: Kullanıcılar, anahtarlar ve entegrasyonlar güvenli biçimde nasıl kapatılacak?
- İş sürekliliği: Geçiş döneminde iki sistemin birlikte çalışması gerekiyorsa sorumluluk kimde olacak?
- Uyuşmazlık: Veri eksik veya hizmet kesik olursa yaptırım ve çözüm mekanizması nedir?
Bu soruların cevabı yoksa düşük giriş fiyatı yüksek çıkış maliyetini gizliyor olabilir.
İyi sözleşme, hizmet kadar çıkışı da tasarlar
İyi sözleşme bütün riski tedarikçiye aktaramaz. Kurumun yapılandırma, kullanıcı, veri ve entegrasyon sorumlulukları da açıkça yönetilmelidir.
Kaynaklar ve gözden geçirme notu
Bu rehberde değişebilir veya teknik iddialar için öncelikle resmî kurum, ürün geliştiricisi ve birincil araştırma kaynakları kullanılmıştır. Bağlantılar 27 Temmuz 2026 tarihinde gözden geçirilmiştir.
- 01CISA Secure by Demand Guide
Yazılım satın alan kurumların tedarikçiye sorması gereken güvenlik soruları ve satın alma yaklaşımı.
- 02CISA Software Transparency in SaaS Environments
SaaS ortamlarında yazılım bileşenleri ve tedarik zinciri şeffaflığına ilişkin resmî teknik çalışma.
- 03NIST Software Supply Chain Security Guidance
Yazılım üreticisi ve tedarikçisinin güvenlik uygulamalarını değerlendirmek için resmî kaynak.