1. Privacy by Design ve Privacy by Default Nedir?
Privacy by design ve privacy by default ne anlama gelir?
Kısa yanıt: privacy by design, gizliliği ürünün tasarımına en baştan entegre etmektir; privacy by default ise varsayılan ayarların minimum veri ve minimum paylaşım olacak şekilde güvenli gelmesidir. Teknik tarafta bu; veri minimizasyonu, izin/consent, logging, erişim kontrolü ve export/retention kararlarının “sonradan değil, baştan” verilmesi demektir.
Built-in vs bolted-on
- •Built-in (gömülü): süreçte kontrol noktaları var, her release’te çalışır
- •Bolted-on (sonradan): sorun çıktıkça yamalanır, sürdürülemez
“Gereksiz veri toplamayan UX” ve “güvenli varsayılan” birlikte çalışır
Örneğin formda opsiyonel alanlar default kapalıysa, hem dönüşüm hem KVKK kazanır. Varsayılan export kapalıysa, risk yüzeyi küçülür.
☑ Mini Check
- •“Amaç kadar veri” prensibi yazılı mı?
- •Varsayılan ayarlar güvenli mi? (export kapalı, minimum log)
- •Consent/izin ekranları süreçte planlı mı?
- •Logging PII-minimize mi?
- •Release sonrası privacy review var mı?
Ne yapmalıyım?
- • Privacy by default “varsayılanlar” listesini çıkarın.
- • Ürün backlog’una privacy etiketi ekleyin.
- • Form/izin/log/export kararlarını tasarımın parçası yapın.
- • Release sonrası 30 günlük review ritmi koyun.
- • Web geliştirme ile bağlayın: https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme
2. Discovery Aşaması: Amaç Analizi + Veri Minimizasyonu
Discovery, privacy by design’ın en kritik aşamasıdır; çünkü “neden veri topluyoruz?” sorusunun cevabı burada netleşir. Bu netlik yoksa ürün geliştikçe alanlar ve loglar şişer, sonra temizlemek pahalılaşır.
Discovery’de sorulacak temel sorular
- •Bu özellik hangi iş kararını kolaylaştırıyor?
- •Hangi veri gerçekten gerekli? (whitelist)
- •Alternatif var mı? (daha az veriyle aynı sonuç)
- •Veri nerede tutulacak? (prod/backup/log)
- •Vendor var mı? (erişim haritası)
Otel/B2B örneği
- •Otel: “fiyat teklifi” formunda zorunlu alanları minimize et
- •B2B: “demo talebi” formunda gereksiz kişisel alanları kaldır
☑ Mini Check
- •Feature için veri whitelist çıkarıldı mı?
- •Gereksiz alanlar “yasaklı liste”de mi?
- •Veri kaynakları ve sistem envanteri net mi?
- •Vendor/entegrasyonlar discovery’de görüldü mü?
- •Retention yaklaşımı not edildi mi?
Ne yapmalıyım?
- • Her feature için “data whitelist” dokümanı yazın.
- • Form alanlarını discovery’de belirleyin (UX’e bırakmayın).
- • Vendor entegrasyonu varsa erişim kapsamını ilk gün yazın.
- • Veri haritasını update edin.
- • KVKK veri güvenliğiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi

