İçeriğe atla
Makale

Tedarikçi anketi biter bitmez bayatlıyor — TPRM'i nasıl döngüsel çalıştırırsınız

Yıllık tedarikçi değerlendirmesi cevap-anında doğru, üç ay sonra geçersiz. Döngüsel TPRM'in dört adımı — değerlendirme, kanıt, sürekli izleme, bildirim — ve kritiklik ile riskin neden ayrı eksen olduğu.

4 Haziran 2026
8 dk okuma
Tedarikçi RiskiUyumlulukKeşif

Bir kurumun en hassas verisi artık yalnızca kendi sunucularında durmuyor. Müşteri kayıtları bir CRM SaaS'ında, çalışan özlük dosyaları bir İK platformunda, ürün telemetrisi bir analitik sağlayıcının veritabanında işleniyor. Her tedarikçi, sizin verinizin ikinci bir sahibi konumunda. Tedarikçide yaşanan bir ihlal — neredeyse her örnekte — sizin güvenlik vakanıza dönüşüyor; KVKK denetçisinin sorusu sizin masanıza geliyor.

Buna rağmen Türkiye'deki çoğu kurumun tedarikçi risk yönetimi (TPRM) süreci hâlâ aynı kalıptan ibaret: yılda bir kez Excel anketi gönderilir, geri dönen cevaplar arşivlenir, denetim zamanı geldiğinde klasör açılır. Bu modelin pratikteki en büyük sorunu şu: anket, geri döndüğü an güncelliğini yitirmiş oluyor.

Bu yazıda yıllık değerlendirme modelinin neden yapısal olarak çöktüğünü, SIG-Lite gibi standart anketlerin neden zemin olduğunu (tavan değil), "kritiklik" ile "risk"in aynı şey OLMADIĞINI ve döngüsel TPRM'in dört adımını anlatıyoruz.

1. Yıllık modelin yapısal sorunu

Klasik tedarikçi değerlendirmesi şu adımları izler:

  • Tedarikçi listesi çıkarılır (genellikle satınalma tarafından)
  • Her birine bir anket gönderilir (SIG-Lite, kurum-içi şablon vb.)
  • Cevaplar elle toplanır
  • Bir risk skoru biçilir
  • Klasör kapanır

Anket cevap-anında doğru

Tedarikçi, ankete cevap verdiği gün hangi kontrolleri uyguladığını beyan eder. Üç ay sonra mimari değişebilir, bir alt-işleyen eklenebilir, kritik bir kontrol sorumlusu ayrılabilir. Anketteki ifadeler hâlâ doğru görünür ama gerçekle bağı kopmuştur.

Kanıt eskir

SOC 2 raporu 12 ay geçerli, ISO 27001 sertifikası üç yıllık. Yenileme arasındaki dönemde tedarikçinin kontrolleri kâğıt üzerinde sağlam görünür — pratikte boşalmış olabilir.

Olay bildirimi yoktur

Tedarikçinin hayatında bir ihlal olduğunda kurumunuza ulaşması haftalar sürebilir; bazen hiç ulaşmaz. Anket "ihlal yaşadınız mı" sorusunu yıllık ritimde sorar; aradan geçen aylarda olan biten kurumunuzun radarına girmez.

İletişim tek yönlü

Cevapları aldıktan sonra tedarikçinin yeni bir alt-işleyen eklediğini, veri merkezi konumunu değiştirdiğini veya zorunlu bir kontrolü düşürdüğünü öğrenmenin sistematik bir yolu yoktur.

2. SIG-Lite zemindir, tavan değildir

SIG-Lite, HECVAT ve CAIQ gibi standart anketler değerli — kurum-içi bir şablonu sıfırdan yazmak yerine sektör-onaylı sorularla başlayabilirsiniz. Ama bu anketler doğaları gereği bir ana hat çizer; sizin spesifik bağlamınızı yakalamaz.

Üst-segment bir kurumda olgun TPRM şöyle katmanlanır:

  • Zemin (standart anket): SIG-Lite + KVKK md.9 ve GDPR md.28 sorularını barındıran kurum-spesifik ek
  • Kanıt (asset attestation): son SOC 2 raporu, pen-test sonucu, ISO sertifikası, alt-işleyen listesi
  • İzleme (continuous signal): ihlal bildirim akışları, sertifika yenileme alarmları, alt-işleyen değişiklik bildirimleri
  • Tetik (event-driven re-assessment): kritik bir tedarikçi kamuoyu bilinen bir ihlalde anılırsa anket otomatik yeniden gönderilir

Bu katmanlar olmadan anket, arşiv için doldurulan bir form olmaktan öteye geçmez.

Tedarikçi yaşam döngüsünün beş aşaması bir kere yapılmaz — her halka 'sürekli izleme' merkezine bağlı kalır. Yıllık-tek-sefer anket modelinin yerini değiştirmenin görsel ifadesi.

3. Kritiklik ≠ Risk — ve bu ayrımı kuramayan kurumlar yanlış önceliklendiriyor

Klasik bir hatadır: "Bu tedarikçi bizim için kritik, demek ki yüksek riskli." Oysa iki eksen tamamen ayrıdır:

  • Kritiklik: bu tedarikçi çıktığında işiniz durur mu? (Bordro sağlayıcısı, ERP, ana CRM)
  • Risk: bu tedarikçi sizin verinizle ve operasyonunuzla ne kadar olgun davranıyor? (Sertifikalar, kontroller, ihlal geçmişi, alt-işleyen disiplini)

