Web Sitesi Güvenliği ve KVKK: Site Sahipleri İçin Rehber

Okuma süresi: 19 dk

Küçük bir kurumsal site, bir blog veya bir e-ticaret mağazası fark etmeksizin, internete açık her web sitesi otomatik taramaların hedefidir. Saldırganların çoğu sizi özel olarak seçmez; bilinen açıkları olan eski eklentileri, zayıf parolaları ve yanlış yapılandırılmış sunucuları tarayan botlar kullanır. Bir ihlalin bedeli ise yalnızca teknik değildir: Müşteri verileri sızarsa KVKK kapsamında bildirim yükümlülüğü, idari para cezası riski ve itibar kaybı gündeme gelir. Bu rehberde web sitesi güvenliğini katman katman ele alıyor, ardından site sahiplerini doğrudan ilgilendiren KVKK yükümlülüklerini pratik bir dille açıklıyoruz.

Web siteleri neden ve nasıl saldırıya uğrar?

Saldırıların büyük bölümü birkaç tekrarlayan yöntemle gerçekleşir:

• Güncellenmemiş yazılımlar: İçerik yönetim sistemi, tema veya eklentilerde yayımlanmış ama yamanmamış açıklar, otomatik saldırıların en yaygın giriş noktasıdır.
• Zayıf veya sızdırılmış parolalar: Kaba kuvvet (brute force) ve başka sitelerden sızdırılmış parola listeleriyle yapılan denemeler (credential stuffing).
• Enjeksiyon saldırıları: SQL enjeksiyonu ve siteler arası betik çalıştırma (XSS) gibi, kullanıcı girdisinin doğru doğrulanmadığı durumlarda ortaya çıkan açıklar.
• Erişim kontrolü hataları: Yetkisiz kullanıcıların görmemesi gereken sayfalara veya verilere erişebilmesi. OWASP Top 10 listesinde “Broken Access Control” en üst sıralarda yer alır.
• Yanlış yapılandırma: Açık bırakılmış dizin listeleri, herkese açık yedek dosyaları, varsayılan yönetici hesapları ve gereğinden geniş dosya izinleri.
• Oltalama (phishing) ve sosyal mühendislik: Yönetici veya çalışanların kandırılarak kimlik bilgilerini vermesi.
• DDoS saldırıları: Sunucuyu yoğun trafikle hizmet veremez hâle getirme girişimleri.

Web uygulaması güvenlik risklerinin kapsamlı bir sınıflandırması için OWASP’ın (Open Worldwide Application Security Project) Top 10 listesi iyi bir başlangıç noktasıdır.

Temel güvenlik katmanları

Güvenlik tek bir ürün değil, birbirini tamamlayan katmanlardır. Bir katman aşılırsa diğeri devreye girer.

Güncellemeler ve yazılım envanteri

Sitenizde hangi yazılımların çalıştığını bilmeden onları güncel tutamazsınız. Bir envanter çıkarın: içerik yönetim sistemi ve sürümü, tema, eklentiler, PHP sürümü, sunucu bileşenleri. Ardından:

• Güvenlik güncellemelerini mümkün olduğunca hızlı uygulayın; büyük sürüm güncellemelerini önce hazırlık (staging) ortamında test edin.
• Kullanmadığınız eklenti ve temaları devre dışı bırakmakla kalmayın, silin (bu aynı zamanda siteyi hızlandırır; bkz. WordPress hızlandırma rehberi).
• Geliştiricisi tarafından bırakılmış (uzun süredir güncellenmeyen) eklentileri alternatifleriyle değiştirin.
• PHP sürümünüzün güvenlik desteği aldığından emin olun. Hangi sürümün ne zamana kadar güvenlik güncellemesi alacağını php.net’teki desteklenen sürümler sayfasından kontrol edin.

Kimlik doğrulama ve erişim yönetimi

