WordPress siteleri için BT risk değerlendirmesi: basit yöntem

Bir WordPress sitesi için BT risk değerlendirmesi tek sayfaya sığar. Neye sahip olduğunuzu, gerçekçi olarak neyin ters gidebileceğini, bunun ne kadar ağır olacağını ve kimin neyi hangi tarihe kadar düzelteceğini listeler. Aşağıdaki beş adımlı yöntemle bugün öğleden sonra bir taslak çıkarabilirsiniz. Elinize geçen belge, bir müşteri anketi, bir sigortacı ya da bir denetim makamı güvenlik önlemlerinizi nasıl seçtiğinizi sorduğunda gösterebileceğiniz somut bir dayanaktır.

GDPR ve NIS2 kapsamında BT risk değerlendirmesi neden önce gelir

GDPR (AB Genel Veri Koruma Tüzüğü) madde 32(1), teknolojinin güncel durumu ve maliyetler dikkate alınarak riske uygun teknik ve organizasyonel tedbirler alınmasını ister. Riskin ne olduğunu söylemeden bir tedbirin uygun olduğunu gösteremezsiniz. Madde 5(2) ayrıca uyumu kanıtlayabilmenizi şart koşar; dolayısıyla değerlendirmenin yazılı olması gerekir. Tedbirlerin kendisini WordPress için GDPR madde 32 yazımızda ele alıyoruz.

Şirketiniz NIS2 Direktifi kapsamındaysa, madde 21(2)'deki asgari tedbirler listesi (a) bendiyle başlar: risk analizi ve bilgi sistemleri güvenliği politikaları. Bağlayıcı yükümlülükler ulusal hukuktan doğar; bu nedenle ülkenizin NIS2 uyum yasasına bakın. Önce NIS2'nin sizi kapsayıp kapsamadığını kontrol edebilirsiniz.

Bu yöntem pragmatik bir başlangıç noktasıdır. Bir ISO 27001 uygulaması da değildir, resmî bir bağımsız denetim de.

Adım 1: Varlıklarınızı listeleyin (siteler, veriler, hesaplar, tedarikçiler)

Varlık, kaybedilmesi veya kötüye kullanılması size zarar verecek her şeydir. Tipik bir küçük işletmede dört grup hemen her şeyi kapsar. Kişisel verileri başa koyun; çünkü GDPR'ın devreye girdiği ve etkinin en yüksek olduğu yer burasıdır.

Somut olun. "Web sitesi" fazla belirsiz. "shop.example.com, yaklaşık 40 eklentili WooCommerce, 2021'den beri siparişler" ise işe yarar. Listeyi yazarken unutulmuş bir staging kopyası ya da eski bir freelancer'ın yönetici hesabı çıkarsa not alın. Egzersizi haklı çıkarmaya tek başına bu keşif yeter.

Adım 2: Her varlık için gerçekçi tehditleri belirleyin

Olası her saldırının kataloğuna ihtiyacınız yok. WordPress sitelerinde gerçek olayların çoğunu dört tehdit grubu kapsar:

• Açığı olan veya terk edilmiş eklentiler ve temalar. Biri siz güncellemeden önce bilinen bir açığı istismar eder ya da hiç düzeltilmeyen bir açık vardır.
• Çalınan veya paylaşılan girişler. Tekrar kullanılan bir parola, paylaşılan bir "admin" hesabı ya da kimsenin kaldırmadığı bir ajans girişi.
• Hosting veya sunucu arızası. Kesinti, hostta veri kaybı ya da sunucu yazılımının kendisindeki bir açık. PHP2Shell açıkları buna örnektir: açıklar PHP çalışma zamanındaydı, bu yüzden tamamen güncel bir WordPress bile risk altındaydı.
• İnsan hatası. Ödeme sayfasını bozan bir güncelleme, silinmiş bir sayfa ya da "sadece bir dakikalığına" Yönetici rolü verilmiş bir editör.

