Vendor-Management für SaaS: Vertragsklauseln, die IT und Einkauf früh prüfen sollten

An hoş olmayan derecede tanıdık bir an: İlgili birim bir SaaS çözümünü test etti, pilot „aslında iyiydi“, ticari taraf hız istiyor — ve gelen kutusuna „sadece imzalamanız gerekiyor“ notuyla bir sözleşme paketi düşüyor ki rollout başlasın. En geç şimdi belirlenir: SaaS için SaaS için Tedarikçi Yönetimi kurumunuzda yerleşik bir süreç mi yoksa satın alma ile IT zaman baskısı altında ileride işletmeyi belirleyecek hususları mı kabul ediyor: açıklanmamış veri akışları, gerçek bir eskalasyon mekanizması olmayan destek, güvenilir değişiklik kuralları olmayan entegrasyonlar — ve yalnızca kağıt üzerinde var olan bir çıkış.

Belirleyici yönlendirme ince yazılarda değil, öncelik sırasındadır: Hangi maddeler erken masaya konulmalıdır çünkü verileri, uyumluluğu, işletme kabiliyetini ve bağımlılıkları şekillendirir? Ve hangi ayrıntılar ikincil bırakılabilir, kontrolü ve planlanabilirliği kaybetmeden?

SaaS için Tedarikçi Yönetimi pratikte

Uygulamada şirketler SaaS sözleşmeleriyle nadiren „iyi ya da kötü“ ikilemiyle karşılaşır; daha çok üç seçenekle karşılaşırlar:

• Seçenek A: Standart sözleşmeyi kabul etmek ve her şeyin yolunda gideceğini ummak. Bu hızlıdır, ancak riskler daha sonra işletme ve denetim hazırlığında ortaya çıkar.
• Seçenek B: Her şeyi müzakere etmek ve sözleşmeyi ilkesel bir tartışma haline getirmek. Bu sıkça süreci tıkar — garantili olarak daha iyi sonuçlar getirmeyebilir.
• Seçenek C: Önceliklendirilmiş müzakere: birkaç madde grubunu tutarlı şekilde teminat altına almak, gerisini pragmatik şekilde ele almak. Bu genellikle IT, satın alma ve ilgili birim için en iyi uzlaşıdır.

Amaç çatışması bellidir: satın alma hızı ile güvenilir işletme ve çıkış kabiliyeti arasında. Bunu açıkça ele almayanlar zımnen karar verir — çoğunlukla hız lehine. Fatura daha sonra entegrasyonlar, destek ve geçişte ek iş yükü olarak gelir.

Karar akışı: IT ve satın almanın hangi sırayla inceleme yapması gerektiği

İşleyen bir inceleme yolu günlük kullanım için yeterince kısa — ve temel varsayımlar üzerine tartışmayı önleyecek kadar somut olmalıdır. Aşağıdaki sıra sağlamdır çünkü önce işletme görünümünü netleştirir, sonra müzakereye girilebilecek riskleri önceliklendirir.

1. Koruma gereksinimi & veri türlerini belirleyin: Hangi veriler SaaS içinde yer alacak (kişisel veriler, gizli bilgiler, ticari sırlar)? Hangi süreçler buna bağlı ve kabul edilebilir kesinti sonuçları neler olur?
2. Roller ve sorumlulukları netleştirin: Siz „Verantwortlicher“ (Controller) misiniz ve sağlayıcı „Auftragsverarbeiter“ (Processor) mı? Yoksa müşterek sorumluluk konstelasyonu mu var?
3. İşletme görünümünü taslak halinde çizin (mimari roman yazmadan): SSO (Single Sign-on), provisioning, API/Exports, logging, monitoring, destek kanalları, yönetici erişimleri.
4. En önemli maddeleri kontrol edin: DPA/DSGVO, alt yükleniciler, Güvenlik/Olaylar, SLA/Destek, veri konumu/transferler, Çıkış/Taşınabilirlik.