3. Design Aşaması: Form, İzin ve Logging Kararları
Form, log ve izin kararlarını hangi aşamada almalıyım?
Kısa yanıt: design aşamasında. Çünkü kullanıcı deneyimi (form alanları, izin ekranları) ve teknik davranış (hangi event/log tutulacak) birlikte tasarlanmalıdır. Design aşamasında alınmayan kararlar, dev’de “kolay olsun” diye geniş log/alan setlerine dönüşebilir.
Design çıktıları (pratik)
- •Form alanları: zorunlu/opsiyonel
- •Consent kutuları: ayrı, pre-checked değil
- •Aydınlatma linki: görünür
- •Logging planı: hangi event, hangi alan (PII minimize)
- •Error/feedback ekranları: serbest metin kontrolü
Privacy by default: default kapalı/limitli
- •Export default kapalı
- •Debug log default kapalı (prod’da)
- •Tracking default minimal (consent sonrası genişler)
☑ Mini Check
- •Form alanları minimize edildi mi?
- •Consent kutuları ayrıştırıldı mı?
- •Logging şeması PII-minimize mi?
- •Error/feedback ekranları kontrollü mü?
- •Default ayarlar güvenli mi?
Ne yapmalıyım?
- • Design review’e “privacy checklist” ekleyin.
- • Consent ve form kararlarını UI mockup ile sabitleyin.
- • Logging şemasını tasarım dokümanına koyun.
- • KVKK uyumlu form yaklaşımını referans alın.
- • CMS entegrasyonu ile bağlayın: https://dgtlface.com/tr/yazilim/cms-entegrasyonu
4. Dev + Test Aşaması: Uygulama, Otomatik Kontrol, KVKK Checklist
Dev aşamasında privacy by design “kodda” görünür olur: RBAC, şifreleme, logging redaction, consent’e bağlı tetikleme, secrets yönetimi. Test aşamasında ise bunların gerçekten çalıştığı doğrulanır.
Dev: teknik uygulama maddeleri
- •RBAC + MFA (admin)
- •TLS ve at-rest şifreleme
- •Logging redaction (e-posta/telefon maskeleme)
- •Consent sonrası tag firing (GTM)
- •Secrets manager (token/anahtarlar)
Test: KVKK checklist doğrulaması
- •Consent reddinde tag çalışmıyor mu?
- •Export default kapalı mı?
- •Loglar PII içeriyor mu?
- •Test ortamında gerçek veri var mı?
- •Backup/restore ve log heartbeat çalışıyor mu?
“Test verisi” en büyük sürpriz kaynaklardan biridir
Prod verisini stage’e taşıyıp “test” yapmak, privacy by design’ı bozar. Testte pseudo/masked dataset kullanmak en iyi pratiktir.
☑ Mini Check
- •Dev’de RBAC+MFA uygulanmış mı?
- •Loglarda redaction aktif mi?
- •Consent testleri yapılmış mı?
- •Test verisi maskeli mi?
- •Release öncesi privacy checklist imzalı mı?
Ne yapmalıyım?
- • CI/CD’ye privacy test adımı ekleyin (basic checks).
- • Release checklist’ine KVKK maddeleri koyun.
- • Stage/test verisini pseudo/masked yapın.
- • Teknik SEO ve ölçüm tarafını da dahil edin.
- • Teknik SEO ile bağlayın: https://dgtlface.com/tr/seo/teknik-seo

5. Release Sonrası: Periyodik Privacy Review + Sprint Başına Privacy Task Örnekleri
Privacy by design “yayına çıktı bitti” değildir; release sonrası yeni script’ler, yeni vendor’lar, yeni alanlar eklenir. Bu yüzden periyodik privacy review (ör. 30–90 gün) ve sprint başına küçük privacy görevleriyle sistem canlı tutulmalıdır.
Sprint başına privacy task örnekleri (pratik)
- •Yeni form alanı eklendiyse: minimizasyon + consent güncelle
- •Yeni vendor eklendiyse: erişim haritası + token politikası
- •Yeni event eklendiyse: log redaction + retention
- •Yeni kampanya script’i: consent tetik testi
- •Release sonrası: “privacy smoke test” (10 dk)
Key Data Point (yumuşatılmış)
Privacy by design checklist’leri olan ekiplerde, yeni özellikler yayına alınırken KVKK kaynaklı geri dönüş ve son dakika revizyonları daha az yaşanır; çünkü kontrol noktaları sürecin içine gömülüdür.
☑ Mini Check
- •Release sonrası privacy review takvimi var
- •Sprint başına en az 1 privacy task var
- •Yeni vendor/script değişiklikleri review’a giriyor
- •Consent ve logging smoke test yapılabiliyor
- •365 gün checklist güncelleme planı var
Ne yapmalıyım?
- • Backlog’a “privacy” etiketi ve DoD maddesi ekleyin.
- • Her sprintte 1 küçük privacy task planlayın.
- • Release sonrası 30–90 gün review ritmi koyun.
- • Dokümantasyonu yaşayan hale getirin (365 gün).
- • İç linklerle SDLC’yi hizalayın: https://dgtlface.com/tr/yazilim/web-sitesi-gelistirme, https://dgtlface.com/tr/seo/teknik-seo, https://dgtlface.com/tr/yazilim/cms-entegrasyonu, https://dgtlface.com/tr/yazilim/kvkk-uyum-hizmeti




