GDPR Madde 32 ve WordPress: “uygun güvenlik” ne demek?

GDPR (AB Genel Veri Koruma Tüzüğü) Madde 32'de ne bir eklenti adı geçer, ne bir sunucu ayarı ne de bir parola uzunluğu. Madde, riske uygun bir güvenlik düzeyi ister. Çoğu WordPress sitesi için bu, kısa ve somut bir listeye dönüşür: her yerde HTTPS, güncel yazılım, iki faktörlü kimlik doğrulamayla korunan kişisel hesaplar, gerçekten geri yüklemeyi denediğiniz yedekler ve düzenli kontroller. Bunları yapıyor ve belgeleyebiliyorsanız, Madde 32'nin tipik bir WordPress sitesinden beklediklerinin büyük kısmını zaten karşılıyorsunuz demektir.

Bu rehber, Madde 32(1)'in (a)–(d) bentlerini tek tek WordPress önlemlerine çeviriyor. Ayrıca bu maddeyi çevreleyen iki yükümlülüğü de ele alıyor: aldığınız önlemleri belgelemek (hesap verebilirlik) ve barındırma firmanızla ajansınızın da üzerine düşeni yapmasını sağlamak.

GDPR ve WordPress güvenliği: Madde 32 ne diyor?

GDPR Madde 32, hem veri sorumlusunu (yani işletmenizi) hem de her veri işleyeni (örneğin barındırma firmanızı) uygun teknik ve organizasyonel tedbirleri almakla yükümlü kılar. Neyin uygun sayılacağı; teknolojinin son durumuna, uygulama maliyetlerine, işlemenin niteliğine, kapsamına, bağlamına ve amaçlarına, ayrıca verilerini işlediğiniz kişiler açısından ortaya çıkan riske bağlıdır. Tüzük yalnızca AB'de yerleşik şirketleri ilgilendirmez: AB'deki kişilere mal veya hizmet sunan ya da onların davranışlarını izleyen AB dışındaki şirketlere de uygulanabilir (GDPR Md. 3(2)).

Madde, ardından bu tedbirlerin "diğerlerinin yanı sıra, duruma göre" kapsadığı dört unsuru sayar:

• (a) kişisel verilerin takma adlandırılması ve şifrelenmesi;
• (b) sistem ve hizmetlerin süregelen gizliliğini, bütünlüğünü, erişilebilirliğini ve dayanıklılığını sağlama yeteneği;
• (c) bir olayın ardından kişisel verilerin erişilebilirliğini ve bunlara erişimi zamanında geri sağlama yeteneği;
• (d) tedbirlerin işe yarayıp yaramadığını düzenli olarak test etmeye, ölçmeye ve değerlendirmeye yönelik bir süreç.

Bunun arkasında Madde 5(1)(f) yer alır: kişisel veriler uygun bir güvenlik düzeyiyle işlenmelidir. Tipik bir WordPress sitesi de sahibinin sandığından çok daha fazla kişisel veri işler: kullanıcı hesapları, isim, e-posta ve IP adresi içeren yorumlar, iletişim formu kayıtları, bülten abonelikleri, WooCommerce siparişleri ve sunucu kayıtları.

Risk temelli yaklaşım: teknolojinin son durumu ve maliyet

Madde 32 bilinçli olarak risk temelli kurgulanmıştır. Tek bir iletişim formu olan bir kurumsal site, binlerce müşteri hesabı barındıran bir mağaza ve sağlık bilgisi saklayan bir üye alanı aynı çabayı gerektirmez; ama her biri, olası zararla orantılı bir koruma düzeyine ihtiyaç duyar. Madde 32(2), tartılması gereken riskleri sayar: kişisel verilerin kazara veya hukuka aykırı olarak yok edilmesi, kaybı, değiştirilmesi, yetkisiz olarak ifşa edilmesi ya da bunlara yetkisiz erişilmesi.

"Teknolojinin son durumu" ifadesini "piyasadaki en pahalı ürün" olarak değil, "yerleşik ve yaygın olarak erişilebilir" olarak okumak en doğrusudur. HTTPS, desteklenen yazılım sürümleri ve yöneticiler için iki faktörlü giriş bugün teknolojinin son durumunu temsil eder ve maliyetleri düşüktür. Maliyet gerekçesi, küçük bir blogu kurumsal düzeyde bir web uygulaması güvenlik duvarı (WAF) olmadan işletmeyi haklı çıkarabilir. Temel önlemleri atlamayı ise nadiren haklı çıkarır.