İş birliği için net bir görev ayrımı yardımcı olur: Satınalma pazarlığı ve süreleri yürütür, IT işletmeye ilişkin asgari kriterleri sağlar, Veri Koruma/Compliance zorunlu gereksinimleri onaylar. Bu roller birbirine karıştığında karar alma süreci ağırlaşır — veya „önce imzalayalım“ moduna kayılır.

İlk olarak masaya konması gereken hükümler

Birçok sözleşme biçimsel olarak eksiksiz görünür ama işletmedeki gerçeklikle baş edemez. Tablo tipik hüküm alanlarını somut sonuçlara çevirir. „Bugün karar vermeliyiz“ ile „yarın işletmemiz gerekiyor“ durumlarının karşılaştığı yerde önceliklendirme için uygundur.

DPA, DSGVO ve “Return or Delete”: neden bunun bir ek konusu olmadığı

SaaS içinde kişisel veriler işlendiği anda (kullanıcı verileri, müşteri verileri, İK verileri, protokoller), veri koruma bölümü “dosyalık bir belge” değil, işletme yeterliliğinizin bir parçasıdır. EDPB kılavuzları, işleme sona erdiğinde kişisel verilerin sorumlu tarafından silinmesi veya iade edilmesi ve mevcut kopyaların silinmesi gerektiğini netleştirir.^[Quelle] Pratik sonuç: Exit sadece “Export” demek değildir, aynı zamanda Löschungskette—yedekler ve ilgili alt yükleniciler dahil—anlamına gelir.

Sınır detayda belirir: Bir DPA resmi olarak doğru olabilir ama yine de yedek bağlamında silmenin nasıl işleyeceğini, kurtarma noktalarının ne kadar süre saklanacağını veya “silme doğrulaması”nın somut olarak nasıl göründüğünü açık bırakabilir. Bu boşluk hukuki terimlerle kaybolmaz. Ancak bir senaryoyu oynadığınızda kaybolur: “X tarihine kadar feshediyoruz. Hangi veriler ne zaman nerede duruyor, kim hâlâ görebiliyor ve kesin olarak ne zaman biter?”

Subunternehmer-Ketten: Transparenz ist gut, Steuerbarkeit ist besser

SaaS’te alt yükleniciler normaldir: hosting, monitoring, destek araçları, e-posta teslimatı, analytics, ticketing. Önemli olan alt yüklenicilerin varlığı değil, onların kullanımını kontrol edebilmenizdir. ICO kılavuzları, sorumluların müdahale edebilmesi için onay (spesifik veya genel) ve değişiklikler için bir bilgilendirme mekanizmasının gerekli olduğunu vurgular.^[Quelle] Pratikte bu şudur: PDF olarak bir alt yüklenici listesi ancak başlangıçtır. Ön bildirim, bilgilendirme kanalı ve itiraz mantığı olmadan o liste sadece bir arşiv belgesidir.

IT ve satın alma için “Liste var mı?” sorusunun ötesine geçen bir kontrol sorusu faydalıdır: Alt yüklenici sayesinde hangi yeni yetenek ortaya çıkıyor? Bir CDN, yönetici oturumlarına izin veren bir destek aracıyla farklı değerlendirilmelidir. Ve telemetri için bir observability hizmeti, birincil hosting bölgesiyle eşleşmeyen coğrafi bölgelerde çalışabilir.

SaaS modelini zorlamadan genellikle pazarlık konusu olabilecekler:

• Ön bildirim süreleri alt yüklenici değişiklikleri için (iç değerlendirme yapabilmeniz amacıyla).
• İtiraz veya özel fesih hakları kabul edilemez değişiklikler durumunda.
• Sınıflandırma veri kategorilerine göre: Özellikle kritik veriler için daha sıkı kurallar geçerlidir.

SLA und Support: Messen statt behaupten