• Tüm yönetici hesaplarında iki adımlı doğrulama (2FA) kullanın: web sitesi yönetim paneli, hosting kontrol paneli, alan adı kayıt hesabı ve e-posta.
• Her kullanıcıya yalnızca işini yapmaya yetecek yetkiyi verin (en az yetki ilkesi); paylaşılan hesaplar yerine kişisel hesaplar kullanın.
• Parola yöneticisi ile benzersiz ve uzun parolalar oluşturun.
• Ayrılan çalışanların ve iş birliği biten ajansların erişimlerini derhal kapatın.
• Giriş sayfasına deneme sınırı (rate limiting) uygulayın.
• Sunucu erişimi için FTP yerine SFTP ve SSH anahtarları kullanın.

Web uygulaması güvenlik duvarı (WAF) ve kötü amaçlı yazılım taraması

WAF, bilinen saldırı kalıplarını (SQL enjeksiyonu, XSS, bilinen eklenti açıklarını hedefleyen istekler) sitenize ulaşmadan engeller. Sunucu düzeyinde (ör. ModSecurity kuralları), hosting sağlayıcısının güvenlik yazılımıyla veya bir CDN/WAF hizmetiyle uygulanabilir. Düzenli kötü amaçlı yazılım taraması ise sızma gerçekleştiyse bunu erken fark etmenizi sağlar. Hosting paketinizde hangi korumaların bulunduğunu sağlayıcınıza sorun.

Yedekleme: 3-2-1 kuralı

Yedek, diğer tüm önlemler başarısız olduğunda son savunma hattıdır. Yaygın kabul gören 3-2-1 kuralı şudur:

• Verinin en az 3 kopyası olsun (canlı veri + 2 yedek),
• Bu kopyalar en az 2 farklı ortamda saklansın,
• Kopyalardan en az 1’i farklı bir konumda (sunucu dışında) bulunsun.

Bunlara ek olarak:

• Fidye yazılımlarına karşı, değiştirilemeyen (immutable) veya çevrim dışı bir yedek kopyası düşünün.
• Yedeklerin geri yüklenebildiğini düzenli olarak test edin; test edilmemiş yedek, yedek değildir.
• Yedeklerin kişisel veri içerdiğini unutmayın; yedekler de şifrelenmeli, erişimi sınırlanmalı ve saklama süreleri kişisel veri saklama ve imha politikanızla uyumlu olmalıdır.

HTTPS, SSL/TLS ve sertifika ömürleri

HTTPS, ziyaretçi ile sunucu arasındaki trafiği şifreler; form verileri, parolalar ve oturum çerezleri bu sayede korunur. Bugün HTTPS fiilen standarttır: Tarayıcılar HTTP sayfalarını “Güvenli değil” olarak işaretler. Kişisel veri toplayan bir formu şifresiz sunmak, verilerin aktarım sırasında okunabilmesine yol açar ve veri güvenliği yükümlülüğü açısından ciddi bir risk oluşturur.

Dikkat edilmesi gereken önemli bir gelişme: CA/Browser Forum’un SC-081 kararıyla kamuya açık TLS sertifikalarının azami geçerlilik süresi kademeli olarak kısalıyor:

Bu, sertifika yenilemenin artık elle yapılabilecek bir iş olmaktan çıktığı anlamına gelir. Otomatik yenileme (ACME) desteği olan bir altyapı kullanın ve yenilemelerin başarısız olması durumunda uyarı alacağınız bir izleme kurun. Sertifika türleri ve otomatik yenileme seçenekleri için SSL sertifikası sayfamıza bakabilirsiniz.

Ayrıca:

• HTTP’den HTTPS’e kalıcı (301) yönlendirme yapın.
• TLS 1.2 ve 1.3 dışındaki eski protokolleri kapatın.
• DNS’te CAA kaydı ile yalnızca kullandığınız sertifika otoritelerinin sertifika düzenleyebilmesini sağlayın.

Güvenlik başlıkları