Eklenti tehdidi dürüst bir puanı hak ediyor. Satıcı Patchstack, State of WordPress Security in 2026 raporunda 2025'te WordPress ekosisteminde 11.334 yeni güvenlik açığı saydı. Bunların %91'i eklentilerdeydi ve %46'sı kamuya açıklandığı sırada geliştiriciden gelen bir düzeltmeye sahip değildi. Yoğun biçimde istismar edilen açıklarda, kitlesel istismara kadar geçen ağırlıklı medyan süre 5 saatti. Bunlar bir satıcının rakamları, ama "eklenti açığı"nın bir WordPress kaydında neden genellikle en üstte yer aldığını açıklıyorlar.

Adım 3: Olasılık ve etkiyi 1–3 ölçeğinde puanlayın

Üç düzey kullanın ve bunları açık sözcüklerle tanımlayın; böylece aynı riski puanlayan iki kişi aynı sonuca varır.

Olasılık

1. Bir yıl içinde olası değil
2. Bir yıl içinde mümkün
3. Beklenen ya da size veya benzer bir siteye zaten oldu

Etki

1. Can sıkıcı: düzeltmek bir saat sürer, hiçbir veri etkilenmez
2. Kesinti veya sınırlı miktarda hassas olmayan verinin etkilenmesi
3. Kişisel verilerin ifşası, ödemelerin etkilenmesi ya da işin durması

İki değeri çarpın. 1–2 puan kabul, 3–4 puan önlem planlama, 6–9 puan hemen harekete geçme anlamına gelir. 5, 7 ve 8 puanı bu ölçekte oluşamaz; bu da bantları net tutar.

Riski bugünkü haliyle puanlayın. Var olan ve işleyen bir kontrol olasılığı düşürür. "Yedeğimiz var" ifadesi ancak biri bir yedeği geri yüklemişse sayılır. Ondalık ya da ağırlık katsayısı eklemeyin. 1–3 ölçeği bilerek kabadır; sahte hassasiyet, kaydı arkasındaki bilgiden daha bilimsel gösterir.

Adım 4: Önlemleri, sorumluları ve gözden geçirme tarihlerini belirleyin

3 ve üzeri puan alan her risk için bir ya da iki somut önlem seçin. "Güvenliği iyileştir" bir önlem değildir. "Dört yöneticinin tamamı için iki faktörlü girişi 17 Kasım'a kadar etkinleştir" ise öyledir. Sorumlu olarak "BT" ya da "ajans" değil, bir kişi yazın ve bir tarih koyun.

Önlemlerin kendisini derinlemesine ele alan yazılarımız var: açığı olan eklentilerle başa çıkma ve gerçekten geri yüklenen WordPress yedekleri. Risk kaydınızın yalnızca kararı not etmesi ve kanıta bağlantı vermesi yeterli.

Her satıra iki şey daha girmeli. Birincisi, düşük puanlar için "kabul" geçerli bir karardır; yeter ki gerekçesini yazın. İkincisi, kalan riski, yani önlem uygulandıktan sonra beklediğiniz puanı not edin. Bir önlem puanı düşürmüyorsa büyük olasılıkla yanlış önlemdir.

Örnek: küçük bir WooCommerce mağazası için risk kaydı

Aşağıdaki örnek kurgusal bir mağazaya ait. Mağazanın tek bir WooCommerce sitesi, bir staging kopyası, iki çalışanı, harici bir ajansı ve paylaşımlı hostingi var. "O" olasılık, "E" etki, "Sonra" ise beklenen kalan puandır.

Yukarıdan aşağı okuyun. Mağaza bu hafta ajans hesabını kaldırıyor ve hosttan PHP hakkında bilgi istiyor. İkisi de ucuz ve bir saatten kısa sürüyor. En yüksek puana sahip olduğu için eklenti temizliği gelecek haftaya kadar tamamlanıyor. 2FA ve geri yükleme testi ay içine planlanıyor.