Birçok SLA, öne çıkan bir yüzde rakamı olduğu için iyi görünür. Arıza durumunda ise ölçüm yöntemi, istisnalar ve bakım pencerelerinin o kadar esnek formüle edildiği ortaya çıkar ki rakamın anlamı azalır. WorldCC SaaS Contracting Guide SLA’leri merkezi pazarlık noktaları olarak tanımlar — Service Credits gibi telafi mekanizmaları ve tekrarlanan yerine getirmeme durumlarındaki sonuçlar dahil.^[Kaynak] Operasyon açısından bundan şu çıkar: IT, sözleşme imzalanmadan önce kendi sürecinde gerçekten hangi kullanılabilirliğin önemli olduğunu (UI, API, bölge, çekirdek işlemler) ve gerektiğinde bunun nasıl kanıtlanabileceğini tanımlamalıdır.

„Kâğıt“ ile „işletim aracı“ arasındaki farkı yaratan üç SLA bileşeni:

• Ölçüm yöntemi: Kim ölçüyor, hangi noktada (UI, API uç noktası, bölge)? Kısmi kesintiler, performans bozulması veya oturum açma sorunları nasıl değerlendiriliyor?
• Bakım penceresi: planlanabilir, sınırlı, net bir duyuruyla. „Her zaman mümkün“ pratikte bakım penceresi değil, bir risktir.
• Destek mekanizması: Öncelikler (P1–P4), tepki ve güncelleme döngüleri, eskalasyon seviyeleri ve iletişim kanalı.

Satın alma açısından günlük hayatta etkili olan kaldıraç da buna dahildir: tekrarda görülecek hukuki sonuçlar. Service Credits bütçeleri rahatlatabilir, ancak süreç bağımlılığını ortadan kaldırmaz. SaaS kritik bir akış için gerekiyorsa, tekrarlanan SLA ihlallerinde özel fesih hakkı genellikle daha belirleyici bir teminattır.

Güvenlik hükümleri: Asgari standartlar, olay müdahale süreci ve kanıtlar

Güvenlik hükümleri nadiren „güvenlik“ istemeyen bir taraf yüzünden başarısız olur; daha sık başarısızlık nedeni ifadelerin doğrulanamaz kalmasıdır. Canadian Centre for Cyber Security, bulut sözleşmelerinde güvenlik gereksinimlerinin açıkça yer almasını; bunlar arasında olay müdahale ve bildirim yükümlülükleri ile güvenli veri imhasını önermektedir.^[Kaynak] Bu, IT için günlük kullanımda değerlidir çünkü tartışmayı „Best Effort“ten somut yükümlülüklere kaydırır: Kim neyi, ne kadar hızlı ve hangi kanalla bildirir?

Pratik bir güvenlik bloğu her detayı tek tek yazmak zorunda değildir, ancak net asgari maddelere ihtiyaç duyar:

• Kimlik doğrulama ve erişim: Ayrıcalıklı hesaplar için MFA, rol modeli, ilke olarak Least Privilege (asgari yetki verme).
• Şifreleme: iletişim ve depolama sırasında; ayrıca anahtar yönetimi (döndürme, erişim sınırlamaları).
• Olay/İhlal süreci: bildirim süreleri, asgari bilgiler (etkilenen veri türleri, dönem, ilk alınan önlemler), düzenli güncellemeler.
• Günlükleme ve adli destek: Hangi kayıtlar mevcut, ne kadar süre saklanıyor ve olayda ilgili verileri nasıl alırsınız?
• Kanıtlar: Hangi attestelerin veya standartlaştırılmış raporların düzenli olarak sağlanacağı.

Tipi̇k engel şudur: Birçok sağlayıcı sınırsız yerinde denetim hakkını kabul etmez. Buna takılı kalmak yerine kademeli bir güvence modeli genellikle daha etkili olur: düzenli attesteler, standart soru formları/portallar ve geri sorgulamalar için bir eskalasyon hakkı. Böylece sağlayıcı için yapısal olarak sağlanması mümkün olmayan bir noktada sözleşmeyi riske atmadan kanıt elde edersiniz.

Veri lokasyonu ve uluslararası veri transferleri: „EU-Hosting“ ile yetinmeyin