HTTP yanıt başlıkları, tarayıcıya sitenizi nasıl koruması gerektiğini söyler:

CSP’yi doğrudan uygulamak yerine önce “Content-Security-Policy-Report-Only” modunda test etmek, sitenin bozulmasını önler.

E-posta güvenliği: SPF, DKIM ve DMARC

Alan adınız adına sahte e-posta gönderilmesi (spoofing), müşterilerinize yönelik oltalama saldırılarında sık kullanılır. Üç DNS kaydı bunu önlemeye yardımcı olur:

• SPF: Alan adınız adına hangi sunucuların e-posta gönderebileceğini belirtir.
• DKIM: Gönderilen e-postaları kriptografik olarak imzalar.
• DMARC: SPF/DKIM doğrulamasından geçemeyen e-postalara ne yapılacağını (izle, karantinaya al, reddet) belirler ve size raporlar gönderir.

Gmail ve Yahoo tüm göndericilerden en az SPF veya DKIM, günde 5.000 civarı ve üzeri ileti gönderenlerden ise SPF, DKIM ve DMARC’ın birlikte kurulmasını ister; Microsoft da Outlook.com ve Hotmail adreslerine aynı alan adından 5.000 ve üzeri ileti gönderenler için benzer şartlar uygular. Kurumsal e-posta hizmetimiz bu kayıtların yapılandırılmasını içerir; ayrıntılar için kurumsal e-posta sayfasına bakabilirsiniz.

Alan adı ve DNS güvenliği

Alan adı kayıt hesabınızın ele geçirilmesi, tüm sitenizin ve e-postanızın ele geçirilmesi demektir. Transfer kilidini etkin tutun, kayıt hesabında 2FA kullanın ve destekleniyorsa DNSSEC’i etkinleştirin. Ayrıntılar domain nedir rehberimizde yer alıyor.

Hosting altyapısının rolü

Sitenizin güvenliği, üzerinde çalıştığı altyapının güvenliğinden bağımsız değildir. Paylaşımlı hostingte hesapların birbirinden izole edilmesi (ör. CloudLinux), sunucu düzeyinde WAF ve kötü amaçlı yazılım taraması, düzenli sunucu yamaları ve fiziksel veri merkezi güvenliği sağlayıcının sorumluluğundadır. Sağlayıcı seçerken bu önlemleri ve verilerin hangi ülkede tutulduğunu sorun; genel seçim kriterleri için hosting nedir rehberimize göz atabilirsiniz. Altyapımız hakkında bilgi için veri merkezi sayfamızı inceleyebilirsiniz.

Ücretsiz araçlarla dışarıdan güvenlik kontrolü

Bazı önlemlerin doğru kurulup kurulmadığını, sitenizin dışarıya verdiği yanıtlardan görebilirsiniz. Aşağıdaki kontrolleri alan adınızı yazarak yapabilirsiniz:

Bu araçlar yalnız dışarıdan görünen yapılandırmayı ölçer. Yazılımların güncelliği, kullanıcı yetkileri ve yedeklerin geri yüklenebilirliği gibi iç önlemleri ayrıca denetlemeniz gerekir. Eksik başlıkları eklemek için güvenlik başlıkları ekleme rehberine bakabilirsiniz.

KVKK ve web siteleri: site sahiplerinin bilmesi gerekenler

6698 sayılı Kişisel Verilerin Korunması Kanunu, 7 Nisan 2016 tarihli ve 29677 sayılı Resmî Gazete’de yayımlandı. Bir web sitesi üzerinden iletişim formu, üyelik, sipariş, bülten aboneliği veya analiz çerezleri aracılığıyla kişisel veri topluyorsanız, büyük olasılıkla veri sorumlusu konumundasınız. Hosting sağlayıcınız ise çoğu durumda veriyi sizin adınıza işlediği için veri işleyen konumundadır.

Kişisel veri nedir?

Kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi kişisel veridir: ad, e-posta adresi, telefon numarası, IP adresi, sipariş geçmişi, çerez tanımlayıcıları. Sağlık, biyometrik veri, din, ceza mahkûmiyeti gibi bilgiler ise özel nitelikli kişisel veri sayılır ve daha sıkı kurallara tabidir.

Aydınlatma yükümlülüğü (m.10)

Kişisel veri toplarken ilgili kişiyi; veri sorumlusunun kimliği, verilerin hangi amaçla işleneceği, kimlere ve hangi amaçla aktarılabileceği, toplama yöntemi ve hukuki sebebi ile kişinin hakları konusunda bilgilendirmeniz gerekir. Web sitelerinde bu genellikle formların yanında bağlantı verilen bir aydınlatma metni ile yapılır. Kurul’un ilke kararına göre, açık rızaya dayanılan durumlarda aydınlatma metni ile açık rıza metni farklı başlıklar altında, ayrı metinler olarak düzenlenmelidir. Aydınlatma metni için ilgili kişiden onay ya da rıza istenmez; yalnızca metnin okunduğuna ilişkin geri bildirim alınabilir.

Açık rıza ne zaman gerekir?

Açık rıza, kişisel veri işlemenin hukuki sebeplerinden yalnızca biridir. Sözleşmenin ifası (ör. siparişin teslimi), hukuki yükümlülük (ör. fatura) veya meşru menfaat gibi başka bir hukuki sebep varsa ayrıca açık rıza alınmaz. Pazarlama iletişimi, bazı çerezler ve yurt dışına aktarımın bazı halleri gibi durumlarda ise açık rıza gerekebilir. Hizmeti açık rızaya bağlamak (ör. “rıza vermezseniz sipariş veremezsiniz”) geçerli bir rıza değildir.

Veri güvenliği yükümlülüğü (m.12)

Kanun’un 12. maddesi, veri sorumlusunun kişisel verilerin hukuka aykırı işlenmesini ve erişilmesini önlemek ve muhafazasını sağlamak için uygun güvenlik düzeyini temin etmeye yönelik gerekli her türlü teknik ve idari tedbiri almasını öngörür. Bu yazının ilk bölümündeki teknik önlemler, bu yükümlülüğün pratikteki karşılığıdır. Kurum’un yayımladığı Kişisel Veri Güvenliği Rehberi, erişim yetkilendirme, şifreleme, kayıt (log) tutma, yedekleme, sızma testi ve çalışan eğitimi gibi tedbirleri ayrıntılandırır. Veri işleyenle (ör. hosting sağlayıcısı, e-posta pazarlama hizmeti) yapılan sözleşmelerde de güvenlik yükümlülükleri tanımlanmalıdır; çünkü veri işleyen, tedbirlerin alınması konusunda veri sorumlusuyla birlikte müştereken sorumludur.

Veri ihlali bildirimi

İşlenen kişisel verilerin kanuni olmayan yollarla başkaları tarafından elde edilmesi hâlinde veri sorumlusu, durumu en kısa sürede ilgili kişiye ve Kurul’a bildirmekle yükümlüdür (m.12/5). Kurul, 24.01.2019 tarihli ve 2019/10 sayılı kararıyla “en kısa süre”yi, veri sorumlusunun ihlali öğrendiği tarihten itibaren gecikmeksizin ve en geç 72 saat olarak yorumlamıştır. İlgili kişilere ise ihlalden etkilenen kişiler tespit edildikten sonra makul en kısa sürede bildirim yapılmalıdır. Bildirim, Kurum’un internet sitesindeki veri ihlali bildirim formu ile yapılır. Bu süre çok kısa olduğundan olay müdahale planınızın hazır olması gerekir.

VERBİS kaydı

Veri Sorumluları Sicili’ne (VERBİS) kayıt yükümlülüğünden, Kurul’un 04.09.2025 tarihli ve 2025/1572 sayılı kararıyla şu veri sorumluları istisna tutulmuştur:

