SaaS satın alma kararları çoğu zaman “bugün çalışıyor mu?” sorusuyla başlar; ancak gerçek maliyet ve riskler genellikle entegrasyon, SLA ve veri taşınabilirliği detaylarında ortaya çıkar. Bir aracı CRM’e, veri ambarına, kimlik sağlayıcısına (SSO) veya destek masasına bağlayamadığınızda; ya da bir gün sağlayıcıyı değiştirmek istediğinizde verinizi temiz biçimde dışarı alamadığınızda, seçim pahalıya mal olabilir.

Bu kontrol listesi, global olarak uygulanabilir pratik sorular ve kanıt talepleri sunar. Referans verilen NIST ve FTC içerikleri ABD’deki standart/düzenleyici tartışmalardan bir bakış açısı sağlar; FTC çalıştayının bir “bağlayıcı hukuk kuralı” olarak yorumlanmaması gerekir. Yaklaşımın omurgası; birlikte çalışabilirlik/taşınabilirlik (NIST), SLA kavramları ve ölçülebilirlik (ISO/IEC 19086) ve müşteri-görünür güvenlik kabiliyetleri (CSA SSCF) üzerinden kurulur. Kaynaklar: NIST SP 500-291, ISO/IEC 19086-1:2016, CSA SSCF, FTC Data To Go çalıştayı.

1) Entegrasyon kontrolü: “Bağlanır” demek yetmez, kanıt isteyin

Bir SaaS ürünü tek başına iyi olsa bile, kurum içi araçlarla veri akışı kuramıyorsa değer üretmesi zorlaşır. NIST’in bulut standartları haritası, birlikte çalışabilirlik ve taşınabilirliği bulut benimsemenin temel konularından biri olarak ele alır; CSA SSCF gibi çerçeveler de müşterinin doğrulayabileceği kabiliyetleri görünür kılmayı hedefler (NIST, CSA).

Entegrasyon için hızlı kontrol listesi

  • API var mı? REST/GraphQL gibi arayüzlerin kapsamı nedir (okuma, yazma, silme, arama, toplu işlem)?
  • Dokümantasyon kalitesi: Uç noktalar, örnek istek/yanıtlar, hata kodları, sayfalama, oran limitleri (rate limit), sürümleme (versioning) açık mı?
  • Kimlik doğrulama: OAuth 2.0 gibi mekanizmalar kurumsal SaaS’larda yaygın bir en iyi pratiktir; sağlayıcı hangi yöntemi destekliyor ve yetki kapsamları/izinleri (scopes) net mi?
  • Webhook/olay akışı: “Bir kayıt değiştiğinde haber verir mi?” sorusu kritik. Webhook imzalama ve başarısız teslimatta retry/backoff gibi yaklaşımlar genel en iyi pratik kabul edilir; sağlayıcıda nasıl uygulanıyor?
  • Standart dışa aktarma formatı: CSV/JSON gibi yaygın formatlarda dışa aktarma mümkün mü? Şema (alan adları ve anlamları) belgelendirilmiş mi?
  • Hazır bağlayıcılar: Zapier, Slack, Google Workspace/Microsoft 365, data warehouse araçları vb. için mevcut entegrasyonlar var mı?
  • Sandbox/test ortamı: Ücretsiz deneme yerine, API test anahtarı ve sandbox ile PoC yapabiliyor musunuz?

Sağlayıcıya sorulacak entegrasyon soruları (kopyala-yapıştır)

  • “API dokümantasyonunun herkese açık bağlantısını paylaşır mısınız? Sürümleme politikanız nedir?”
  • “API oran limitleri nedir, artış için seçenekler var mı?”
  • “Webhook olayları listesi nedir? Teslimat başarısız olursa retry/backoff nasıl çalışır; imzalama/kimlik doğrulama yaklaşımınız nedir?”
  • “Toplu dışa aktarma (bulk export) yapabilir miyim? Ek dosyalar/ekler/yorumlar/audit kayıtları da dahil mi?”
  • “SSO (SAML/OIDC) ve SCIM ile kullanıcı yaşam döngüsü yönetimi kurumsal ortamlarda sık istenir; sizde destek kapsamı nedir?”