„Veriler AB içinde bulunuyor“ ifadesi net gibi görünür, ama nadiren öyledir. Sözleşmeler açısından en az dört veri konumu önem taşır: birincil veriler, yedekler, telemetri/loglar ve destek erişimleri (uzaktan yönetim). Bu yolların herhangi biri üçüncü ülkelere çıkıyorsa, uluslararası veri transferleri pratikte önem kazanır. EDPB, ne zaman uluslararası veri transferi söz konusu olduğunu ve bunları hukuken güvence altına almak için tipik olarak hangi mekanizmaların kullanıldığını açıklıyor.^[Kaynak] Satın alma ve BT için sonuç: veri akışları hizmet kapsamına dahil edilmelidir — izole bir gizlilik maddesinde bırakılmamalıdır.

Pratikte yararlı olan, genel vaadeler yerine net ifadeler içeren kısa bir sözleşme eki olacaktır:

• Bölgeler işleme ve depolama için (yedeklemeler dahil).
• Taşınma kuralları: kim değiştirebilir, hangi ön bildirim süresiyle, hangi bilgilerle.
• Destek erişimleri: yalnızca ticket tabanlı, zamanla sınırlı, kayıtlı; gerekirse ek olarak maskelenme veya kısıtlayıcı roller.

Exit, taşınabilirlik ve silme: küçümsenen maliyet ve risk tetikleyicisi

Vendor Lock-in nadiren tek bir maddeyle oluşur. Genellikle çıkış mekanizmasının eksikliği, entegrasyonlar ve zaman baskısının birleşimiyle meydana gelir. Exit yalnızca „verileri dışa aktarmak“ anlamına gelmez; aynı zamanda „verilerin ve kopyaların silinmesini talep etmek“ anlamına da gelir. EDPB rehberleri, veri işleme faaliyeti sonunda veri işleyici ilişkilerinde „delete or return“ ilkesini vurguluyor.^[Kaynak] Proje planlaması açısından bu belirleyicidir: net kurallar olmadan geçişi ve devre dışı bırakmayı güvenilir şekilde zamanlayamazsınız.

İyi çıkış kuralları uzun değil, kullanılabilir ve somut olmalıdır:

• Dışa aktarma formatları: makine tarafından okunabilir (ör. CSV/JSON), eksiksiz (meta veriler ve referanslar dahil), belgelenmiş.
• Erişim pencereleri: sözleşme sona erdikten sonra erişim ne kadar süreyle sağlanıyor, dışa aktarma verileri ne kadar süre erişilebilir?
• Destek: tanımlanmış bir kota veya açıkça tarif edilmiş hizmetler (örn. dışa aktarma çalıştırma, doğrulama, veri eşlemesi danışmanlığı).
• Silme süreci: yedeklerle muamele, süreler, kanıt (silme onayı), alt yüklenici zincirinin dahil edilmesi.

Ek bir iç manivela: Çıkış yeteneğini ancak fesih anında test etmeyin. Kritik SaaS’ler için yıllık bir „dışa aktarma gerçeklik kontrolü“ genellikle planlanabilir bir geçiş ile projede sürpriz arasındaki farktır.

Değişiklik maddeleri: API, fiyat mantığı veya limitler değiştiğinde

SaaS sürekli değişir. Bu işlevsel olarak çoğu zaman istenir — sözleşme açısından ise tek taraflı değişikliklerin mümkün olup sizin haklarınız veya ön bildirim süreleriniz olmadığında risklidir. Özellikle entegrasyon noktalarındaki değişiklikler (APIs, Webhooks, SSO), lisans metriklerindeki değişiklikler (True-ups, neue Pflicht-Add-ons) ve veri işlevlerindeki değişiklikler (Export, Aufbewahrung, Logging) kritik öneme sahiptir.

Satın alma açısından burada liste fiyatından daha az önemli olan değişiklik mekanizmasıdır: Hangi değişiklikler „özgün/önemli“ sayılır, ne kadar erken duyurulur ve bundan hangi haklar doğar (itiraz, özel fesih, geçiş süreleri)? IT için ayrıca önemli olan, geri uyumluluğu bozan değişikliklerin „bir gün“ değil, kullanımdan kaldırma süreleri ve test imkanları ile planlanabilir olmasıdır. Aksi takdirde SaaS bakımı sürekli tekrarlayan bir acil müdahale haline gelir.