• Yıllık çalışan sayısı 50’den az ve yıllık mali bilanço toplamı 100 milyon TL’den az olan ve ana faaliyet konusu özel nitelikli kişisel veri işleme olmayan veri sorumluları,
• Ana faaliyet konusu özel nitelikli kişisel veri işleme olmakla birlikte, yıllık çalışan sayısı 10’dan az ve yıllık mali bilanço toplamı 10 milyon TL’den az olan veri sorumluları.

Kurul’un 25.12.2025 tarihli ve 2025/2393 sayılı kararıyla, bilanço esasına göre defter tutmayan veri sorumluları için yalnızca çalışan sayısı kriterinin esas alınacağı netleştirilmiştir. Yurt dışında yerleşik veri sorumluları ve bazı sektörler için farklı kurallar bulunduğundan, kayıt yükümlülüğünüzü VERBİS rehberinden kontrol edin. İstisna kapsamında olmak, KVKK’nın diğer yükümlülüklerinden (aydınlatma, güvenlik, ihlal bildirimi) muafiyet anlamına gelmez.

Yurt dışına veri aktarımı (m.9) ve 7499 sayılı Kanun

Web siteleri farkında olmadan sürekli yurt dışına veri aktarabilir: yurt dışındaki bir sunucuda barındırma, yurt dışı merkezli e-posta ve analiz araçları, CDN’ler, canlı destek ve form hizmetleri. 12 Mart 2024 tarihli Resmî Gazete’de yayımlanan 7499 sayılı Kanun ile KVKK’nın 9. maddesi kapsamlı olarak değiştirildi ve yeni düzenleme 1 Haziran 2024’te yürürlüğe girdi. Yeni sistemde yurt dışı aktarım, kabaca şu sıralamayla değerlendirilir:

1. Yeterlilik kararı bulunan ülkelere veya uluslararası kuruluşlara, işleme şartlarından biri varsa aktarım yapılabilir.
2. Yeterlilik kararı yoksa, uygun güvencelerden biri sağlanmalıdır: Kurul’un ilan ettiği standart sözleşmeler, bağlayıcı şirket kuralları veya Kurul izniyle yazılı taahhütname. Standart sözleşme, imzalanmasından itibaren beş iş günü içinde Kurum’a bildirilmelidir; Kurum bu amaçla bir bildirim modülü sunmaktadır.
3. Bunların hiçbiri yoksa, yalnızca arızi (süreklilik arz etmeyen) aktarımlarda, açık rıza gibi sınırlı istisnalara dayanılabilir.

Kurul’un bir ülke için yeterlilik kararı verip vermediğini Kurum’un internet sitesindeki yurt dışına aktarım sayfasından kontrol edin. Bu nedenle yurt dışında yerleşik hizmet sağlayıcılarla çalışırken standart sözleşme gibi bir uygun güvence mekanizması kurmanız gerekebilir. Verilerin Türkiye’deki bir veri merkezinde barındırılması, en azından barındırma kaynaklı yurt dışı aktarımı ortadan kaldırarak bu süreci sadeleştirir. Kurumsal ihtiyaçlar için kurumsal hosting sayfamız bu konuları ayrıntılı ele alıyor.

Çerezler ve rıza yönetimi

Kurum’un Çerez Uygulamaları Hakkında Rehberi’ne göre, sitenin çalışması için zorunlu çerezler dışındaki çerezler (analiz, kişiselleştirme, reklam/hedefleme) için kural olarak açık rıza gerekir. Pratikte:

• Zorunlu olmayan çerezler, kullanıcı rıza vermeden yüklenmemelidir.
• Çerez bildirimi, “kabul et” kadar kolay bir “reddet” seçeneği sunmalıdır; önceden işaretlenmiş kutular geçerli rıza oluşturmaz.
• Çerez politikası, kullanılan çerezleri, amaçlarını, sürelerini ve üçüncü tarafları açıklamalıdır.
• Rıza kayıtları saklanmalı ve kullanıcı rızasını kolayca geri alabilmelidir.

