Üçüncü taraf siber risk yönetimi; tedarikçileri iş kritikliği, veri erişimi, teknik entegrasyon ve ikame zorluğuna göre sınıflandırır; gereksinimleri sözleşmeye ve teknik kontrole dönüştürür; olay, değişiklik ve alt yüklenici riskini hizmet boyunca izler; çıkışta veri, hesap, anahtar ve bağımlılıkların güvenli biçimde kaldırılmasını doğrular. Tek seferlik anket veya sertifika bu yaşam döngüsünün yerine geçmez.
Üçüncü taraf riski, satın alma dosyasından daha geniştir
Tedarikçi; kurumun sistemine yazılım sağlayabilir, kullanıcı kimliklerine erişebilir, kişisel veri işleyebilir, kritik üretim sürecini çalıştırabilir veya başka alt yükleniciler kullanabilir. Risk yalnız tedarikçinin saldırıya uğraması değildir. Yanlış yapılandırma, hizmet kesintisi, finansal sorun, lisans değişikliği, habersiz alt işleyen, veri taşınamazlığı ve sözleşme sonrasında silinmeyen hesaplar da kurumsal etki doğurur.
Kritiklik sınıflandırması doğru soruları belirler
| Boyut | Soru | Yüksek risk göstergesi |
|---|---|---|
| İş etkisi | Hizmet durursa hangi süreç ve gelir etkilenir? | Saatler içinde kritik operasyonun durması. |
| Veri | Hangi veri sınıflarını işler, saklar veya aktarır? | Özel nitelikli, finansal veya ticari sır verisi. |
| Erişim | Hangi sistem ve ayrıcalıklara bağlanır? | Yönetici, üretim veya geniş API yetkisi. |
| Bağımlılık | Alternatife geçiş ne kadar sürer? | Kapalı format, özel entegrasyon ve uzun veri çıkışı. |
| Alt zincir | Hangi alt yüklenici ve bulut hizmetlerini kullanır? | Şeffaf olmayan veya tek noktada yoğunlaşan zincir. |
| Dış yüzey | İnternete açık mı, kurum adına işlem yapıyor mu? | Kimlik, ödeme, mesaj veya müşteri iletişimi yetkisi. |
Sonuç, “düşük–orta–yüksek” etiketten ibaret kalmamalıdır. Her seviye için inceleme kanıtı, onay makamı, tekrar değerlendirme sıklığı ve sözleşme şartı tanımlanmalıdır.
Ön inceleme beyan değil, kanıt toplamalıdır
- Kurumsal ve finansal durum: Hizmet sürekliliğini etkileyebilecek sahiplik, finansal ve hukuki riskler.
- Güvenlik yönetişimi: Sorumluluk, politika, varlık yönetimi, risk ve bağımsız denetim kapsamı.
- Kimlik ve erişim: MFA, ayrıcalıklı hesap, görevler ayrılığı, destek erişimi ve hesap kapatma.
- Ürün güvenliği: Güvenli geliştirme, bağımlılık, zafiyet, güncelleme ve değişiklik süreci.
- Veri koruma: Veri lokasyonu, şifreleme, saklama, silme, yedek ve alt işleyenler.
- Olay ve süreklilik: Bildirim, müdahale, kurtarma hedefi ve test kanıtı.
- Çıkış: Veri dışa aktarma, format, süre, destek ve güvenli silme.
Sertifika kapsamı ürün, lokasyon ve dönem bakımından kontrol edilmelidir. ISO veya SOC raporunun bulunması, ilgili hizmetin bütün risklerini otomatik olarak kapsamaz. Bulgular, istisnalar ve telafi edici kontroller görünür karara bağlanmalıdır.
Güvenlik gereksinimi sözleşmede uygulanabilir olmalıdır
| Konu | Asgari beklenti | Zayıf ifade örneği |
|---|---|---|
| Olay bildirimi | Tanım, süre, içerik, güncelleme ve iletişim kanalı. | “Makul sürede bilgilendirir.” |
| Alt yüklenici | Liste, değişiklik bildirimi, eşdeğer yükümlülük ve itiraz süreci. | “Gerekli görülen üçüncü kişiler kullanılabilir.” |
| Denetim/kanıt | Uygun rapor, test özeti, soru yanıtlama ve kritik bulgu takibi. | Yalnız pazarlama güvenlik sayfasına atıf. |
| Veri yaşam döngüsü | Lokasyon, kullanım, saklama, yedek, iade ve silme teyidi. | Silme yöntemi ve süresi belirtilmemiş. |
| Değişiklik | Kritik ürün, mimari, veri veya sahiplik değişikliğinin bildirimi. | Tedarikçinin tek taraflı sınırsız değişiklik hakkı. |
| Çıkış | Makine-okunur veri, süre, destek, maliyet ve erişim iptali. | Veri dışa aktarımı “var” fakat format ve süre yok. |
Sözleşme maddesi teknik gerçeklikle doğrulanmalıdır. Örneğin “veri silinir” hükmü varsa aktif sistem, yedek, log ve alt işleyenlerde nasıl ve ne zaman silineceği tanımlanmalıdır.
Teknik entegrasyon risk kararıyla aynı anda tasarlanmalıdır
Ayrı servis hesabı
Kişisel yönetici hesabı yerine görevle sınırlı, izlenebilir servis kimliği kullanılır.
En az ayrıcalık
API kapsamı, ağ yolu, veri alanı ve işlem limiti ihtiyaca göre sınırlandırılır.
Secret yönetimi
Anahtar kodda tutulmaz; rotasyon, son kullanma ve olay halinde iptal planı bulunur.
Bağımsız iz
Tedarikçi loguna ek olarak kurum, kritik erişim ve işlemi kendi tarafında izler.
Test ortamı ve üretim erişimleri ayrılmalı, varsayılan açık port veya geniş IP izinleri kaldırılmalı, destek erişimi süreli ve onaylı olmalıdır. Yeni entegrasyon açıldığında tedarikçi kaydı otomatik olarak varlık ve risk envanterine girmelidir.
Yıllık anket, sürekli değişimi yakalamaz
Tedarikçinin ürün sürümü, alt işleyeni, bulut bölgesi, şirket sahibi veya güvenlik olayı yıl içinde değişebilir. İzleme modeli, risk seviyesine göre farklı sinyalleri takip etmelidir.
- Kritik güvenlik ve gizlilik sayfası değişiklikleri.
- Alt işleyen ve veri lokasyonu güncellemeleri.
- Zafiyet, olay ve hizmet kesintisi bildirimleri.
- Sertifika ve bağımsız rapor geçerlilik tarihleri.
- API kapsamı, kullanıcı sayısı ve ayrıcalıklı erişim değişiklikleri.
- SLA performansı, kurtarma testi ve destek gecikmeleri.
- Finansal, sahiplik veya birleşme/satın alma gelişmeleri.
- İstisna ve açık bulguların kapanma durumu.
İzleme gerçek zamanlı SOC iddiasına dönüştürülmemelidir. Kurumun elindeki kanıt ve erişim düzeyi neyse, raporlama sınırı açıkça belirtilmelidir.
Olay ve iş sürekliliği birlikte yönetilmelidir
Tedarikçi olayında kurumun kiminle iletişim kuracağı, hangi veriyi isteyeceği ve kendi müşterilerine/otoritelere karşı sorumluluğu önceden belirlenmelidir. Olay bildirimi yalnız “ihlâl oldu” mesajı değil; etkilenen hizmet, veri, zaman aralığı, alınan önlem, kanıt ve sonraki güncelleme planını içermelidir.
| Senaryo | Hazırlık |
|---|---|
| Tedarikçi hizmeti kesildi | RTO/RPO, manuel süreç, alternatif hizmet ve iletişim planı. |
| Kimlik bilgisi sızdı | Anahtar iptali, token rotasyonu, oturum sonlandırma ve log analizi. |
| Veri ihlali şüphesi | Veri kapsamı, delil, bildirim yükümlülüğü ve etkilenen kişi değerlendirmesi. |
| Tedarikçi faaliyetini durdurdu | Veri ihracı, geçiş ekibi, lisans devamlılığı ve kaynak kod/escrow ihtiyacı. |
Çıkış planı sözleşme sonunda değil, seçim aşamasında hazırlanır
- Veri: Hangi formatta, hangi süre içinde ve hangi bütünlük kanıtıyla alınacak?
- Entegrasyon: API, webhook, kimlik sağlayıcı ve otomasyon bağlantıları nasıl sökülecek?
- Hesap: Kullanıcı, servis hesabı, anahtar, sertifika ve destek erişimleri nasıl kapatılacak?
- Silme: Aktif veri, yedek, log ve alt işleyen kopyaları için teyit nasıl alınacak?
- Geçiş: Paralel çalışma, kabul testi, sorumluluk ve ek maliyet nedir?
- Kanıt: Çıkış tamamlandığında kim hangi belgeyi onaylayacak?
Yönetişim modeli ve karar kapıları
| Kapı | Sorumlu katkılar | Çıktı |
|---|---|---|
| Talep | İş birimi + satın alma | İş ihtiyacı, veri ve kritik süreç tanımı. |
| Risk | Siber güvenlik + veri koruma + hukuk | Risk sınıfı, gereksinim ve açık bulgu. |
| Teknik | BT/mimari | Entegrasyon, kimlik, log ve çıkış tasarımı. |
| Onay | Risk sahibinin yetki seviyesine göre | Kabul, şartlı kabul veya ret. |
| İşletim | Hizmet sahibi + tedarikçi yöneticisi | SLA, değişiklik, olay ve yeniden değerlendirme. |
| Çıkış | İş, BT, güvenlik ve satın alma | Veri, erişim ve bağımlılık kapanış kanıtı. |
NIST CSF 2.0, tedarik zinciri risk yönetimini yönetişim fonksiyonu altında ele alır. Bu yaklaşım, konunun yalnız güvenlik ekibine bırakılmaması; risk sahibinin, satın almanın, hukukun ve iş biriminin birlikte karar vermesi gerektiğini destekler.
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 — CSF 2.0 Quick-Start Guide for C-SCRM
CSF GV.SC kategorisiyle tedarik zinciri risk yönetimi yeteneği ve tedarikçi gereksinimleri kurmayı açıklar.
- 02NIST — Cybersecurity Framework 2.0
Siber riskin yönetişim dâhil bütün kurum ölçeğinde yönetilmesine yönelik çerçeve.
- 03NIST — Cybersecurity Supply Chain Risk Management
Tedarik zinciri boyunca risklerin belirlenmesi, değerlendirilmesi ve azaltılmasına ilişkin resmî kaynaklar.
- 04CISA — ICT Supply Chain Risk Management
Üçüncü taraf güvencesi ve tedarik zinciri risk programı için resmî rehberlik.
- 05CISA — Vendor SCRM Template
Tedarikçi risk planlamasında kullanılabilecek standartlaştırılmış soru alanlarını sunar.