Teknik not: Bu yaklaşımın kalıcı olması için /tr/yazilim/web-sitesi-gelistirme, /tr/seo/teknik-seo ve /tr/yazilim/cms-entegrasyonu ile birlikte yürütülmelidir. Bu içerik hukuki yorum değil, süreç ve teknik kontrol rehberidir.
6. Aşama Bazlı KVKK Checklist Tablosu
| Aşama | Soru | Çıktı | Owner |
|---|---|---|---|
| Discovery | Amaç nedir, hangi veri gerçekten gerekli, vendor/entegrasyon var mı? | Data whitelist + veri haritası + retention/backup/log notu | Product Owner + IT/BT |
| Design | Form, consent, logging ve varsayılan ayarlar minimize edildi mi? | UI mockup + consent modeli + logging şeması | UX + Product + IT/BT |
| Dev | RBAC/MFA, şifreleme, redaction, secrets ve consent tetikleme uygulandı mı? | Teknik kontrol seti + kod/config çıktıları | Dev + DevOps |
| Test | Consent, log, export ve test verisi kontrolleri gerçekten çalışıyor mu? | Privacy test sonuçları + release checklist | QA + Dev |
| Release | Privacy smoke test geçti mi ve post-release review planlandı mı? | Release onayı + 30–90 gün review takvimi | Product + QA + IT/BT |
7. Ürün & Web Geliştirme İçin Privacy by Design Checklist Şablonunu İndir
Ürün & Web Geliştirme İçin Privacy by Design Checklist Şablonunu İndir — Yazılım / SDLC Privacy (v1.0)
Bu asset, privacy by design/default yaklaşımını ürün geliştirme yaşam döngüsüne (discovery→design→dev→test→release) gömmek için aşama bazlı checklist sunar. Form, izin, logging, erişim ve vendor kararlarını en başta almayı standardize eder. Otel ve B2B projelerinde KVKK kaynaklı son dakika revizyonlarını azaltmayı hedefler.
Kim Kullanır?
Product owner + UX + dev + QA + IT/BT.
Nasıl Kullanılır?
- Her aşamada sorulacak KVKK sorularını ve çıktıları doldur.
- Sprint başına en az 1 privacy task planla (backlog etiketi).
- Release öncesi “privacy smoke test” ve release sonrası review takvimi koy.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Discovery — Feature “amaç” tanımı yazılı
- ▢ ✅ Discovery — Data whitelist çıkarıldı (gerekli alanlar)
- ▢ ✅ Discovery — Gereksiz alanlar yasak listede
- ▢ ✅ Discovery — Vendor/entegrasyon ihtiyacı görüldü
- ▢ ✅ Discovery — Retention/backup/log notu eklendi
- ▢ ✅ Design — Form alanları minimize (zorunlu/opsiyonel net)
- ▢ ✅ Design — Consent kutuları ayrı ve pre-checked değil
- ▢ ✅ Design — Aydınlatma linki görünür
- ▢ ✅ Design — Logging şeması tasarım dokümanında
- ▢ ✅ Design — Default ayarlar güvenli (export kapalı, minimal tracking)
- ▢ ✅ Dev — RBAC/MFA uygulandı (admin)
- ▢ ✅ Dev — TLS + at-rest şifreleme planlandı/uygulandı
- ▢ ✅ Dev — Log redaction aktif
- ▢ ✅ Dev — Secrets manager kullanılıyor
- ▢ ✅ Dev — Tag/script consent sonrası tetikleniyor
- ▢ ✅ Test — Consent reddinde tag çalışmıyor
- ▢ ✅ Test — Loglarda PII yok (masking test)
- ▢ ✅ Test — Export varsayılan kapalı/rol bazlı
- ▢ ✅ Test — Stage/test verisi pseudo/masked
- ▢ ✅ Test — Backup/restore ve log heartbeat kontrol edildi
- ▢ ✅ Release + Post-Release — Privacy smoke test geçti
- ▢ ✅ Release + Post-Release — 30–90 gün privacy review takvimlendi
- ▢ ✅ Release + Post-Release — Yeni vendor/script değişiklikleri review’a giriyor
- ▢ ✅ Release + Post-Release — 365 gün checklist güncelleme planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu


Bir Sonraki Adım
KVKK’yı SDLC’ye gömer; sprint başına privacy görevleri ve release checklist ile son dakika revizyonlarını azaltır.
Sık Sorulan Sorular
Privacy by design ve privacy by default ne anlama gelir?▾
Web/ürün geliştirme sürecine KVKK’yı nasıl gömerim?▾
Form, log ve izin kararlarını hangi aşamada almalıyım?▾
Otel ve B2B için örnek privacy by design adımları neler?▾
Ürünü bitirdikten sonra değil, baştan KVKK’ya uygun tasarlamak istiyorum, nasıl yaparım?▾
En sık yapılan hata nedir?▾
İlgili İçerikler