Madde 32(1)(a)–(d) için WordPress önlemleri

Aşağıdaki tablo her bendi tipik WordPress önlemleriyle ve saklamaya değer kanıtlarla eşleştiriyor.

(a) Şifreleme ve takma adlandırma

Sitenin tamamını, /wp-admin/ ve tüm formlar dahil, yalnızca HTTPS üzerinden sunun; bu düzen sorunsuz çalışmaya başlayınca HSTS'yi ekleyin. Parolalar şifrelenmez, özetlenir (hash); parolalar için doğru yaklaşım da budur. WordPress 6.8 sürümünden bu yana kullanıcı parolaları bcrypt ile özetleniyor.

Yedekler, kişisel verilerinizin en çok gözden kaçan kopyasıdır. Onları şifreleyin ve web sunucusundan uzakta saklayın. Gerçek anlamda takma adlandırma tipik bir WordPress sitesinde nadiren görülür, ama ona yakın adımlar riski azaltır: analiz araçlarında ve kayıtlarda IP adreslerini kısaltın, iletişim formu kayıtlarını veritabanında gerektiğinden uzun süre tutmayın. Artık saklamadığınız veri sızamaz.

(b) Gizlilik, bütünlük, erişilebilirlik ve dayanıklılık

İlk sırada güncellemeler gelir. Bir güvenlik şirketi olan Patchstack, 2025 yılında WordPress ekosisteminde 11.334 yeni güvenlik açığı saydı; bunların %91'i eklentilerdeydi. Yoğun biçimde istismar edilen açıklarda kitlesel istismara kadar geçen ağırlıklı medyan süre yalnızca beş saatti (Patchstack raporu). Uygun olduğu yerlerde otomatik güncellemeleri açın (WordPress çekirdeği eklenti ve temalar için bu seçeneği 5.5 sürümünden beri sunuyor) ve kullanmadığınız eklentileri silin. Açık barındıran eklentiler rehberimiz, eklentilerinizi nasıl denetleyeceğinizi anlatıyor.

İkinci temel direk erişim kontrolüdür: her kişiye kendi hesabı, işini görecek en düşük rol (Administrator yerine Editor, Author veya Contributor) ve her yönetici için iki faktörlü kimlik doğrulama. WordPress çekirdeği bu özelliği içermez. Bütünlüğü korumak için yönetim panelindeki dosya düzenleyicileri wp-config.php içinde kapatın:

define( 'DISALLOW_FILE_EDIT', true );

Çekirdek dosyalarını zaman zaman resmî sağlama toplamlarıyla karşılaştırın (WP-CLI ile wp core verify-checksums). Erişilebilirlik ve dayanıklılık için yeterli kaynak ve izleme sunan bir barındırma hizmeti seçin. Hiçbir eklenti büyük bir DDoS saldırısını karşılayamaz; bu, bir CDN'in ya da uç (edge) güvenlik duvarının işidir. Resmî WordPress sıkılaştırma rehberi sunucu tarafında yapılabilecek başka ayarları da listeler.

(c) Bir olaydan sonra erişilebilirliği geri sağlamak

Bir yedek ancak geri yükleyebiliyorsanız işe yarar. Dosyaları ve veritabanını yedekleyin, en az bir kopyayı sunucu dışında ve WordPress yönetici hesabının erişemeyeceği bir yerde tutun ve tam bir geri yüklemeyi bir test (staging) sitesinde deneyin. Ne kadar sürdüğünü not edin: "zamanında" geri yükleyebildiğinizi ölçülmüş bir süreyle savunmak, bir umutla savunmaktan çok daha kolaydır.

(d) Düzenli test, ölçme ve değerlendirme

GDPR bir sıklık belirlemez; bu yüzden kendi takviminizi belirleyin ve ona uyun. Küçük bir işletme için makul bir başlangıç noktası şöyle olabilir: her hafta otomatik bir tarama, her çeyrekte kullanıcı hesaplarının ve eklentilerin gözden geçirilmesi, yılda iki kez geri yükleme testi ve her olaydan ya da büyük değişiklikten sonra ek bir inceleme. Neyi bulup düzelttiğinizi tarihleriyle birlikte kaydedin.