Tedarikçi yönetimi sürekli bir yönetimdir, imza değil

İmzalanmış bir sözleşme riskleri otomatik olarak durdurmaz. NIST, Cybersecurity Supply Chain Risk Management’i sürekli bir uygulama olarak tanımlar: değerlendirmek, izlemek, sapmalara yanıt vermek ve geçiş/sonlandırmayı düşünmek.^[Kaynak] Kurumlar için bundan çıkan basit ilke şudur: Riskleri yalnızca sözleşme imzalanırken ele alıyorsanız, hareketli bir hedefi durağan bir görüntüyle değerlendiriyorsunuz demektir.

Bağlayıcı olduğu sürece genellikle sade bir ritim yeterlidir:

• Üç aylık: SLA ve destek değerlendirmesi (Ticketler, eskalasyonlar, kesintiler) ile büyük değişikliklerin/kullanımdan kaldırılmaların gözden geçirilmesi.
• Altı aylık: Alt yüklenici değişikliklerini ve ilgili kanıtları (Attestate/Reports) inceleyin, sapmaları belgeleyin.
• Yıllık: Çıkış incelemesi (Exports), yetki ve rol incelemesi, koruma gereksinimi ve bağımlılıkların güncellenmesi.

Önemli olan frekans değil, ortaya çıkan belge/artefaktın varlığıdır: Ne karar verildiğini, nedenini ve hangi takip görevlerinin doğduğunu gösteren kısa bir karar kaydı veya bir risk kaydı. Bu iz olmadan tedarikçi yönetimi e-posta aramasına dönüşür.

Hemen etki eden ilk adım: teklif öncesi bir „Klausel-Intake“

Eğer yalnızca bir süreç değişikliği uygulamak istiyorsanız, bunu yapın: Vendor-Management’ı SaaS için somut tekliften önce başlatın. Bir birim bir SaaS’i kısa listeye aldığı anda, satın alma ve IT ile yapılacak 30–45 dakikalık bir toplantı genellikle sınırları belirlemek için yeterlidir: koruma gereksinimi, entegrasyonlar, DPA/Incident/SLA için asgari gereksinimler ve minimal bir çıkış şartı.

Faydası doğrudandır: Sonradan pazarlık yapılamayan sözleşme koşullarına takılan pilot uygulamalardan kaçınırsınız. Ayrıca sağlayıcıya erken dönemde hangi noktaların „iyi olur“ değil, tedarik şartı olduğunu net biçimde gösterirsiniz.

Son düşünce: Ein SaaS-Vertrag ist Betriebsdesign in Textform

Çoğu SaaS sorunu, bir ürünün teknik olarak yetersiz olmasından değil, sözleşmenin sonraki gerçekliği yansıtmamasından kaynaklanır: veri akışları, destek erişimleri, alt yüklenici değişiklikleri, ölçüm yöntemleri ve çıkış. Bu noktaları erken önceliklendirenler devreye almayı yavaşlatmaz — bunun yerine işletme ve uyumun daha sonra sürekli bir projeye dönüşmesini engeller.

Kritik SaaS için kısa, tekrarlanabilir bir inceleme yolu oluşturmak veya mevcut sözleşmelerin çıkış ve taşınabilirlik kurallarını sıkılaştırmak istiyorsanız, veri, arayüzler ve işletme süreçlerine yapılandırılmış bir bakış mantıklı bir başlangıç noktasıdır.

Bu konu için ayrıca SaaS sözleşmeleri ve Vendor Lock-In’den kaçınma önemlidir. Bu yazı bu hususları anlaşılır şekilde ele alır ve günlük uygulamada hangi konuların kritik olduğunu gösterir.

Proje veya modernizasyon girişimini Net-Base ile görüşün.