Personel hatası ve iletişim formu satırları Aralık'a kalabilir. Puanları daha düşük; personel hataları için de dördüncü satırdaki yedek çalışması zaten bir geri dönüş yolu sağlıyor. Bülten kesintisi ise gerekçesi ve gözden geçirme tarihiyle kabul ediliyor. Her satır 3 veya altında bitiyor. Bu, hiçbir şeyin olamayacağı anlamına gelmez; belgelenmiş ve gerekçelendirilmiş bir risk düzeyidir.

Risk değerlendirmesini güncel tutmak

Hiç yeniden açılmayan bir BT risk değerlendirmesi, bakmayı bıraktığınızın kanıtına dönüşür. Şu tetikleyicilerden biri gerçekleştiğinde gözden geçirin:

• Her olaydan veya ucuz atlatılan durumdan sonra; başarısız giriş dalgası ya da geri almak zorunda kaldığınız bir eklenti dahil
• Kişisel veri işleyen yeni bir eklenti, yeni bir host, yeni bir ajans veya mağaza açılışı gibi büyük değişikliklerden sonra
• Bir tedarikçi ya da NIS2 kapsamındaki bir müşteri güvenlik anketi gönderdiğinde
• Kendi seçtiğiniz sabit bir aralıkta; örneğin üç ayda bir veya yılda bir. Bu sizin kararınızdır, yasal bir kural değil

Belgeye sürüm numarası ve tarih verin, eski sürümleri saklayın. 9 puanın bir önlemden sonra 3'e düştüğünü gösteren bir geçmiş, hesap verebilirlik açısından iyi bir kanıttır. Güvenlik denetimi dokümantasyonu rehberimiz, kaydın diğer belgelerinizle nasıl bütünleştiğini gösteriyor.

secaudit.eu'nun "Security Audit & Compliance" denetim eklentisi 2. adımda ve her gözden geçirmede yardımcı olabilir. Bulgularını GDPR md. 32 ve NIS2 md. 21 ile eşleştirir, rapor veya CSV olarak dışa aktarır; böylece bunları kaydınızla karşılaştırabilirsiniz. Kayıttaki kararlar sizin kalır; eklenti onlara güncel girdi sağlar. → secaudit.eu

Sıradaki adımınız: örnek tabloyu kopyalayın, satırları kendi varlıklarınızla değiştirin ve dosyayı kapatmadan ilk gözden geçirme tarihini takviminize koyun.

SSS

Bunun için ISO 27001'e ihtiyacım var mı?

Hayır. Bu yöntem, kendi ekibinizle yürütebileceğiniz pratik bir başlangıçtır. ISO 27001 tam bir yönetim sistemi standardıdır; onu sonradan benimseyip benimsemeyeceğiniz, çoğunlukla büyük müşterilerin yönlendirdiği ayrı bir iş kararıdır.

Tek bir site için ne kadar sürer?

Kurulumu bilinen tek bir site için ilk taslak bir çalışma oturumuna sığar. Zamanın çoğu hesapları ve tedarikçileri bulduğunuz 1. adıma gider. Sonraki gözden geçirmeler çok daha hızlıdır; çünkü yalnızca değişenleri güncellersiniz.

Ajans bunu bir kez mi yapar, yoksa her müşteri için mi?

Her müşteri kendi sitesinin veri sorumlusudur ve kendi risk değerlendirmesine sahiptir. Ajans, müşterinin onaylaması için bir taslak hazırlayabilir. Ayrıca kendi sistemleri için, yani dizüstü bilgisayarları, parola kasası ve müşteri hostingine erişimi için ayrı bir kayıt tutmalıdır. Veri işleme sözleşmeniz kimin ne yaptığını tanımlamalıdır.

Bu makale genel bilgi niteliğindedir, hukuki danışmanlık değildir.