secaudit.eu tarafından geliştirilen Security Audit & Compliance eklentisi, test kısmının bir bölümünü üstlenebilir: zararlı yazılımları, değiştirilmiş çekirdek dosyalarını, güncel olmayan eklentileri ve zayıf parolaları kontrol eder, bulgularını GDPR Md. 32 ile eşleştirir ve ekranda bir uyumluluk özeti gösterir; imzalı rapor belgeleri (PDF, CSV) secaudit.eu Pro ile gelir. Bir tarama dokümantasyonunuzu destekler; tek başına bir siteyi uyumlu hâle getirmez.

Hesap verebilirlik: yaptıklarınızı belgeleyin (Md. 5(2))

Madde 5(2) uyarınca veri sorumlusu, uyumu kanıtlayabilmelidir. Uygulamada bu, kimsenin açıp okumadığı kalın bir klasör değil, kısa ve sürekli güncellenen bir güvenlik belgesi demektir. Bu belge şunları kapsamalıdır:

• Bir envanter: barındırma, WordPress sürümü, eklentiler, temalar, harici hizmetler
• Kimin hangi rolle erişimi olduğu ve yeni hesapları kimin onayladığı
• (a)–(d) bentleri için önlemleriniz ve bunların dayandığı risk notu
• Bir güncelleme kaydı ile tarama, erişim incelemesi ve geri yükleme testlerinin tarihleri
• 72 saatlik ihlal bildirimi dahil olay müdahale prosedürünüz
• Veri işleyenlerinizle yaptığınız veri işleme sözleşmeleri

Belgeyi yılda bir kez ve site önemli ölçüde değiştiğinde gözden geçirin. Envanter için WordPress güvenlik kontrol listemiz iyi bir başlangıç noktasıdır.

Barındırma firmaları ve ajanslar: Md. 28 kapsamında veri işleyenler

Barındırma firmanız veritabanını ve yedekleri saklar. Yönetici erişimi olan bir ajans ya da serbest çalışan, her müşteri kaydını okuyabilir. Her ikisi de genellikle veri işleyen konumundadır ve bu durumda Madde 28 uyarınca her biriyle ayrı bir veri işleme sözleşmesi yapmanız gerekir. Aynı madde, yalnızca uygun teknik ve organizasyonel tedbirler konusunda yeterli güvence sunan veri işleyenlerle çalışabileceğinizi söyler; sözleşme de onları Madde 32'nin gerektirdiği tedbirleri almakla yükümlü kılmalıdır.

Hazır bir şablona güvenmek yerine somut sorular sorun. Yedekler nerede ve ne kadar süreyle saklanıyor? Barındırma panelinde ve ajansın hesaplarında iki faktörlü giriş zorunlu mu? Bir güvenlik olayını size ne kadar sürede bildirecekler? Bir ajansla sözleşme sona erdiğinde, ajansın hesaplarını aynı gün kaldırın ve ortak kullanılan erişim bilgilerini değiştirin.

Madde 32 dahil 25 ila 39. maddelerin ihlali, 10 milyon avroya ya da dünya genelindeki yıllık cironun %2'sine kadar (hangisi daha yüksekse) para cezasıyla sonuçlanabilir (Md. 83(4)(a)). Yine de dokümantasyonunuza ihtiyaç duyacağınız asıl an büyük olasılıkla bir olayın ardından, bir makam elinizde hangi önlemlerin bulunduğunu sorduğunda gelir.

Sık sorulan sorular

Madde 32 belirli bir güvenlik eklentisi kullanmayı şart koşuyor mu?

Hayır. Madde ürünleri değil, uygun tedbirleri şart koşar. Bir eklenti, iki faktörlü giriş ya da tarama gibi bazı tedbirlerde yardımcı olabilir; ama güncellemeler, yedekler, erişim incelemeleri ve sözleşmeler de en az onlar kadar bu işin parçasıdır.

Madde 32, kullanıcı hesabı olmayan küçük bir site için de geçerli mi?

Evet; site, örneğin iletişim formu kayıtları, yorumlar ya da IP adresleri içeren sunucu kayıtları gibi kişisel verileri işlediği anda geçerlidir. Tedbirler riskle birlikte ölçeklenir.

(a) bendi için HTTPS yeterli mi?

Hayır. HTTPS, verileri yalnızca aktarım sırasında korur. Yedekler, dışa aktarılan dosyalar ve sunucudaki veritabanı için ayrıca koruma gerekir.

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