Bu yükümlülükler pazarlama iletişimi kurallarından (ticari elektronik ileti ve İYS) ayrıdır; e-posta bülteni gönderiyorsanız bu düzenlemeleri de ayrıca değerlendirin.

İlgili kişi başvuruları

Kişiler, verilerinin işlenip işlenmediğini öğrenme, düzeltilmesini veya silinmesini isteme gibi haklara sahiptir (m.11). Veri sorumlusu, başvuruları en geç otuz gün içinde sonuçlandırmalıdır. Web sitenizde başvuru yöntemini açıkça belirtin ve gelen başvuruları takip edecek bir süreç oluşturun.

5651 sayılı Kanun ve log kayıtları

KVKK’nın yanı sıra, internet ortamındaki yayınları düzenleyen 5651 sayılı Kanun da hosting ve web sitesi işletmecilerini ilgilendirir. Kanun’un 5. maddesi uyarınca yer sağlayıcılar (hosting hizmeti sunanlar), sundukları hizmetlere ilişkin trafik bilgilerini bir yıldan az ve iki yıldan fazla olmamak üzere yönetmelikte belirlenen süre boyunca saklamak ve bu bilgilerin doğruluğunu, bütünlüğünü ve gizliliğini sağlamakla yükümlüdür. Kanunun güncel metni ve değişiklik geçmişi mevzuat.gov.tr’de yayımlanır.

Kendi sunucunuzda başkalarına hizmet veriyorsanız veya bir işletme olarak çalışanlarınıza ya da müşterilerinize internet erişimi sağlıyorsanız (ör. misafir Wi-Fi), size de log tutma yükümlülüğü doğabilir. Log kayıtlarının kendisi de kişisel veri içerdiğinden, erişimi sınırlanmalı ve saklama süresi sonunda imha edilmelidir. Bu noktada 5651 ve KVKK yükümlülükleri birlikte değerlendirilmelidir.

Sitenin ele geçirildiğini gösteren belirtiler

Saldırıların çoğu sessiz ilerler: site açılmaya devam ederken arka planda spam sayfası barındırabilir ya da sizin adınıza e-posta gönderebilir. Aşağıdaki belirtilerden birini görürseniz bir sonraki bölümdeki müdahale adımlarına geçin.

WordPress sitelerde temizlik adımları hacklenen WordPress temizleme rehberinde. İşin bizim tarafımızdan yapılmasını isterseniz hacklenen site kurtarma hizmetine bakabilirsiniz.

Olay müdahalesi: siteniz hacklendiğinde ne yapmalısınız?

Hazırlıklı olmak, bir güvenlik olayının etkisini ve süresini büyük ölçüde azaltır. Aşağıdaki adımlar genel bir çerçevedir; kendi altyapınıza göre uyarlayıp yazılı bir plan hâline getirin.

