[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-post-veri-analizi-ve-raporlamada-mahremiyet-abd-uyumlulugu-rehberi":3},{"dataItem":4,"heading":36,"metaData":38,"schema":81},["Reactive",5],{"id":6,"title":7,"summary":8,"content":9,"seo_title":10,"seo_description":11,"seo_keywords":12,"slug":13,"createdAt":14,"updatedAt":14,"blog_categories":15,"authors":19,"image":24,"thumb":25,"image_webp":26,"thumb_webp":27,"rating":28,"heading_title":7,"heading_sub_title":17,"readingTime":29,"url":34,"comments":35,"meta_cover":24},21248,"Veri Analizi ve Raporlamada Mahremiyet: ABD Uyumluluğu Rehberi","Bu rehber, ABD’de veri analizi ve raporlama yaparken mahremiyet uyumluluğunu (özellikle Kaliforniya CCPA/CPRA ve sağlık verilerinde HIPAA) pratik bir çerçeveyle ele alır. Veri envanteri, amaç sınırlaması, saklama, tüketici hakları talepleri, tedarikçi yönetimi, risk değerlendirmesi ve de-identification/PET yaklaşımları için uygulanabilir kontrol listeleri sunar.","\u003Ch2>Bu rehber kimin için ve neyi çözer?\u003C/h2>\n\u003Cp>ABD pazarında faaliyet gösteren (ya da ABD’de kullanıcıları olan) ekipler için veri analizi ve raporlama çoğu zaman iki hedef arasında sıkışır: \u003Cstrong>iş değerini ölçmek\u003C/strong> ve \u003Cstrong>mahremiyeti korumak\u003C/strong>. Özellikle ürün analitiği, pazarlama raporlaması, müşteri başarı metrikleri, A/B testleri, BI panoları ve otomatik karar destek sistemleri büyüdükçe; veri akışlarının “uyumlu” olup olmadığı sorusu daha da karmaşık hale gelir.\u003C/p>\n\u003Cp>\u003Cstrong>Yazanın perspektifi:\u003C/strong> Bu içerik, \u003Cem>privacy engineering / analytics ops\u003C/em> bakış açısıyla; teknik ekiplerin süreç kurmasına yardımcı olacak şekilde hazırlanmıştır. Hukuki danışmanlık değildir.\u003C/p>\n\u003Cp>Kaliforniya düzenleyicisinin (CPPA) güncel düzenleme çalışmaları ve duyuruları için resmi sayfalar: \u003Ca href=\"https://cppa.ca.gov/regulations/ccpa_updates.html\">CPPA – CCPA Updates\u003C/a> ve özet duyuru: \u003Ca href=\"https://privacy.ca.gov/2025/09/california-finalizes-regulations-to-strengthen-consumers-privacy/\">privacy.ca.gov – Regulations duyurusu\u003C/a>. \u003Cstrong>Son kontrol:\u003C/strong> 7 Mart 2026.\u003C/p>\n\n\u003Chr>\n\n\u003Ch2>1) ABD’de “tek bir mahremiyet standardı” yok: kapsamı nasıl çizersiniz?\u003C/h2>\n\u003Cp>ABD’de mahremiyet rejimi çoğunlukla \u003Cstrong>eyalet bazlı\u003C/strong> ilerler ve belirli veri türleri için \u003Cstrong>sektörel\u003C/strong> kurallar bulunur. Bu nedenle veri analizi/raporlama uyumluluğunda ilk adım şudur: “Hangi kullanıcılar hangi eyaletlerde?” ve “Hangi veri türleri işleniyor?”\u003C/p>\n\n\u003Ch3>Kapsam notu (önemli): bu rehberin odağı\u003C/h3>\n\u003Cp>Bu yazı \u003Cstrong>Kaliforniya CCPA/CPRA + sağlık verisi varsa HIPAA\u003C/strong> odağında bir çerçeve sunar. Bununla birlikte ABD’de başka eyalet mahremiyet yasaları da (ör. farklı eyaletlerde farklı kurallar) devreye girebilir. Eyalet farklılıklarını ele almak için önce bu bölümdeki “kapsam” adımını netleştirip, ardından kendi kullanıcı/coğrafya dağılımınıza göre hukuk danışmanlığıyla çerçeveyi genişletin.\u003C/p>\n\n\u003Ch3>Pratik başlangıç: 3 soruluk kapsam testi\u003C/h3>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Hangi veri sınıfları var?\u003C/strong> (ör. hesap verileri, cihaz/çerez verileri, konum, ödeme, sağlık verisi)\u003C/li>\n  \u003Cli>\u003Cstrong>Bu veriler hangi amaçla işleniyor?\u003C/strong> (ürün geliştirme, güvenlik, pazarlama ölçümü, finans raporu vb.)\u003C/li>\n  \u003Cli>\u003Cstrong>Paylaşım var mı?\u003C/strong> (bulut sağlayıcı, analitik SDK’sı, reklam/ölçüm ortakları, veri zenginleştirme, danışmanlık)\u003C/li>\n\u003C/ul>\n\u003Cp>Bu üç soru, hem CCPA/CPRA kapsamındaki tüketici haklarını süreçlerinize yerleştirmek hem de HIPAA gibi sektörel çerçevelere temas edip etmediğinizi görmek için temel bir harita oluşturur.\u003C/p>\n\n\u003Chr>\n\n\u003Ch2>2) Kaliforniya (CCPA/CPRA) odağında analitik için kritik beklentiler\u003C/h2>\n\u003Cp>Kaliforniya’daki CCPA/CPRA çerçevesi, analitik ve raporlamayı doğrudan etkileyen iki büyük alana temas eder: (1) \u003Cstrong>tüketici hakları ve şeffaflık\u003C/strong>, (2) \u003Cstrong>yönetişim ve risk temelli kontroller\u003C/strong>. CPPA’nın resmi “güncellemeler / rulemaking” derlemesi için: \u003Ca href=\"https://cppa.ca.gov/regulations/ccpa_updates.html\">CPPA düzenleme güncellemeleri\u003C/a>.\u003C/p>\n\n\u003Ch3>2.1 Analitik akışlarında “hak yönetimi”ni unutmayın\u003C/h3>\n\u003Cp>Analitik olayları (event), kullanıcı kimlikleri, cihaz tanımlayıcıları ve raporlama çıktılarını ayrı sistemlerde tutmak yaygındır. Ancak pratikte tüketici talepleri (erişim/silme/opt-out benzeri) geldiğinde, bu taleplerin \u003Cstrong>analitik boru hattına\u003C/strong> da yansıması beklenir. Uygulama ve uyum vurgularını resmi kaynaklardan izlemek için örnek: \u003Ca href=\"https://oag.ca.gov/news/press-releases/data-privacy-day-attorney-general-bonta-focuses-surveillance-pricing-compliance\">California DOJ – CCPA uyumu vurgusu\u003C/a>.\u003C/p>\n\n\u003Ch4>Uygulanabilir kontrol listesi: analitik için “hak talebi” tasarımı\u003C/h4>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Kimlik eşleme stratejisi:\u003C/strong> Silme talebini event depolarına ve yedekleme/arşiv katmanlarına nasıl yayacaksınız?\u003C/li>\n  \u003Cli>\u003Cstrong>Downstream etkisi:\u003C/strong> Silinen verinin raporlara etkisi nasıl açıklanacak? (ör. geçmiş dönem raporlarının yeniden hesaplanmaması gibi durumlarda politika netliği)\u003C/li>\n  \u003Cli>\u003Cstrong>Paydaşlar:\u003C/strong> Üçüncü taraf analitik/ölçüm sağlayıcılarına talep iletimi ve doğrulaması nasıl yapılacak?\u003C/li>\n  \u003Cli>\u003Cstrong>Kanıt:\u003C/strong> Talep işleme logları ve süreç dokümantasyonu nerede tutulacak?\u003C/li>\n\u003C/ul>\n\n\u003Ch4>Somut örnek: DSAR silme talebinin analitiğe yayılması (örnek akış)\u003C/h4>\n\u003Col>\n  \u003Cli>\u003Cstrong>Kimlik çözümleme:\u003C/strong> DSAR kimliğini (e-posta/hesap/cihaz) bir \u003Cem>identity graph\u003C/em> veya eşleme tablosu ile event-store’daki anahtarlarla ilişkilendirin.\u003C/li>\n  \u003Cli>\u003Cstrong>Silme kuyruğu:\u003C/strong> Event-store için “deletion queue” üretin (kayıt anahtarı, veri kaynağı, kapsam, tarih, talep ID).\u003C/li>\n  \u003Cli>\u003Cstrong>Uygulama:\u003C/strong> Ham event tablosunda ilgili kayıtları silin veya seçtiğiniz modele göre erişilemez hale getirin (ör. ayrı bir “tombstone” tablosu + sorguda filtreleme).\u003C/li>\n  \u003Cli>\u003Cstrong>Downstream politika:\u003C/strong> Türetilmiş tablolarda/feature store’da yeniden hesaplama yapacak mısınız, yoksa raporların geçmiş değerleri korunacak mı? Bu kararı yazılı politika haline getirin.\u003C/li>\n  \u003Cli>\u003Cstrong>Üçüncü taraf iletim:\u003C/strong> Varsa analitik/ölçüm tedarikçilerine talebi iletin ve kapanış kanıtını saklayın.\u003C/li>\n  \u003Cli>\u003Cstrong>Denetim izi:\u003C/strong> “Kim, ne zaman, hangi sistemde, hangi kapsamda” işlendiğini gösteren log + sonuç kaydı üretin.\u003C/li>\n\u003C/ol>\n\u003Cp>\u003Cem>Not:\u003C/em> Bu akış bir “uygulama örneğidir”; işletmenizin mimarisi ve hukuki değerlendirmesine göre uyarlanmalıdır.\u003C/p>\n\n\u003Ch3>2.2 CPPA düzenleme güncellemeleri (rulemaking): risk değerlendirmeleri, siber güvenlik denetimleri ve ADMT\u003C/h3>\n\u003Cp>CPPA’nın “CCPA Updates” sayfasında; \u003Cstrong>risk değerlendirmeleri\u003C/strong>, \u003Cstrong>siber güvenlik denetimleri\u003C/strong> ve \u003Cstrong>otomatik karar verme teknolojileri (ADMT)\u003C/strong> gibi başlıklar, düzenleme güncellemeleri kapsamında ele alınır. Bu başlıklar; segmentasyon, skorlamaya dayalı hedefleme, dolandırıcılık önleme, dinamik fiyatlama, otomatik erişim kararları veya benzeri otomasyonlar kullanan analitik ekipler için özellikle önemli olabilir. Resmi başlıklar ve durum için: \u003Ca href=\"https://cppa.ca.gov/regulations/ccpa_updates.html\">CPPA – Updates\u003C/a> ve duyuru özeti: \u003Ca href=\"https://privacy.ca.gov/2025/09/california-finalizes-regulations-to-strengthen-consumers-privacy/\">privacy.ca.gov\u003C/a>.\u003C/p>\n\u003Cp>\u003Cstrong>Dil hassasiyeti:\u003C/strong> Bu bölüm, \u003Cem>CPPA’nın düzenleme güncellemelerinde ele aldığı alanları\u003C/em> işaret eder. Hangi gerekliliklerin işletmenize uygulanacağı; rolünüze (işleyen/sağlayıcı vb.), veri türlerine, kullanım durumuna ve nihai düzenleyici metinlere bağlıdır.\u003C/p>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Ne zaman hukuk danışmanlığı gerekir?\u003C/strong> ADMT/otomasyon çıktıları bireyler için anlamlı sonuçlar doğuruyorsa (örn. erişim, fiyat, uygunluk, risk skorlaması gibi), ayrıca “yüksek risk” olarak sınıflandırılabilecek veri/amaçlar kullanılıyorsa; hem düzenleyici metinlerin güncelliği hem de kapsam analizi için hukuk/uyum ekibiyle birlikte ilerleyin.\u003C/p>\n\u003C/blockquote>\n\n\u003Ch4>Pratik yaklaşım: “Mini DPIA” ile başlayın\u003C/h4>\n\u003Cp>Kurumsal ölçekte bir risk değerlendirmesi tasarlamadan önce, analitik projeler için hafif ama disiplinli bir değerlendirme şablonu kullanabilirsiniz:\u003C/p>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Amaç:\u003C/strong> Hangi iş sorusu yanıtlanıyor? Aynı sonucu daha az veriyle elde edebilir misiniz?\u003C/li>\n  \u003Cli>\u003Cstrong>Veri minimizasyonu:\u003C/strong> Hangi alanlar zorunlu, hangileri “güzel olur” seviyesinde?\u003C/li>\n  \u003Cli>\u003Cstrong>Hassasiyet:\u003C/strong> Sağlık, finans, çocuklara ilişkin veya konum gibi kategoriler var mı?\u003C/li>\n  \u003Cli>\u003Cstrong>Paylaşım:\u003C/strong> Veri kimlerle paylaşılıyor, hangi sözleşme ve teknik kontrollerle?\u003C/li>\n  \u003Cli>\u003Cstrong>Otomasyon etkisi:\u003C/strong> Çıktılar kişi bazında karar/sonuç doğuruyor mu? İtiraz/inceleme mekanizması var mı?\u003C/li>\n  \u003Cli>\u003Cstrong>Güvenlik:\u003C/strong> Erişim kontrolü, şifreleme, loglama, ayrıcalık minimizasyonu, anahtar yönetimi.\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>3) HIPAA varsa oyun değişir: “de-identification” iki yolla olur\u003C/h2>\n\u003Cp>Sağlık verisi ile temas eden analitik ve raporlama projelerinde HIPAA kapsamı gündeme gelebilir. HIPAA altında “de-identification” için HHS/OCR iki temel yaklaşımı tanımlar: \u003Cstrong>Safe Harbor\u003C/strong> ve \u003Cstrong>Expert Determination\u003C/strong>. Resmi rehber: \u003Ca href=\"https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/coveredentities/De-identification/hhs_deid_guidance.pdf\">HHS/OCR – Guidance on De-identification of PHI (PDF)\u003C/a>.\u003C/p>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Ne zaman uzman/hukuk desteği gerekir?\u003C/strong> PHI içerebilecek verilerle çalışıyorsanız, “de-identified” iddiasını sözleşme, dış paylaşım veya ürün vaadi haline getiriyorsanız ya da yeniden tanımlama riski yüksek (yüksek boyutlu, az örneklemli, konum/zaman hassas) veri setleri kullanıyorsanız; HIPAA kapsam analizi ve (gerekiyorsa) \u003Cem>Expert Determination\u003C/em> için nitelikli uzman ve hukuk danışmanlığıyla ilerleyin.\u003C/p>\n\u003C/blockquote>\n\n\u003Ch3>3.1 Safe Harbor: 18 tanımlayıcı öğenin kaldırılması\u003C/h3>\n\u003Cp>Safe Harbor yaklaşımı, belirli doğrudan tanımlayıcıların kaldırılmasını ve kalan veride kişinin makul biçimde tanımlanamayacağının hedeflenmesini esas alır. Hangi öğelerin kapsamda olduğuna ve nasıl ele alınacağına dair en doğru referans, HHS/OCR belgesidir.\u003C/p>\n\n\u003Ch3>3.2 Expert Determination: istatistiksel/uzman temelli düşük risk gösterimi\u003C/h3>\n\u003Cp>Expert Determination yaklaşımında, nitelikli bir uzman/uzmanlık yöntemi ile yeniden tanımlama riskinin “çok düşük” olduğuna ilişkin değerlendirme yapılır ve yöntem dokümante edilir. Bu yaklaşım, özellikle yüksek boyutlu veri setlerinde veya coğrafi/zaman bilgisi gibi alanların analitik değeri yüksek olduğunda gündeme gelir. Ayrıntı için: \u003Ca href=\"https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/coveredentities/De-identification/hhs_deid_guidance.pdf\">HHS/OCR de-identification rehberi\u003C/a>.\u003C/p>\n\n\u003Ch4>Analitik ekipler için uyarı\u003C/h4>\n\u003Cp>De-identification “tek seferlik” bir işlem olarak düşünülmemelidir. Veri birleştirme, yeni harici veri kaynakları, farklı sorgu arayüzleri veya farklı kullanıcı rollerinin erişimi, yeniden tanımlama riskini değiştirebilir. Bu nedenle teknik önlem kadar \u003Cstrong>yönetişim ve yaşam döngüsü\u003C/strong> yönetimi de kritiktir.\u003C/p>\n\n\u003Chr>\n\n\u003Ch2>4) De-identification ve anonimlikte NIST bakışı: teknik + yönetişim birlikte\u003C/h2>\n\u003Cp>NIST, de-identification sürecine teknik yöntemlerin yanında \u003Cstrong>yönetişim, disclosure review\u003C/strong> ve yaşam döngüsü yaklaşımıyla bakar. Özellikle kamu veri setlerinin paylaşımı bağlamında hazırlanan NIST SP 800-188, organizasyonların risk yönetimi, gözden geçirme yapıları ve süreç tasarımına dair pratik çerçeveler sunar: \u003Ca href=\"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-188.pdf\">NIST SP 800-188 (PDF)\u003C/a>.\u003C/p>\n\n\u003Ch3>4.1 Neden “sadece maskeleme” yeterli bir strateji olmayabilir?\u003C/h3>\n\u003Cp>Analitik veri setleri çoğu zaman yüksek boyutludur: zaman damgaları, yaklaşık konum, cihaz özellikleri, davranış kalıpları gibi alanlar bir araya geldiğinde kişi bazında eşsiz desenler oluşabilir. NIST’in yaklaşımı, bu riskleri tek bir teknikle “kapatmak” yerine şu üçlüyle yönetmeye uygundur:\u003C/p>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Veri dönüşümü teknikleri\u003C/strong> (genelleştirme, baskılama, örnekleme vb.)\u003C/li>\n  \u003Cli>\u003Cstrong>Erişim ve kullanım kontrolleri\u003C/strong> (rol bazlı erişim, sorgu kısıtları, sözleşmesel kullanım sınırları)\u003C/li>\n  \u003Cli>\u003Cstrong>Gözden geçirme ve hesap verebilirlik\u003C/strong> (disclosure review süreçleri, periyodik yeniden değerlendirme)\u003C/li>\n\u003C/ul>\n\n\u003Ch3>4.2 Analitik raporlar için “risk bazlı yayın” yaklaşımı\u003C/h3>\n\u003Cp>Bir dashboard’u şirket içinde paylaşmakla, müşterilere rapor sunmak veya harici araştırmacılara veri açmak aynı risk seviyesinde değildir. Aşağıdaki basit matris ekiplerin kararını hızlandırır:\u003C/p>\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Yayın senaryosu\u003C/th>\n      \u003Cth>Tipik risk\u003C/th>\n      \u003Cth>Önerilen kontroller\u003C/th>\n    \u003C/tr>\n  \u003C/thead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>İç raporlama (dar ekip)\u003C/td>\n      \u003Ctd>Orta\u003C/td>\n      \u003Ctd>Rol bazlı erişim, amaç sınırlaması, denetim logu\u003C/td>\n    \u003C/tr>\n    \u003Ctr>\n      \u003Ctd>Müşteriye/iş ortağına rapor\u003C/td>\n      \u003Ctd>Orta–yüksek\u003C/td>\n      \u003Ctd>Sözleşmesel kısıtlar, agregasyon eşikleri, yeniden tanımlama risk değerlendirmesi\u003C/td>\n    \u003C/tr>\n    \u003Ctr>\n      \u003Ctd>Ham/veri seti paylaşımı\u003C/td>\n      \u003Ctd>Yüksek\u003C/td>\n      \u003Ctd>De-identification planı, disclosure review, erişim modeli (ör. güvenli ortam), periyodik yeniden değerlendirme\u003C/td>\n    \u003C/tr>\n  \u003C/tbody>\n\u003C/table>\n\n\u003Chr>\n\n\u003Ch2>5) PETs: Differential privacy ve sentetik veri ne zaman gündeme gelir?\u003C/h2>\n\u003Cp>Privacy-enhancing technologies (PETs) ailesinde sık tartışılan iki yaklaşım: \u003Cstrong>differential privacy\u003C/strong> ve \u003Cstrong>sentetik veri\u003C/strong>. Bunlar, doğru tasarlanırsa analitik faydayı korurken mahremiyet risklerini azaltmaya yardımcı olabilir; ancak her ikisi için de parametre seçimi, doğrulama ve fayda kaybı gibi pratik zorluklar vardır. Genel çerçeve ve sınırlamalar üzerine sektör perspektifi için: \u003Ca href=\"https://www.deloitte.com/content/dam/assets-zone2/de/de/docs/about/2024/Deloitte_Trustworthy_AI_Differential_Privacy_April24.pdf\">Deloitte – Differential Privacy and Synthetic Data (PDF)\u003C/a>; literatür derlemesi için: \u003Ca href=\"https://arxiv.org/abs/2503.20846\">arXiv – Synthetic Data with Formal Privacy Guarantees (survey)\u003C/a>.\u003C/p>\n\n\u003Ch3>5.1 Differential privacy: raporlama çıktılarında mahremiyet bütçesi fikri\u003C/h3>\n\u003Cp>Differential privacy yaklaşımı çoğunlukla \u003Cem>çıktı düzeyinde\u003C/em> koruma sağlar: rapor sonuçlarına kontrollü gürültü ekleme veya sorgu mekanizmasını mahremiyet garantisiyle tasarlama gibi. Uygulamada iki pratik soru öne çıkar:\u003C/p>\n\u003Cul>\n  \u003Cli>\u003Cstrong>“Ne yayınlıyoruz?”\u003C/strong> KPI’lar mı, kohort tabloları mı, segment bazlı dönüşümler mi?\u003C/li>\n  \u003Cli>\u003Cstrong>“Hata toleransımız ne?”\u003C/strong> Pazarlama optimizasyonu ile finans raporlamasının toleransı aynı değildir.\u003C/li>\n\u003C/ul>\n\u003Cp>Bu nedenle differential privacy çoğu ekipte “hemen her yerde” değil, belirli rapor türlerinde (ör. dışa açık istatistikler, düşük örneklemli kesitler) daha anlamlı bir seçenek olabilir.\u003C/p>\n\n\u003Ch3>5.2 Sentetik veri: test, geliştirme ve paylaşım senaryolarında\u003C/h3>\n\u003Cp>Sentetik veri, gerçek verinin istatistiksel özelliklerini yansıtan ancak gerçek kişilere doğrudan bağlı olmayan bir veri seti üretmeyi hedefler. Bunun analitik ekiplere faydası çoğu zaman şuralarda görülür:\u003C/p>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Geliştirme/test:\u003C/strong> Üretim verisine erişmeden pipeline ve dashboard doğrulama.\u003C/li>\n  \u003Cli>\u003Cstrong>Eğitim ve demo:\u003C/strong> Müşteriye veya iç ekibe gerçek kişileri göstermeden ürün anlatımı.\u003C/li>\n  \u003Cli>\u003Cstrong>Paylaşım kısıtları:\u003C/strong> Ham verinin paylaşılamadığı iş ortaklığı senaryoları.\u003C/li>\n\u003C/ul>\n\u003Cp>Ancak sentetik verinin “otomatik olarak risksiz” olduğunu varsaymak doğru değildir; üretim yöntemi, saldırı modeli ve doğrulama yaklaşımı belirleyicidir. Ayrıntı ve sınırlamalar için: \u003Ca href=\"https://arxiv.org/abs/2503.20846\">arXiv survey\u003C/a>.\u003C/p>\n\n\u003Chr>\n\n\u003Ch2>6) Veri yönetişimi: analitiği yavaşlatmadan uyumlu hale getirme\u003C/h2>\n\u003Cp>Uyum çoğu zaman “tek seferlik bir proje” gibi görülür; oysa analitik dünyasında veri şemaları, event isimleri, SDK’lar ve rapor gereksinimleri sürekli değişir. Bu yüzden sürdürülebilir yaklaşım, \u003Cstrong>veri yönetişimini\u003C/strong> analitik yaşam döngüsüne entegre etmektir.\u003C/p>\n\n\u003Ch3>6.1 Minimum uygulanabilir yönetişim (MVG) çerçevesi\u003C/h3>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Veri envanteri:\u003C/strong> Event sözlüğü, alan tanımları, veri kaynakları, hedef sistemler.\u003C/li>\n  \u003Cli>\u003Cstrong>Sınıflandırma:\u003C/strong> Kişisel veri / hassas veri / de-identified veri / agregat rapor gibi etiketler.\u003C/li>\n  \u003Cli>\u003Cstrong>Saklama politikası:\u003C/strong> Ham event verisi ne kadar tutulur? Agregatlar ne kadar tutulur?\u003C/li>\n  \u003Cli>\u003Cstrong>Erişim modeli:\u003C/strong> Kim hangi seviyede görebilir? (ham, pseudonymous, agregat)\u003C/li>\n  \u003Cli>\u003Cstrong>Değişiklik yönetimi:\u003C/strong> Yeni bir event alanı eklendiğinde kim onaylar, hangi şablonla risk kontrolü yapılır?\u003C/li>\n\u003C/ul>\n\n\u003Ch3>6.2 Üçüncü taraflar: sözleşme + teknik kontrol birlikte\u003C/h3>\n\u003Cp>Analitik ve raporlama genellikle üçüncü taraflarla yürür: bulut veri ambarı, etiket yönetimi, ürün analitiği, müşteri veri platformları, danışmanlık vb. Kaliforniya çerçevesinde “paylaşım/satış” gibi kavramlar ve tüketici haklarının taşınması bağlamında sözleşme dili kritik olabilir. Bu nedenle, tedarikçi incelemesini hem sözleşmesel hem de teknik açıdan ele almak gerekir. Genel düzenleme bağlamı için CPPA duyurusu: \u003Ca href=\"https://privacy.ca.gov/2025/09/california-finalizes-regulations-to-strengthen-consumers-privacy/\">privacy.ca.gov\u003C/a>.\u003C/p>\n\n\u003Ch4>Tedarikçi değerlendirme soruları (kısa liste)\u003C/h4>\n\u003Cul>\n  \u003Cli>Veri işleyen/sağlayıcı rolü nedir ve bunu sözleşmede açıkça tanımlıyor mu?\u003C/li>\n  \u003Cli>Alt işleyiciler ve veri konumları (bölge/ülke) şeffaf mı?\u003C/li>\n  \u003Cli>Hak taleplerini (silme/erişim/opt-out) destekleyen teknik süreçleri var mı?\u003C/li>\n  \u003Cli>Güvenlik kontrolleri ve denetim raporları nasıl paylaşılır?\u003C/li>\n  \u003Cli>De-identification iddiası varsa: yöntem, varsayımlar ve yeniden tanımlama riskine yaklaşım dokümante mi?\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>7) Uygulama planı: 30 günde “daha uyumlu” analitik nasıl kurulur?\u003C/h2>\n\u003Cp>Aşağıdaki plan, büyük yeniden mimari gerektirmeden iyileştirme yapmaya yöneliktir. Kurum ölçeğine göre süreler değişebilir.\u003C/p>\n\n\u003Ch3>Hafta 1: Envanter ve akış haritası\u003C/h3>\n\u003Cul>\n  \u003Cli>En kritik 10 raporu ve beslendiği veri kaynaklarını listeleyin.\u003C/li>\n  \u003Cli>Bu raporların çıktısı kimlerle paylaşılıyor (iç/dış)?\u003C/li>\n  \u003Cli>Her rapor için veri sınıflandırması etiketi verin (kişisel/hassas/agregat).\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Hafta 2: Veri minimizasyonu ve saklama\u003C/h3>\n\u003Cul>\n  \u003Cli>Event şemasında “gereksiz” alanları işaretleyin; kaldırma ya da daha düşük hassasiyetle tutma seçeneklerini belirleyin.\u003C/li>\n  \u003Cli>Ham veri saklama süresini ve agregat saklama süresini yazılı hale getirin.\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Hafta 3: Hak talepleri ve tedarikçiler\u003C/h3>\n\u003Cul>\n  \u003Cli>Hak taleplerinin analitik depolara yansımasını test edin (ör. örnek bir silme talebi).\u003C/li>\n  \u003Cli>En çok veri alan 3 tedarikçi için sözleşme ve teknik süreç kontrolünü başlatın.\u003C/li>\n\u003C/ul>\n\n\u003Ch3>Hafta 4: Risk değerlendirmesi ve yayın kontrolleri\u003C/h3>\n\u003Cul>\n  \u003Cli>Yüksek riskli görünen 2 analitik kullanım durumu için mini risk değerlendirmesi dokümantasyonu oluşturun.\u003C/li>\n  \u003Cli>Küçük örneklemli segment raporları için agregasyon eşiği ve erişim kısıtları belirleyin.\u003C/li>\n  \u003Cli>Sağlık verisi varsa, HIPAA de-identification yolunu (Safe Harbor vs Expert Determination) netleştirin. Referans: \u003Ca href=\"https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/understanding/coveredentities/De-identification/hhs_deid_guidance.pdf\">HHS/OCR\u003C/a>.\u003C/li>\n\u003C/ul>\n\n\u003Chr>\n\n\u003Ch2>Son not: belirsizlikleri görünür kılın\u003C/h2>\n\u003Cp>Mahremiyet uyumu, “tamamlandı” diyerek bitirilen bir görev olmaktan çok, \u003Cstrong>sürekli iyileştirilen bir kontrol sistemi\u003C/strong>dir. Özellikle de-identification/anonimlik iddialarında ve otomatik karar süreçlerinde, teknik gerçeklik ile yasal beklentiler arasında gri alanlar oluşabilir. Bu gri alanları azaltmanın en güvenli yolu: (1) dokümantasyon, (2) risk bazlı karar, (3) gerektiğinde uzman ve hukuk danışmanlığı ile ilerlemektir.\u003C/p>\n\u003Cp>Kaliforniya düzenleme gündeminin en güncel özetleri için CPPA’nın resmi sayfasını düzenli kontrol edin: \u003Ca href=\"https://cppa.ca.gov/regulations/ccpa_updates.html\">CPPA – Updates\u003C/a>.\u003C/p>","Veri Analizi Mahremiyeti: ABD CCPA/CPRA ve HIPAA","ABD’de analitik ve raporlamada mahremiyet uyumu için pratik çerçeve: Kaliforniya CCPA/CPRA, DSAR yönetimi, HIPAA de-identification ve NIST temelli kontroller.","veri analizi, raporlama, mahremiyet uyumluluğu, CCPA, CPRA, CPPA, HIPAA, de-identification, veri yönetişimi, DSAR, risk assessment, cybersecurity audit, ADMT, differential privacy, sentetik veri","veri-analizi-ve-raporlamada-mahremiyet-abd-uyumlulugu-rehberi","2026-03-09T16:04:03.000Z",{"id":16,"title":17,"slug":18},598,"Veri Analizi ve Raporlama","veri-analizi-ve-raporlama",{"id":20,"name":21,"nickname":22,"slug":23},150,"Mine Akgül","CodeCraftswoman","mine-akgul","/media/blog/e28491143ab4682f10519fbbf3addafc.jpg","/media/blog/e28491143ab4682f10519fbbf3addafc_thumb.jpg","/media/blog/e28491143ab4682f10519fbbf3addafc.webp","/media/blog/e28491143ab4682f10519fbbf3addafc_thumb.webp",null,{"minutes":30,"wordCount":31,"imageCount":32,"formatted":33},10,1977,0,"10 dk okuma süresi","/blog/veri-analizi-ve-raporlama/veri-analizi-ve-raporlamada-mahremiyet-abd-uyumlulugu-rehberi",[],["Reactive",37],{"title":7,"subTitle":17,"image":24},["Reactive",39],{"title":10,"meta":40,"link":75},[41,43,45,48,51,54,57,60,63,66,69,71,73],{"hid":42,"name":42,"content":11},"description",{"hid":44,"name":44,"content":12},"keywords",{"hid":46,"name":46,"content":47},"author","Yazılım Rehberi",{"hid":49,"name":49,"content":50},"robots","index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1",{"hid":52,"property":52,"content":53},"og:type","website",{"hid":55,"property":55,"content":56},"og:title","Yazılım Rehberi: Blog ve Sosyal Medya İçin Yeni Yazılımlar",{"hid":58,"property":58,"content":59},"og:description","Blog yazarları ve sosyal medya içerik üreticileri için yeni yazılımlar, kullanım önerileri ve pratik rehberler sunan güncel bilgi blogu.",{"hid":61,"property":61,"content":62},"og:image","https://yeniyazilimlar.com/media/blog/e28491143ab4682f10519fbbf3addafc.jpg",{"hid":64,"property":64,"content":65},"og:url","https://yeniyazilimlar.com/blog/veri-analizi-ve-raporlama/veri-analizi-ve-raporlamada-mahremiyet-abd-uyumlulugu-rehberi",{"hid":67,"name":67,"content":68},"twitter:card","summary_large_image",{"hid":70,"name":70,"content":56},"twitter:title",{"hid":72,"name":72,"content":59},"twitter:description",{"hid":74,"name":74,"content":62},"twitter:image",[76,78],{"rel":77,"href":65},"canonical",{"rel":79,"href":80},"amphtml","https://amp.yeniyazilimlar.com/blog/veri-analizi-ve-raporlama/veri-analizi-ve-raporlamada-mahremiyet-abd-uyumlulugu-rehberi",["Reactive",82],{"@context":83,"@graph":84},"https://schema.org",[85,98],{"@type":86,"headline":10,"image":62,"author":87,"publisher":90,"datePublished":14,"dateModified":14,"mainEntityOfPage":96,"description":11},"BlogPosting",{"@type":88,"name":21,"url":89},"Person","https://yeniyazilimlar.com/yazarlar/mine-akgul",{"@type":91,"name":47,"logo":92},"Organization",{"@type":93,"url":94,"width":95,"height":95},"ImageObject","https://yeniyazilimlar.com/img/icons/favicon.png",32,{"@type":97,"@id":65},"WebPage",{"@type":99,"itemListElement":100},"BreadcrumbList",[101,106,110,113],{"@type":102,"position":103,"name":104,"item":105},"ListItem",1,"Ana Sayfa","https://yeniyazilimlar.com",{"@type":102,"position":107,"name":108,"item":109},2,"Blog","https://yeniyazilimlar.com/blog",{"@type":102,"position":111,"name":17,"item":112},3,"https://yeniyazilimlar.com/blog/veri-analizi-ve-raporlama",{"@type":102,"position":114,"name":7,"item":65},4]