Aydınlatma metni yükleniyor…
Kurumsal bir web sitesi; marka anlatımının yanı sıra iletişim formları, çerezler, analitik araçları, iş başvuruları, üyelik alanları ve harici sistem bağlantıları üzerinden kişisel veri işleyen bir platformdur. Bu nedenle KVKK ve GDPR uyumlu kurumsal web tasarım, proje tamamlandıktan sonra eklenecek birkaç hukuki metinden ibaret değildir. Veri toplama amaçlarının, kullanıcı tercihlerinin, yazılım mimarisinin ve operasyonel sorumlulukların daha kapsam belirlenirken ele alınması gerekir.
Uyumun hukuki değerlendirmesi veri sorumlusuna ve yetkili hukuk danışmanlarına aittir. Tasarım ve yazılım ekibinin görevi ise belirlenen kuralları çalışan, denetlenebilir ve sürdürülebilir bir dijital deneyime dönüştürmektir. Bu yaklaşım hem ziyaretçinin gizlilik beklentisini destekler hem de pazarlama, bilgi teknolojileri, hukuk ve bilgi güvenliği ekiplerinin aynı sistem üzerinde kontrollü biçimde çalışmasını kolaylaştırır.
KVKK ve GDPR uyumlu web tasarım ne anlama gelir?
Uyumlu web tasarım; hangi kişisel verinin, hangi kullanıcı temasında, hangi amaç ve hukuki dayanakla toplandığını görünür hâle getiren bir proje yaklaşımıdır. Yalnızca gizlilik politikasının yayımlanması yeterli değildir. Form alanlarından üçüncü taraf komut dosyalarına, yönetim panelindeki kullanıcı rollerinden saklama ve silme süreçlerine kadar tüm sistem bu yaklaşımı desteklemelidir.
GDPR’ın 25. maddesi veri korumasının tasarıma ve varsayılan ayarlara dâhil edilmesini; 32. maddesi ise riskle orantılı teknik ve organizasyonel tedbirleri ele alır. Düzenleme, güvenliğin tek seferlik bir kurulum olmadığını; tedbirlerin düzenli biçimde test edilmesi ve değerlendirilmesi gerektiğini de belirtir. Ayrıntılar GDPR’ın resmî metninde incelenebilir.
Projeye veri envanteriyle başlayın
İlk çalışma, sayfa listesinden önce veri akışlarını çıkarmak olmalıdır. İletişim, teklif, e-bülten, etkinlik kaydı, iş başvurusu, canlı destek ve müşteri girişi gibi her temas noktası ayrı değerlendirilmelidir. Toplanan alanlar, işleme amacı, hukuki dayanak, alıcılar, saklama süresi, yurt dışı aktarım ihtimali ve silme yöntemi kayıt altına alınmalıdır.
Bu envanter teknik ekibe somut gereksinimler verir. Örneğin teklif talebi için telefon numarası gerçekten zorunlu mu, özgeçmişler hangi süre sonunda silinecek, form kaydı hem e-posta kutusunda hem yönetim panelinde mi tutulacak, analitik sağlayıcısına hangi tanımlayıcılar aktarılacak? Bu sorular yanıtlanmadan geliştirilen bir sistem gereksiz veri, belirsiz yetki ve kontrolsüz kopyalar üretebilir.
Veri minimizasyonunu arayüze uygulayın
Her form alanı bir iş ihtiyacına dayanmalıdır. Zorunlu ve isteğe bağlı alanlar ayırt edilmeli; hassas bilgi gerektirmeyen süreçlerde serbest metin alanlarının riski dikkate alınmalıdır. Kullanıcıdan dosya isteniyorsa izin verilen dosya türleri, boyut sınırı, kötü amaçlı içerik kontrolü ve erişim yetkisi planlanmalıdır. “İleride lazım olabilir” düşüncesiyle veri toplamak yerine amaca yetecek en dar veri kümesi tercih edilmelidir.
Aydınlatma ve açık rıza aynı işlem değildir
Aydınlatma, kişiye verisinin kim tarafından, hangi amaçlarla ve hangi yöntemle işlendiğini açıklamayı amaçlar. Açık rıza ise yalnızca uygun hukuki dayanağın rıza olduğu faaliyetler için gündeme gelir. Bir kutucuğun altına iki farklı metni birlikte yerleştirmek veya hizmet için zorunlu olmayan pazarlama iznini form gönderiminin şartı yapmak, sağlıklı bir tercih deneyimi oluşturmaz.
Formun bağlamına uygun kısa bilgilendirme kullanıcıya işlem anında sunulmalı; ayrıntılı metne erişim sağlanmalıdır. Pazarlama iletişimi gibi ayrı bir amaç varsa ilgili tercih bağımsız yönetilmeli, önceden işaretlenmemeli ve geri alınabilmelidir. Tercihin hangi metin sürümü, zaman ve kanal üzerinden verildiğinin kanıtlanabilir biçimde kaydedilmesi de sistem tasarımının parçasıdır.
Çerez tercih mekanizması nasıl tasarlanmalı?
Çerez bandı yalnızca “kabul et” düğmesi gösteren görsel bir katman değildir. Kullanılan çerezler ve benzer teknolojiler taranmalı; zorunlu, işlevsel, analitik ve pazarlama gibi amaçlara göre sınıflandırılmalıdır. Zorunlu olmayan teknolojiler ilgili tercih verilmeden önce çalıştırılmamalı; reddetme seçeneği kabul kadar anlaşılır olmalı ve kullanıcı daha sonra kararını değiştirebilmelidir.
Kişisel Verileri Koruma Kurumunun Çerez Uygulamaları Hakkında Rehberi, açık rızanın belirli bir konuya ilişkin, bilgilendirmeye dayalı ve özgür iradeyle açıklanmış olması gerektiğini ele alır. Rehber ayrıca kullanıcının açıkça talep ettiği hizmet için kesinlikle gerekli çerezlerle analitik veya davranışsal reklam amaçlı kullanımların aynı kabul edilmemesi gerektiğini gösterir.
Tercih merkezi teknik olarak neyi kontrol etmeli?
- Etiket yöneticisi, analitik, reklam, video ve sosyal medya bileşenlerinin yüklenmesini kategori bazında yönetmelidir.
- Kabul, ret ve kategori seçimi aynı arayüzden değiştirilebilmelidir.
- Tercih kaydında metin ve yapılandırma sürümü izlenebilmelidir.
- Yeni bir üçüncü taraf eklendiğinde çerez envanteri ve bilgilendirme güncellenmelidir.
- Çerez silindiğinde veya süresi dolduğunda tercih akışı öngörülebilir biçimde yeniden çalışmalıdır.
Formlar ve entegrasyonlar uçtan uca ele alınmalı
Web formu çoğu zaman verinin son durağı değildir. Kayıt; e-posta servisine, CRM’e, destek yazılımına, insan kaynakları sistemine veya ERP’ye aktarılabilir. Bu nedenle form güvenliği yalnızca tarayıcıdaki doğrulamadan oluşmaz. Sunucu tarafı doğrulama, bot ve kötüye kullanım önlemleri, aktarım şifrelemesi, hata kayıtlarında kişisel verinin sınırlandırılması ve entegrasyon kimlik bilgilerinin güvenli yönetimi gerekir.
CRM bağlantılarında alan eşleştirme, mükerrer kayıt, sorumlu atama, aktarım hatası ve yeniden deneme davranışı tanımlanmalıdır. Bu konu, web ve mobil yazılım çözümleri kapsamında yalnızca bağlantı kurmak olarak değil, denetlenebilir bir iş akışı olarak değerlendirilmelidir. Daha ayrıntılı planlama için web sitesi–CRM entegrasyonu rehberi de incelenebilir.
Yönetim panelinde yetki ve hesap güvenliği
İçerik yöneticisi, pazarlama kullanıcısı, insan kaynakları çalışanı ve sistem yöneticisinin aynı yetkilere sahip olması gerekmez. En az yetki ilkesi doğrultusunda roller iş görevlerine göre ayrılmalı; kullanıcı yalnızca ihtiyacı olan menü, kayıt ve işlemlere erişebilmelidir. Kritik değişiklikler ile veri dışa aktarma, silme ve yetki tanımlama işlemleri kayda alınmalıdır.
Güçlü parola politikası, mümkün olduğunda çok faktörlü kimlik doğrulama, başarısız giriş sınırlaması, güvenli oturum sonlandırma ve kullanılmayan hesapların kapatılması temel kontroller arasındadır. Yetki denetimi yalnızca arayüzde bir düğmeyi gizlemekle bırakılmamalı; her istek sunucu tarafında doğrulanmalıdır.
| Temas noktası | Temel kontrol | Sorumlu ekip | Doğrulama |
|---|---|---|---|
| Formlar | Minimizasyon ve güvenli aktarım | Pazarlama + BT | Alan ve kayıt testi |
| Çerezler | Kategori bazlı tercih | Hukuk + Pazarlama | Ön onay engelleme testi |
| Yönetim paneli | Rol ve en az yetki | BT + Bilgi Güvenliği | Yetki senaryosu testi |
| Entegrasyonlar | Aktarım ve hata kontrolü | BT + Süreç sahibi | Uçtan uca akış testi |
| Yayın sonrası | Güncelleme ve saklama | BT + Uyum | Periyodik gözden geçirme |
Güvenli yazılım altyapısı için temel standartlar
Kurumsal web yazılımında güvenlik gereksinimleri teklif ve kapsam dokümanına ölçülebilir maddeler hâlinde eklenmelidir. OWASP’ın Application Security Verification Standard projesi, web uygulamalarındaki teknik güvenlik kontrollerini test etmek ve güvenli geliştirme gereksinimlerini tanımlamak için kullanılabilecek bir temel sunar.
- Tüm trafik güncel TLS yapılandırmasıyla şifrelenmeli ve güvenlik başlıkları değerlendirilmelidir.
- Girdiler güvenilir katmanda doğrulanmalı; sorgular parametreli yöntemlerle oluşturulmalı ve çıktılar bağlama uygun kodlanmalıdır.
- Parolalar geri döndürülebilir biçimde saklanmamalı; gizli anahtarlar kaynak koddan ayrılmalıdır.
- Yazılım bağımlılıkları izlenmeli, güvenlik güncellemeleri için sorumlu ve süre belirlenmelidir.
- Yedeklerin kapsamı, şifrelenmesi, saklama süresi ve geri yükleme testi tanımlanmalıdır.
- Loglar olay incelemesine yetecek bilgi üretmeli fakat gereksiz kişisel veri veya parola içermemelidir.
Üçüncü taraf servisler görünmeyen veri akışları yaratabilir
Harita, video, yazı tipi, canlı destek, CAPTCHA, analitik ve sosyal medya eklentileri ziyaretçinin tarayıcısından üçüncü taraflara istek gönderebilir. Bu isteklerde IP adresi, cihaz bilgileri ve tanımlayıcılar aktarılabilir. Her bileşen için sağlayıcı, veri kategorisi, amaç, saklama yaklaşımı, sunucu konumu ve sözleşmesel koşullar değerlendirilmelidir.
Bir servisin pazarlama açısından yararlı olması otomatik olarak gerekli olduğu anlamına gelmez. Mahremiyet dostu bir alternatif, yerel barındırma veya kullanıcı tercihi sonrasında yükleme seçeneği incelenmelidir. Sağlayıcı değiştiğinde ya da yeni bir entegrasyon eklendiğinde veri haritası, çerez yapılandırması ve ilgili metinler birlikte güncellenmelidir.
Erişilebilirlik ve gizlilik birlikte düşünülmeli
Gizlilik seçenekleri klavyeyle kullanılabilir, ekran okuyucular tarafından anlaşılabilir ve mobil ekranda erişilebilir olmalıdır. Düşük kontrastlı ret bağlantıları, kapanmayan pencereler veya odağı yanlış yöneten çerez katmanları gerçek bir seçim sunmaz. Form hata mesajları alanla ilişkilendirilmeli; kullanıcı hangi bilginin neden geçersiz olduğunu anlayabilmelidir.
Bu kontroller markaya özel kurumsal web tasarım sürecinin kullanıcı deneyimi, bilgi mimarisi ve arayüz tasarımı aşamalarına dâhil edilmelidir. Böylece mevzuat gereksinimleri sonradan eklenen ve deneyimi bozan katmanlar yerine sitenin doğal davranışlarına dönüşür.
Yayın öncesi kontrol listesi
- Tüm form, çerez, izleme ve entegrasyon noktaları veri envanteriyle karşılaştırıldı mı?
- Zorunlu olmayan komut dosyaları tercih verilmeden önce gerçekten engelleniyor mu?
- Aydınlatma metinleri doğru işlem anında ve okunabilir biçimde sunuluyor mu?
- Rol ve yetkiler gerçek görev ayrımına göre test edildi mi?
- Dosya yükleme, hata senaryoları, oturum yönetimi ve API erişimleri kontrol edildi mi?
- Mobil cihaz, klavye kullanımı ve yaygın tarayıcı senaryoları doğrulandı mı?
- Yedekten geri dönüş, güvenlik güncellemesi ve olay müdahalesi sorumluları belirlendi mi?
- Yayın sonrası periyodik tarama ve gözden geçirme takvimi oluşturuldu mu?
Uyum yayın günü bitmez
Web sitesi yaşayan bir sistemdir. Pazarlama ekibi yeni bir ölçüm etiketi ekleyebilir, insan kaynakları yeni bir başvuru alanı açabilir veya kullanılan üçüncü taraf servis veri işleme koşullarını değiştirebilir. Bu nedenle değişiklik yönetimi kurulmalı; yeni özellikler yayına alınmadan önce hukuk, güvenlik ve veri akışı etkisi açısından gözden geçirilmelidir.
Periyodik çerez taraması, kullanıcı ve yetki incelemesi, bağımlılık güncellemeleri, zafiyet kontrolleri, log değerlendirmesi ve geri yükleme testleri bakım planına bağlanmalıdır. Ayrıca saklama süresi dolan kayıtların silinmesi veya anonimleştirilmesi yalnızca politika metninde kalmamalı; teknik süreç veya sorumlu operasyon adımıyla uygulanmalıdır.
Kumsal Ajans yaklaşımıyla bütünleşik proje planı
Kumsal Ajans, kurumsal web projelerini marka hedefleri ve gerçek kullanıcı ihtiyaçlarıyla birlikte ele alır. Art Director liderliğindeki özgün tasarım yaklaşımı; bilgi mimarisi, projeye özel yazılım, yönetim paneli, formlar, entegrasyonlar, çerez tercih mekanizması ve yayın öncesi teknik kontrollerle birleştirilir. Amaç hukuki uygunluk garantisi vermek değil, kurumun hukuk ve bilgi güvenliği kararlarını uygulanabilir teknik özelliklere dönüştüren sağlam bir altyapı kurmaktır.
Kurumsal web sitenizin kapsamını, veri toplama akışlarını ve teknik güvenlik gereksinimlerini Kumsal Ajans ile birlikte değerlendirmek için iletişime geçin.