Mini PoC: 2 saatte entegrasyon gerçeğini test edin

  1. Bir örnek veri seti oluşturun: 20–50 kayıt, ek/yorum gibi kenar durumlar dahil.
  2. API ile okuma-yazma: Oluştur, güncelle, sil, arama ve sayfalama testleri.
  3. Webhook testi: Bir kaydı güncelleyin; olayın hedef sisteminize düşme süresini ve tekrar deneme davranışını gözleyin.
  4. Dışa aktarma testi: CSV/JSON indirin, alan eşlemesini kontrol edin; eksik alanları not edin.
  5. Geri yükleme/migrasyon provası: Mümkünse içe aktarma (import) yapın; sahadaki gerçek geçişler için kritik olur.

Not: Evrensel tek bir SaaS veri formatı olmadığı için “export var” ifadesi tek başına yeterli değildir. Örnek dışa aktarma dosyası ve şema dokümanı istemek, daha en baştan sürprizleri azaltır (NIST).

2) SLA değerlendirmesi: Ölçülebilir metrik + ölçüm yöntemi + sonuç

SLA (Service Level Agreement) çoğu kişi için “%99.9 uptime” cümlesinden ibaret görünür. Oysa pratikte SLA; hangi metriklerin nasıl ölçüleceğini, istisnaları, olay iletişimini ve ihlal durumunda ne olacağını anlatır. ISO/IEC 19086-1, SLA kavramlarını ve çerçevesini ele alarak metriklerin tanımlanması ve anlaşılabilirliği konusunda referans sağlar (ISO). NIST de bulut hizmetlerinde standartlar, ölçümler ve karşılaştırma zorluklarına işaret eder (NIST).

SLA’da aramanız gereken temel bileşenler

  • Hizmet tanımı: “Hizmet” tam olarak ne? Sadece web arayüzü mü, API mi, entegrasyonlar mı?
  • SLO’lar: Uptime, yanıt süresi, destek yanıt süresi, yedekleme/geri yükleme hedefleri gibi ölçülebilir hedefler.
  • Ölçüm yöntemi: Metrikler sağlayıcının iç ölçümüyle mi, bağımsız izleme ile mi ölçülüyor? Zaman penceresi nedir (aylık mı, 28 gün mü)?
  • Planlı bakım: Bakım pencereleri, ön bildirim ve bakımın SLA hesaplamasına etkisi.
  • Olay yönetimi: Olay bildirimi kanalları, durum sayfası, kök neden analizi paylaşımı.
  • İhlal sonucu: Hizmet kredisi gibi telafiler; talep etme prosedürü; üst sınırlar.
  • Bağımlılıklar ve istisnalar: Müşteri hatası, üçüncü taraf kesintisi, yanlış yapılandırma gibi durumlar nasıl ele alınıyor?

“Doğrulanabilirlik” kırmızı bayrağı

SLA ihlallerini doğrulamak zor olabilir; çünkü sağlayıcılar çoğu zaman metrikleri kendileri raporlar. Bu durum, değerlendirme sırasında bağımsız kanıt veya en azından erişilebilir metrik kayıtları (ör. metrik API’si, ayrıntılı olay günlüğü, üçüncü taraf izleme çıktısı) istemeyi değerli kılar (ISO, NIST).

SLA karşılaştırma pratik yöntemi (puan kartı)

  1. Öncelik verin: Uptime mı kritik, yoksa API gecikmesi mi? Destek yanıtı mı?
  2. Her metriği aynı formatta yazın: “Aylık ölçüm, %X, ölçüm kaynağı Y, istisna listesi Z”.
  3. İstisnaları yan yana koyun: Aynı uptime yüzdesi, farklı istisnalarla çok farklı anlama gelebilir.
  4. Operasyonel süreçleri tartın: Olay iletişimi ve RFO (root cause) paylaşımı, sadece rakam kadar önemlidir.