1. Olayı doğrulayın ve kayıt altına alın: Belirtileri (değişen sayfalar, bilinmeyen kullanıcılar, şüpheli dosyalar, güvenlik uyarıları) not edin; olayı öğrendiğiniz tarih ve saati kaydedin. KVKK’daki 72 saatlik süre bu andan itibaren işler.
2. Yayılmayı durdurun: Gerekirse siteyi bakım moduna alın; tüm yönetici, hosting, veritabanı ve FTP/SFTP parolalarını değiştirin; bilinmeyen kullanıcıları ve oturumları kapatın.
3. Kanıtları koruyun: Sunucu ve uygulama loglarını, değiştirilmiş dosyaları silmeden önce bir kopyasını alın. Bu kayıtlar hem kök neden analizi hem de olası yasal süreçler için gereklidir.
4. Kapsamı belirleyin: Saldırganın nasıl girdiğini, hangi sistemlere eriştiğini ve kişisel verilerin etkilenip etkilenmediğini tespit edin. Hosting sağlayıcınızdan destek isteyin.
5. Temizleyin ve geri yükleyin: Saldırıdan önceki temiz bir yedekten geri yükleyin; açığı kapatmadan (ör. güncellemeyi yapmadan) siteyi yeniden açmayın.
6. Bildirimleri yapın: Kişisel veriler etkilendiyse Kurul’a en geç 72 saat içinde veri ihlali bildirim formuyla, ilgili kişilere ise makul en kısa sürede bildirim yapın. İhlalin ne zaman öğrenildiğini, hangi verilerin ve kaç kişinin etkilendiğini ve aldığınız önlemleri yazılı olarak kayıt altında tutun.
7. Ders çıkarın: Kök nedeni, alınan aksiyonları ve iyileştirmeleri belgeleyin; olay müdahale planınızı güncelleyin.

Sorumluluk paylaşımı: hosting tarafı ve site sahibi

Paylaşımlı hostingte bazı önlemler sağlayıcının altyapısında, bazıları ise sizin elinizdedir. dticaret hostingte bu paylaşım şöyledir:

Bu tablo teknik önlemleri gösterir. Aydınlatma, rıza ve ilgili kişi başvuruları gibi süreçler veri sorumlusu olarak site sahibine aittir.

Güvenlik ve KVKK kontrol listesi

Sık sorulan sorular

Sonuç

Web sitesi güvenliği ve KVKK uyumu ayrı projeler değil, aynı hedefin iki yüzüdür: Ziyaretçilerinizin ve müşterilerinizin verilerini korumak. Güncel yazılımlar, güçlü kimlik doğrulama, düzenli ve test edilmiş yedekler, doğru yapılandırılmış HTTPS ve e-posta kayıtları teknik temeli oluşturur. Aydınlatma metinleri, çerez rızası, veri envanteri, yurt dışı aktarım güvenceleri ve 72 saatlik ihlal bildirim süreci ise yasal çerçeveyi tamamlar. Bugün kontrol listesindeki maddeleri tek tek gözden geçirmek, yarın yaşanabilecek bir olayın maliyetini önemli ölçüde azaltır.

Kaynaklar

• 6698 sayılı Kişisel Verilerin Korunması Kanunu (RG 07.04.2016, 29677): https://www.mevzuat.gov.tr/MevzuatMetin/1.5.6698.pdf
• 7499 sayılı Kanun (RG 12.03.2024, 32487): https://www.resmigazete.gov.tr/eskiler/2024/03/20240312-1.htm
• KVKK – Kişisel Verilerin Yurt Dışına Aktarılması Rehberi ve standart sözleşme bildirim duyurusu: https://www.kvkk.gov.tr/
• Kurul’un 24.01.2019 tarihli ve 2019/10 sayılı Kararı (veri ihlali bildirim usulü): https://www.kvkk.gov.tr/
• Kurul’un 2025/1572 ve 2025/2393 sayılı VERBİS kararları ve uygulama esasları duyurusu (12.01.2026): https://www.kvkk.gov.tr/
• KVKK – Çerez Uygulamaları Hakkında Rehber (güncelleme 2025): https://www.kvkk.gov.tr/
• KVKK – Kişisel Veri Güvenliği Rehberi (Teknik ve İdari Tedbirler): https://www.kvkk.gov.tr/
• 5651 sayılı Kanun: https://www.mevzuat.gov.tr/MevzuatMetin/1.5.5651.htm
• CA/Browser Forum – Ballot SC-081: https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
• OWASP Top 10: https://owasp.org/www-project-top-ten/
• Google – E-posta gönderen yönergeleri: https://support.google.com/a/answer/81126
• MDN – HTTP güvenlik başlıkları: https://developer.mozilla.org/docs/Web/HTTP/Headers