Privacy by Design ve Privacy by Default İlkelerini Web ve Ürün Geliştirme Sürecine Gömmek

Privacy by Design ve Privacy by Default İlkelerini Web ve Ürün Geliştirme Sürecine Gömmek

14 dk okuma24 Temmuz 2026DGTLFACE Editorial

KVKK projeleri çoğu kurumda “revizyon” olarak ele alınır: ürün yayına çıkar, sonra form alanları fazla olduğu fark edilir, loglar PII taşıyordur, izin ekranı eksiktir, erişimler geniş kalmıştır. Bu yaklaşım hem pahalıdır hem de güven kaybı yaratır. Privacy by design/default ise tersini savunur: KVKK’yı bitmiş ürüne eklemek yerine, ürün geliştirme yaşam döngüsünün içine gömmek. Böylece “son dakika düzeltme” değil, “ilk günden doğru tasarım” yapılır. Otel ve B2B projelerinde bu daha da kritiktir: rezervasyon/lead akışları, CRM entegrasyonları, kampanya script’leri, call center ve BI katmanı aynı ürüne dokunur. Bu rehber; discovery→design→dev→test→release adımlarında hangi KVKK sorularını soracağınızı ve hangi kontrol listelerini çalıştıracağınızı pratik olarak anlatır.

Öne Çıkan Cevap

Privacy by design/default, KVKK uyumunu “yayından sonra düzeltme” yerine ürün geliştirme sürecinin doğal parçası yapar. Discovery’de amaç ve veri minimizasyonu netleşir; design’da form/izin ekranları ve log kapsamı belirlenir; dev’de erişim kontrolü, şifreleme ve logging kuralları uygulanır; test’te KVKK checklist’iyle doğrulama yapılır; release sonrası periyodik privacy review ile sapmalar yakalanır. Bu yaklaşım otel ve B2B projelerinde son dakika revizyonlarını ve riskleri azaltır.

Özet

KVKK’yı SDLC’ye göm: discovery’de amaç+minimizasyon, design’da form/izin, dev’de logging/şifreleme/RBAC, test’te kontrol listesi, release sonrası düzenli privacy review.

Maddeler

  • Hedef kitle: Product owner, UX, dev, QA, IT/BT, ajans ekipleri
  • KPI: KVKK kaynaklı revizyon sayısı, release gecikmesi, risk bulgu sayısı, consent/log uyumsuzluğu, sprint başına privacy task oranı
  • Entity: discovery, design, dev, test, release, privacy review, KVKK checklist
  • Geo: Türkiye (KVKK kapsamı)
  • Funnel: Consideration → Process adoption → Continuous compliance
  • Çıktı: SDLC timeline + aşama bazlı KVKK checklist + sprint privacy task örnekleri
  • Not: Hukuki yorum değil; teknik süreç ve kontrol tasarımı anlatılır.

Kısa Cevap

KVKK’yı en başta ele alın: discovery’den release’e her sprintte küçük privacy görevleri koyun.