Kritik bir tedarikçi — örneğin büyük bir bulut sağlayıcı — düşük riskli olabilir; az kritik ama disiplinsiz bir niş SaaS yüksek riskli olabilir. CenseCloud, bu iki ekseni ayrı ekseni olarak modellemenizi öneriyor; çünkü tek-eksenli sıralama, küçük ama tehlikeli tedarikçiyi gözden kaçırıyor.

Pratik kuadran
  • Yüksek kritiklik + düşük risk: sürdür, izle (bordro, ERP gibi olgun büyük tedarikçiler)
  • Yüksek kritiklik + yüksek risk: acil aksiyon (yedek planı, sözleşme revizyonu, sıkı izleme)
  • Düşük kritiklik + yüksek risk: azalt veya bırak (niş araçlarda sık karşılaşılır)
  • Düşük kritiklik + düşük risk: rutin, periyodik kontrol
Tek-eksenli sıralama tehlikeli olanı sağ-üst köşeye değil, sol-üst köşeye gizleyebilir. Kritiklik düşük, risk yüksek — küçük bir niş SaaS bu kuadrandadır ve gözden kaçar.

4. Döngüsel TPRM: dört adım

Bayatlamayan bir TPRM süreci dört adımdan oluşur — ve bu adımlar yıllık değil, sonsuz bir döngü olarak çalışır.

Adım 1 — Değerlendirme

  • Standart anket (SIG-Lite + kurum-içi ek) tedarikçiye gönderilir
  • Mevcutsa SOC 2 / ISO / pen-test kanıtları toplanır
  • KVKK md.9 / GDPR md.28 / ISO 27036 referansları her kontrole bağlanır

Adım 2 — Kanıt

  • Cevaplar iddia olarak işaretlenir; kanıt eklenmeden skora dönüşmez
  • Her kanıtın geçerlilik tarihi tutulur (SOC 2 ≈ 12 ay, ISO 27001 ≈ 3 yıl)
  • Geçerlilik dolduğunda kanıt otomatik çürür ve yeniden istenir

Adım 3 — Sürekli izleme

  • Tedarikçinin yeni alt-işleyenleri için bildirim akışı
  • Kamuoyuna açılan ihlal bildirimi akışları
  • Sertifika yenileme ve süre dolumu alarmları
  • Tedarikçi domain'lerinde anomali sinyalleri

Adım 4 — Bildirim ve aksiyon

  • Eskiyen kanıt, gelen ihlal sinyali veya kontrol değişikliği bir vaka açar
  • Vaka doğru sahibe atanır — genellikle satınalma + güvenlik birlikte
  • Aksiyon iz bırakır (denetçi için)

5. Tedarikçinin ihlali sizin güvenlik vakanız

KVKK md.9 ve GDPR md.28 her ikisi de aynı şeyi söyler: bir tedarikçide yaşanan kişisel veri ihlali, sizin kontrolünüz altındadır. Veri sorumlusu sıfatınız değişmez. Düzenleyici idari yaptırımı sizin üzerinizden işletir; denetçi tedarikçinin hatasını sizin önünüze koyar.

Bu pattern, son yıllarda "tedarikçi-zinciri ihlali" diye geçen olaylarda defalarca görüldü. Bir veri ihlali kamuoyuna yansıdığında kamu önce esas markayı arar — alt-işleyenin adını dahi bilmeyebilir.

Bu nedenle TPRM, "satınalmadan önce şu evrakı doldur" iş akışından çıkıp sürekli operasyonel bir disiplin haline gelmek zorundadır.

6. CenseCloud'da TPRM nasıl çalışır

CenseCloud TPRM'i ayrı bir modül olarak değil, CenseRisk'in doğal bir parçası olarak modeller — çünkü tedarikçi riski, SaaS risk yönetiminin alt kümesidir.

Pratikte sunduğumuz şey:

  • Tedarikçi envanteri: SaaS keşfi otomatik olarak besler; elle ekleme de mümkün
  • İki-eksenli sıralama: kritiklik vs risk ayrı ayrı modellenir
  • Magic-link dış değerlendirme portalı: tedarikçinin cevap vermesi için kurum hesabı gerekmez
  • Otomatik anket gönderimi: auto_send opt-in; varsayılan değildir
  • SIG-Lite + KVKK anketi şablonu: firma-özel düzenleme mümkün, versiyon-kilidi ile gönderildiği an dondurulur
  • Kanıt yaşam döngüsü ve çürüme alarmı: geçerlilik tarihi gelen kanıt otomatik işaretlenir
  • Çoklu-partner ilişki modeli (N:N): bir tedarikçinin müşterisi ve aynı zamanda başka bir kurumun tedarikçisi olabilirsiniz; iki rolü tek envanterden yönetirsiniz

Kapanış: anket bitmez, devam eder

Tedarikçi risk yönetiminin başarısı, ne kadar kalın bir klasör doldurduğunuz değildir. Başarı, denetçi geldiğinde her tedarikçi için sorulan "şu an risk durumu ne, hangi kanıta dayanıyor, en son ne zaman güncellendi" sorusuna saniyelerde cevap verebilmektir.

Klasik model bu cevabı veremez çünkü cevap zaten kâğıt üstünde donmuştur. Döngüsel TPRM cevabı sürekli güncel tutar.

Daha fazla detay için TPRM çözüm sayfasına veya CenseRisk modülüne göz atabilirsiniz.

Kendi yığınınızda nasıl çalıştığını görün

30 dakikalık canlı demo — kendi envanteriniz, kendi harcamanız, kendi ekibinizle. Sunum yok.