3) Veri taşınabilirliği ve çıkış planı: “Gerekirse giderim” diyebilmek

Veri taşınabilirliği (data portability), bir SaaS’ı seçerken “yarınki özgürlüğünüzü” belirler: sağlayıcı değiştirme, yedek stratejisi kurma, birleşme/satın alma gibi senaryolarda kritik rol oynar. NIST, bulutta taşınabilirlik ve birlikte çalışabilirlik konularının standart boşlukları ve pratik zorlukları olduğunu vurgular (NIST). ABD’de düzenleyici tartışmalarda da veri taşınabilirliği ve birlikte çalışabilirlik; rekabet, tüketici faydası ve güvenlik boyutlarıyla gündeme gelir (FTC).

Vendor lock-in riskini yükselten tipik durumlar

  • Sağlayıcıya özgü veri formatları: İndirilen dosya var ama alanlar kapalı/şemasız veya eksik.
  • Eksik kapsam: Kayıtlar export ediliyor ancak ekler, yorumlar, etiketler, ilişki tabloları veya audit kayıtları çıkmıyor.
  • API ile export sınırları: Toplu dışa aktarma yok; oran limitleri pratikte taşımayı zorlaştırıyor.
  • Hesap kapatma belirsizliği: Kapatma sonrası veriye erişim süresi, silme politikası ve geri dönüş prosedürü net değil.

Çıkış (exit) kontrol listesi: sözleşmeye girmesi faydalı maddeler

  • Dışa aktarma kapsamı: Hangi veri nesneleri, ekler ve meta veriler dahil?
  • Format: CSV/JSON gibi yaygın formatlar; mümkünse şema dokümantasyonu.
  • Sıklık: İstediğiniz zaman self-service export mu, yoksa talep üzerine mi?
  • Zaman çizelgesi: Talep sonrası teslim süresi (ör. X iş günü gibi net ifade).
  • Maliyet: Export/migrasyon desteği ücretli mi? Ücretlendirme modeli nasıl?
  • Hesap kapatma ve silme: Silme talebi, saklama süresi, yedeklerden silme yaklaşımı nasıl?
  • Geçiş desteği: Belirli bir süre teknik destek veya profesyonel hizmet opsiyonu var mı?

Önemli not (hukuki kapsam): Bu maddeler genel değerlendirme içindir. Sağlık, finans, çocuk verisi veya vergi gibi düzenlemeye tabi veri türlerinde ve ülke/eyalet/bölge kuralları söz konusu olduğunda, kurumunuzun hukuk/uyum ekipleriyle birlikte ilerlemek en güvenli yaklaşımdır.

4) Güvenlik ve erişim kontrolleri: müşteri-görünür kanıt arayın

Güvenlik değerlendirmesi başlı başına geniş bir konu olsa da entegrasyon, SLA ve taşınabilirlik hedeflerini doğrudan etkileyen birkaç müşteri-görünür kontrol alanı vardır. CSA’nın SaaS Security Capability Framework (SSCF) gibi çerçeveler, SaaS sağlayıcısının müşteriye gösterebileceği kabiliyetleri sistematik biçimde toplama fikrini destekler (CSA).

Pratik güvenlik soruları (işe yarayanlar)

  • Erişim günlükleri: Yönetici ve kullanıcı aktiviteleri için denetim kayıtları var mı? Export edilebilir mi?
  • Yetkilendirme modeli: Rol tabanlı yetkiler (RBAC) yeterince ayrıntılı mı? Entegrasyon token’ları en az ayrıcalıkla yönetilebiliyor mu?
  • SSO ve kullanıcı provizyonu: SAML/OIDC ve SCIM gibi mekanizmalar kurumsal ortamlarda yaygın beklentidir; sizde destek kapsamı ve sürümler nedir?
  • Olay iletişimi: Güvenlik olayı bildirim süreci ve kanalları net mi?

