Teknoloji tedarikçisi; ihtiyacı karşılama, ürün ve entegrasyon uyumu, güvenlik ve mahremiyet, geliştirme ve olay yönetimi, hizmet seviyesi, maliyet, finansal/operasyonel dayanıklılık ve çıkış kabiliyeti üzerinden kanıtla değerlendirilmelidir. Demo ve sertifika tek başına yeterli değildir; kritik iddialar sözleşme, teknik test, referans ve pilotla doğrulanmalıdır.
Tedarikçiyi değil önce ihtiyacı tarif edin
Satın alma süreci ürün demosuyla başladığında kurum, tedarikçinin dilini kendi ihtiyacı sanabilir. İlk belge; çözüm adı değil iş problemi, etkilenen kullanıcı, mevcut süreç, veri türü, entegrasyon, performans, güvenlik, uyum ve başarı ölçütünü tanımlamalıdır.
İhtiyaç dosyasında bulunmalı
Çözülecek iş problemi
Kritik kullanıcı senaryoları
Beklenen hacim ve performans
Veri sınıfları ve konum
Entegrasyon ve kimlik yapısı
Zorunlu güvenlik kontrolleri
Başarı ve kabul ölçütleri
Çıkış ve veri taşıma ihtiyacı
“En iyi yazılım” yoktur; belirli bağlam için en uygun ve yönetilebilir seçenek vardır. Özellik fazlası değer yaratmayabilir, tersine karmaşıklık, eğitim, lisans ve saldırı yüzeyi maliyetini artırabilir.
Sekiz boyutlu değerlendirme modeli
İş ve ürün uyumu
Kritik senaryo gerçekten çalışıyor mu; ürün yol haritasına bağımlı vaatler neler?
Teknik mimari
Entegrasyon, ölçek, performans, erişilebilirlik, kimlik ve gözlemlenebilirlik kurum yapısıyla uyumlu mu?
Güvenlik
Güvenli geliştirme, zafiyet yönetimi, olay müdahalesi ve varsayılan güvenli ayarlar kanıtlanabiliyor mu?
Veri ve mahremiyet
Veri rolü, konumu, alt işleyenler, kullanım amacı, saklama, silme ve aktarım koşulları açık mı?
Hizmet ve operasyon
Destek saatleri, uzmanlık, olay önceliği, bakım, sürüm değişimi ve iş sürekliliği yeterli mi?
Ticari model
Toplam sahip olma maliyeti, artış formülü, ek kullanım, entegrasyon ve profesyonel hizmetler görünür mü?
Kurumsal dayanıklılık
Finansal durum, ekip bağımlılığı, müşteri yoğunluğu, ürün stratejisi ve satın alınma/kapanma riski nedir?
Çıkış ve taşınabilirlik
Veri, yapılandırma ve süreç başka sisteme alınabilir mi; silme ve geçiş desteği sözleşmede mi?
Satış beyanını kanıt hiyerarşisiyle okuyun
| Kanıt düzeyi | Örnek | Nasıl kullanılmalı? |
|---|---|---|
| Beyan | Sunum, pazarlama sayfası, satış temsilcisi cevabı. | Keşif için yararlı; kritik karar için tek başına yeterli değil. |
| Dokümante edilmiş süreç | Güvenlik politikası, mimari belge, SLA, olay prosedürü. | Güncellik, kapsam ve fiilî uygulama kanıtı sorgulanmalı. |
| Bağımsız doğrulama | Denetim raporu, penetrasyon testi özeti, sertifika, referans. | Kapsam, tarih, istisna ve ilgili ürün/hizmet doğrulanmalı. |
| Teknik doğrulama | Pilot, entegrasyon testi, performans ölçümü, güvenlik testi. | Kurumun gerçek senaryosu ve kabul eşiğiyle çalıştırılmalı. |
| Sözleşmesel taahhüt | Hizmet seviyesi, ihlal bildirimi, veri silme, tazmin/çözüm. | İhlal halinde ölçülebilir sonuç ve uygulanabilir hak sağlamalı. |
Sertifika, ürünün tümüyle güvenli olduğu anlamına gelmez. Hangi tüzel kişi, hizmet, bölge ve dönem için verildiği; istisnalar ve son denetim tarihi incelenmelidir. Benzer şekilde büyük müşteri logosu, kurumunuzun kullanım senaryosunun test edildiğini kanıtlamaz.
Güvenlik ve veri tedarik kararının çekirdeğidir
NIST SP 800-161 Rev.1, siber tedarik zinciri riskinin kurumun tüm seviyelerinde tanımlanması, değerlendirilmesi ve azaltılması gerektiğini vurgular. CISA'nın Secure by Demand yaklaşımı da müşterilerin satın alma gücüyle güvenli tasarımı talep etmesini önerir. Bu, güvenlik soru listesini satın alma sonunda göndermek yerine gereksinimleri baştan şartnameye yazmak demektir.
| Alan | Sorulacak soru | Beklenen kanıt |
|---|---|---|
| Güvenli geliştirme | Kod, bağımlılık ve sürüm güvenliği nasıl yönetiliyor? | SDLC/SSDF yaklaşımı, kod inceleme, bağımlılık ve imza süreçleri. |
| Zafiyet yönetimi | Açıklar nasıl bildirilir, önceliklendirilir ve kapatılır? | Politika, SLA, güvenlik bülteni, kritik açık geçmişi ve müşteri bildirimi. |
| Kimlik ve yetki | SSO, MFA, rol, ayrıcalıklı erişim ve kullanıcı kapatma var mı? | Canlı demo, doküman, kayıt ve yönetici kontrolü. |
| Olay müdahalesi | İhlal halinde ne kadar sürede, hangi bilgiyle bildirim yapılır? | Olay planı, sözleşmesel süre, tatbikat ve iletişim hattı. |
| Veri işleme | Veri nerede, hangi alt işleyenlerde, ne amaçla ve ne kadar tutulur? | Veri işleme eki, alt işleyen listesi, saklama/silme ve aktarım mekanizması. |
| İş sürekliliği | Bölge, hizmet veya şirket kesintisinde nasıl devam edilir? | Yedek, RTO/RPO, felaket kurtarma testi ve müşteri çıkış planı. |
KVKK bakımından veri sorumlusu, kendi adına veri işleyen tedarikçinin gerekli teknik ve idari tedbirleri almasını sağlamakla yükümlüdür. Bu nedenle “bulut sağlayıcımız güvenli” cevabı yeterli değildir; ürün sağlayıcının kendi erişimi, alt işleyenleri, destek kanalı ve veri silme işlemi de değerlendirilmelidir.
Ürün uyumunu gerçek senaryoyla test edin
- Kritik senaryo demosu: Tedarikçi önceden hazırlanmış genel sunum yerine kurumun örnek verisi ve akışıyla görevi tamamlar.
- Entegrasyon derinliği: API varlığı tek başına yeterli değildir; kimlik, hata, oran limiti, sürümleme, kayıt ve geri alma davranışı test edilir.
- Yapılandırma / özelleştirme ayrımı: Standart ayarla çözülen ihtiyaç ile özel kod gerektiren ihtiyaç ayrılır; yükseltme etkisi ölçülür.
- Performans ve kapasite: Ortalama demo hızından çok beklenen eşzamanlı kullanıcı, veri hacmi ve tepe yükü denenir.
- Yönetilebilirlik: Yetki, log, rapor, politika, dışa aktarma ve hata ayıklama araçları yönetici kullanıcıyla test edilir.
- Yol haritası riski: Bugün bulunmayan özellik puanlamada varmış gibi kabul edilmez; tarih ve sözleşmesel taahhüt ayrı yazılır.
Liste fiyatı yerine toplam sahip olma maliyetini okuyun
Maliyet; lisansın yanında kurulum, veri taşıma, entegrasyon, eğitim, güvenlik çalışması, danışmanlık, destek seviyesi, depolama, işlem hacmi, model/API kullanımı, yenileme artışı, test ortamı ve çıkış giderlerini içerir. Kullanıcı başına ucuz görünen ürün, yoğun profesyonel hizmet veya veri çıkış maliyetiyle daha pahalı olabilir.
| Ticari soru | Risk | Sözleşmede açıklık |
|---|---|---|
| Fiyat hangi birime bağlı? | Kullanıcı, işlem, veri, API veya özellik artınca öngörülmeyen maliyet. | Birim, dahil kota, aşım ve ölçüm yöntemi. |
| Yenileme nasıl artar? | İlk yıl indirimi sonrası bağımlılık fiyatlaması. | Artış üst sınırı, bildirim ve fesih hakkı. |
| Hangi hizmetler ek ücretli? | Kurulum ve destek için sürekli danışmanlık bağımlılığı. | Kapsam, saat, teslim ve ücret tarifesi. |
| Ürün kapanır veya satılırsa? | Hizmet, veri ve uzman ekip sürekliliği. | Değişiklik bildirimi, çıkış, veri alma ve geçiş desteği. |
Finansal dayanıklılık değerlendirmesi yalnız kârlılık değildir. Nakit süresi, yatırımcı bağımlılığı, ürünün şirket gelirindeki yeri, kritik kişi riski, destek ekibi dağılımı ve müşteri yoğunluğu birlikte okunmalıdır.
Pilot ve puanlama nasıl tasarlanmalıdır?
- Geçme-kalma koşullarını ayırın: Veri konumu, zorunlu entegrasyon veya kritik güvenlik gibi maddeler ağırlıklı puanla telafi edilmemelidir.
- Ağırlıkları iş etkisine göre belirleyin: Güvenlik kritik sistemde yüksek, basit içerik aracında daha düşük olabilir; tek şablon her satın almaya uygulanmaz.
- Aynı senaryoyu tüm adaylara verin: Veri, süre, kullanıcı ve başarı ölçütü karşılaştırılabilir olmalıdır.
- Kanıt düzeyini puana katın: “Var” cevabı ile canlı test veya sözleşmesel taahhüt aynı puanı almamalıdır.
- Kullanıcı ve işletim ekibini birlikte değerlendirin: Kullanılabilirlik kadar yönetim, destek ve hata çözümü de test edilir.
- Pilot sonrası toplam maliyeti güncelleyin: Görülen entegrasyon, veri temizliği ve değişim yönetimi yükü iş planına eklenir.
Sözleşme ve çıkış baştan tasarlanmalıdır
- Hizmet kapsamı, sürüm ve dahil özellikler açıkça tanımlanır.
- Uptime yanında destek yanıtı, olay çözümü, veri kaybı ve bakım bildirimi ölçülür.
- Veri sorumlusu/veri işleyen rolleri, alt işleyen ve yurt dışı akışları açıklanır.
- İhlal, kritik zafiyet ve önemli ürün değişikliği bildirim süreleri yazılır.
- Veri dışa aktarma formatı, teslim süresi, ücret ve silme kanıtı belirlenir.
- Fikri mülkiyet, özel geliştirme, yapılandırma ve eğitim verisi hakları ayrılır.
- Denetim, kanıt talebi ve düzeltici faaliyet hakları riskle orantılı kurulur.
- Fesih yardımı, geçiş dönemi ve hizmet kesintisizliği tanımlanır.
Değerlendirme imzayla bitmez
Tedarikçi riski ürün, tehdit ortamı, sahiplik, alt işleyenler ve finansal durum değiştikçe değişir. Kritik tedarikçiler için yıllık form göndermek yerine olay ve değişiklik odaklı izleme kurulmalıdır.
İzlenecek sinyaller
Kritik güvenlik olayları
Zafiyet kapanış performansı
SLA ve destek eğilimi
Alt işleyen değişiklikleri
Ürün/sürüm sonlandırma
Fiyat ve kullanım artışı
Finansman veya sahiplik değişimi
Veri taşıma ve çıkış testi
İş sahibi, BT, güvenlik, hukuk/uyum, satın alma ve finansın aynı risk kaydına bakması gerekir. Sorunlar yalnız tedarikçi yöneticisinin e-postasında kaldığında kurum çapında bağımlılık görünmez olur.
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.
- 01NIST SP 800-161 Rev. 1 — Cybersecurity Supply Chain Risk Management
Ürün ve hizmet tedarik zinciri riskini kurum seviyelerinde yönetme rehberi.
- 02CISA — Secure by Demand Guide
Yazılım müşterilerinin satın alma sürecinde güvenli tasarımı talep etmesi için soru ve değerlendirmeler.
- 03CISA — Software Acquisition Guide
Yazılım ediniminde ürün güvenliği ve tedarik zinciri değerlendirme yaklaşımı.
- 04ENISA — Good Practices for Supply Chain Cybersecurity
Tedarikçi ilişkilerinde organizasyonel, süreçsel, teknik ve sözleşmesel iyi uygulamalar.
- 05KVKK — Kişisel Veri Güvenliği Rehberi
Veri işleyenle sözleşme, ihlal bildirimi ve teknik/idari tedbir sorumlulukları.