Hızlı Özet

  • 1) Discovery’de amaç ve veri minimizasyonunu netleştir
  • 2) Design’da form, consent ve logging kararlarını sabitle
  • 3) Dev’de RBAC, şifreleme, redaction ve secrets kontrollerini uygula
  • 4) Test ve release öncesi privacy checklist + smoke test çalıştır
  • 5) Release sonrası privacy review ve sprint privacy task ritmi kur

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
Media bulunamadı → slug: privacy-by-design-ve-privacy-by-default-ilkelerini-web-ve-urun-gelistirme-surecine-gommek / slot: h1-context

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
Discovery aşaması veri minimizasyonu bölümü ayırıcı, KVKK hedefleri
Discovery aşaması veri minimizasyonu bölümü ayırıcı, KVKK hedefleri

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
Dev ve test KVKK checklist bölümü ayırıcı, release öncesi kontroller
Dev ve test KVKK checklist bölümü ayırıcı, release öncesi kontroller

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
Ürün yaşam döngüsüne gömülü privacy timeline diyagramı, SDLC KVKK
Ürün yaşam döngüsüne gömülü privacy timeline diyagramı, SDLC KVKK
Privacy by design checklist kartı, sprint ve release KVKK kontrolleri
Privacy by design checklist kartı, sprint ve release KVKK kontrolleri
KVKK kaynaklı revizyon ve risk bulgusu KPI kartı, ürün geliştirme
KVKK kaynaklı revizyon ve risk bulgusu KPI kartı, ürün geliştirme
SDLC privacy deliverables kartı, otel ve B2B ürün ekipleri
SDLC privacy deliverables kartı, otel ve B2B ürün ekipleri

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 bazlı KVKK checklist tablosu
AşamaSoruÇıktıOwner
DiscoveryAmaç nedir, hangi veri gerçekten gerekli, vendor/entegrasyon var mı?Data whitelist + veri haritası + retention/backup/log notuProduct Owner + IT/BT
DesignForm, consent, logging ve varsayılan ayarlar minimize edildi mi?UI mockup + consent modeli + logging şemasıUX + Product + IT/BT
DevRBAC/MFA, şifreleme, redaction, secrets ve consent tetikleme uygulandı mı?Teknik kontrol seti + kod/config çıktılarıDev + DevOps
TestConsent, log, export ve test verisi kontrolleri gerçekten çalışıyor mu?Privacy test sonuçları + release checklistQA + Dev
ReleasePrivacy smoke test geçti mi ve post-release review planlandı mı?Release onayı + 30–90 gün review takvimiProduct + QA + IT/BT

7. Ürün & Web Geliştirme İçin Privacy by Design Checklist Şablonunu İndir

CHECKLISTv1.0Checklist + Sprint

Ü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?

  1. Her aşamada sorulacak KVKK sorularını ve çıktıları doldur.
  2. Sprint başına en az 1 privacy task planla (backlog etiketi).
  3. 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

Checklist Şablonunu İndir Ücretsiz • PDF / Excel
Ürün yaşam döngüsüne gömülü privacy timeline diyagramı, SDLC KVKK
Ürün yaşam döngüsüne gömülü privacy timeline diyagramı, SDLC KVKK
Privacy by design checklist kartı, sprint ve release KVKK kontrolleri
Privacy by design checklist kartı, sprint ve release KVKK kontrolleri

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?
Privacy by design gizliliği tasarıma en baştan entegre etmektir; privacy by default varsayılan ayarların minimum veri ve minimum paylaşım olacak şekilde güvenli gelmesidir.
Web/ürün geliştirme sürecine KVKK’yı nasıl gömerim?
Discovery→design→dev→test→release aşamalarına KVKK soruları ve çıktıları içeren checklist koyun; release öncesi smoke test, sonrası periyodik review çalıştırın.
Form, log ve izin kararlarını hangi aşamada almalıyım?
Design aşamasında. Çünkü UX (form/izin) ve teknik (logging) birlikte tasarlanmadığında dev’de gereksiz veri ve geniş loglar oluşur.
Otel ve B2B için örnek privacy by design adımları neler?
Discovery’de veri whitelist; design’da KVKK uyumlu form/consent; dev’de RBAC+şifreleme+log redaction; test’te consent/log kontrolleri; release sonrası privacy review ve sprint privacy task’ları.
Ürünü bitirdikten sonra değil, baştan KVKK’ya uygun tasarlamak istiyorum, nasıl yaparım?
Her aşamaya bir privacy gate ekleyin ve “Definition of Done” içine KVKK maddeleri koyun; her sprintte küçük privacy görevleri planlayın.
En sık yapılan hata nedir?
KVKK’yı test veya release sonuna bırakmak; log/consent kararlarını tasarım aşamasında sabitlememektir.
Privacy by Design: SDLC’ye KVKK Checklist’i | DGTLFACE