5) Tek sayfalık SaaS seçim kontrol tablosu

Aşağıdaki tabloyu tedarikçi görüşmelerinde “kanıt odaklı” ilerlemek için kullanabilirsiniz.

Alan Ne sorulur? İstenen kanıt
API Kapsam, sürümleme, oran limitleri, auth Dokümantasyon linki, örnek istek/yanıt, sandbox anahtarı
Webhook/Olay Olay listesi, imzalama yaklaşımı, retry Webhook rehberi, test eventi, teslimat günlüğü
SLA metrikleri Uptime/latency/support SLO’ları ve ölçüm yöntemi SLA metni, ölçüm tanımı, durum sayfası/rapor örnekleri
İhlal yönetimi Telafi, talep süreci, istisnalar Kredi politikası, örnek vaka akışı
Veri export Kapsam, format, teslim süresi Örnek export dosyası, şema dokümanı, PoC export
Hesap kapatma Silme/saklama, erişim sonu, yedekler Politika dokümanı, sözleşme maddeleri

6) Satın alma akışı: değerlendirmeyi hızlandıran pratik adımlar

  1. Ön koşulları yazın: SSO zorunlu mu, belirli bir entegrasyon şart mı, veri ihracı hangi formatta olmalı?
  2. 2 haftalık PoC planlayın: Entegrasyon testi + export testi + temel performans gözlemi.
  3. Puan kartı kullanın: Entegrasyon (%40), SLA (%30), taşınabilirlik (%30) gibi ağırlıklar tanımlayın.
  4. Sözleşme öncesi kırmızı bayrakları kapatın: Özellikle export kapsamı, zaman çizelgesi ve SLA ölçüm yöntemi.
  5. Çıkış planını ilk günden yazın: Kim, ne zaman, hangi veriyi, hangi adımlarla taşıyacak?

Sık sorulan sorular

SaaS sözleşmesinde hangi SLA maddeleri olmalı?

En azından hizmet tanımı, ölçülebilir SLO’lar (ör. uptime), ölçüm yöntemi, planlı bakımın etkisi, olay iletişimi ve ihlalde telafi/istisnalar net yazılmalıdır (ISO/IEC 19086-1).

Vendor lock-in nasıl azaltılır?

PoC sırasında gerçek bir export alıp kapsamı doğrulayın; açık formatlar (CSV/JSON), belgeli şema ve sözleşmede çıkış zaman çizelgesi/maliyeti gibi maddelerle belirsizliği azaltın (NIST).

“%99.9 uptime” neden tek başına yeterli değil?

Aynı yüzde; farklı istisna listeleri, farklı ölçüm pencereleri ve farklı raporlama biçimleriyle bambaşka bir güvence düzeyi ifade edebilir. Bu yüzden ölçüm yöntemi ve doğrulanabilirlik kritik olur (ISO).

Sonuç

SaaS seçerken doğru soru seti; “özellik” tartışmasını, gerçek hayatta operasyonu belirleyen konulara çeker: entegrasyonun sürdürülebilirliği, SLA’nin ölçülebilirliği ve verinin taşınabilirliği. NIST’in taşınabilirlik/birlikte çalışabilirlik odağı, ISO/IEC 19086’nın SLA çerçevesi ve CSA SSCF’nin müşteri-görünür kontrol yaklaşımı; satın alma sürecini daha denetlenebilir hale getirir (NIST, ISO, CSA). FTC’nin veri taşınabilirliği çalıştayı ise bu konunun yalnızca teknik bir ayrıntı olarak görülmediğini gösteren bir örnektir (FTC).

İsterseniz bu kontrol listesini kendi kullanım senaryonuza göre (ör. e-ticaret, içerik yönetimi, ekip içi dokümantasyon, müşteri destek) uyarlayıp bir “tek sayfa tedarikçi soru listesi” haline getirebilirsiniz.