GDPR talepleri için dışa aktarma, düzeltme ve silme iş akışı şablonu: roller, onaylar, süreler ve uygulamanız içinde saklayabileceğiniz tamamlanma kanıtı kayıtları.
Bir GDPR istek iş akışı, gizlilik taleplerini sakin bir şekilde ele almak ile her e-posta geldiğinde telaşlanmak arasındaki farktır. Kişiler kişisel verilerinin dışa aktarılmasını (erişim), düzeltilmesini (düzeltme) veya silinmesini (silme) isteyebilir. Bu tür talepler, profiller, mesajlar, siparişler, destek kayıtları veya analiz kimlikleri saklayan her uygulama için normaldir.
Gelişigüzel (ad hoc) işlemler hızla çöker. Bir istek birinin gelen kutusuna düşer, başkalarına iletilir ve manuel veritabanı kontrolleri ve ekran görüntülerine dönüşür. Son tarihler kaçırılır, yanlış kişinin verileri yanlışlıkla dışa aktarılabilir ve ekipler ana uygulama veritabanı dışında yaşayan verileri (e-posta araçları, ödeme sağlayıcıları veya loglar gibi) unutabilir. En büyük eksik genellikle aynıdır: ne yaptığınızı ve ne zaman yaptığınızı kanıtlayan açık bir denetim izi yoktur.
İyi tasarlanmış bir iş akışı talepleri öngörülebilir ve tekrarlanabilir kılar. Üç sonuç sağlamalıdır: hız (istek doğru sahiplerine son tarihler ve hatırlatmalarla yönlendirilir), doğruluk (dışa aktarma, düzeltme veya silme doğru sistemler genelinde tamamlanır) ve kanıt (onaylar, zaman damgaları ve etkilenen verilerle tamamlanma kanıtı gösterebilirsiniz).
Kapsam önemlidir. İş akışı uygulamanızdaki verileri (veritabanınız, dosyalar ve dahili yönetici araçları) ve uygulamanızın kullandığı bağlı sistemleri (ödeme sağlayıcıları, mesajlaşma, CRM, analiz, yedekler ve bulut depolama) kapsamalıdır. Basit bir örnek: bir kullanıcı silinme ister, ancak e-postası destek aracınızda hâlâ vardır ve müşteri kimliği Stripe'da kalmıştır. Tanımlı bir kapsam yoksa isteği “tamamladığınızı” düşünebilirsiniz ama yine de kişisel verileri tutuyor olursunuz.
Bu tür bir iş akışını AppMaster gibi bir platformda kuruyorsanız amaç, her istek türünü tutarlı adımlar, roller ve kaydedilmiş sonuçlarla eşleştirmektir; böylece uyum görevde kimin olduğuna bağlı olmaz.
Bir GDPR isteği, bir kişinin kişisel verileriyle ilgili sizden bir işlem yapmanızı istemesidir. Kişisel veri, doğrudan veya dolaylı olarak bir kişiyi tanımlayabilecek her bilgidir: ad, e-posta, cihaz kimliği veya destek bileti geçmişi gibi.
Basitçe söylemek gerekirse, bir kontrolör (veri sorumlusu) olabilirsiniz (verinin neden ve nasıl kullanılacağına karar veren) veya bir işleyen (veriyi başkası adına işleyen). Birçok uygulama özelliğe bağlı olarak her iki rolü de üstlenir, bu yüzden iş akışınız her istek için hangi rolün uygulandığını kaydetmelidir.
En yaygın istek türleri erişim (dışa aktarma), düzeltme ve silme (imha)dir. Bunları farklı yollar olarak ele alın; çünkü her birinin farklı riskleri ve saklamanız gereken farklı kanıtları vardır.
Çoğu isteğin bir yanıt süresi vardır ve zamanlayıcı genellikle isteği aldığınızda başlar, uygun olduğunda değil. İş akışınız tarihler gösterir olmalı: alındı, doğrulandı, kapsam belirlendi ve tamamlandı. Bu, kaçırılan son tarihlerden kaçınmanıza yardımcı olur ve daha sonra biri ne olduğunu sorduğunda temiz bir denetim izi sağlar.
Doğru kayıtları bulmak için yeterli bilgiyi istersiniz, fakat yeni bir gizlilik riski yaratacak kadar çok değil. Genellikle kimin istekte bulunduğunu (ve nasıl doğrulayacağınızı), ne istediklerini (dışa aktarma, düzeltme, silme), hangi hesap veya tanımlayıcıyı arayacağınızı ve yanıtı nereden teslim edeceğinizi (güvenli kanal) bilmeniz gerekir.
İstek belirsizse, tahmin etmek yerine açıklayıcı sorular sorun.
Bazen isteği sınırlayabilir veya reddedebilirsiniz; örneğin kimliği doğrulayamazsanız, istek tekrarlayıcıysa veya yasalar belirli kayıtları tutmanızı gerektiriyorsa (faturalar gibi). Yine de, ne karar verdiğinizi, nedenini ve bunun yerine ne yaptığınızı (kısmi silme veya sınırlı dışa aktarma gibi) kaydedin.
Her adımın isimlendirilmiş bir sahibi olduğunda GDPR istek iş akışı daha hızlı ve daha güvenli işler. Amaç basittir: bir kişi onaylar, farklı bir kişi uygular ve sonra ne olduğunu ispatlayabilirsiniz.
Şirketinizin zaten nasıl çalıştığına uyan küçük bir rol setiyle başlayın. Küçük ekiplerde aynı kişi birden fazla rolü üstlenebilir, ancak izinler yine de ayrılmış kalmalıdır.
Pratik bir RACI benzeri ayrım şöyle görünebilir:
Güvenlik genellikle yürütmekten ziyade danışılır. Kimlik kontrollerini tanımlamada, olağandışı kalıpları (tekrarlayan istekler gibi) incelemede ve dışa aktarılan verinin güvenli şekilde teslim edildiğini doğrulamaya yardımcı olurlar.
Yetki ayrımı silme için özellikle önemlidir. Silme düğmesine basabilen kişi bunu onaylayabilecek tek kişi olmamalıdır. Bu, hataları azaltır ve kötüye kullanım riskini düşürür.
Bekleyen isteklerin tıkanmasını önlemek için önceden kapsam ve devir planlayın: her rol için birinci ve yedek sahibini belirtin (tatiller olur), son tarihler risk altındaysa bir yükseltme noktası tanımlayın, her devrede durum notu zorunlu kılın ve zaman damgaları ile onayların bulunduğu tek bir vaka kaydı tutun.
Bunu dahili bir araç olarak (örneğin AppMaster içinde) kurarsanız rolleri izinli eylemler olarak modelleyin: kim onaylayabilir, kim uygulayabilir ve kim sadece görüntüleyebilir. Bu yapı iş akışını varsayılan olarak denetlenebilir kılar.
Giriş (intake) GDPR çalışmalarının başarılı olup olmamasını belirler. Talepler farklı yerlere geliyorsa ve ad hoc şekilde ele alınıyorsa zaman kaybedersiniz ve ne olduğuna dair temiz bir kayıt kaybedersiniz. Amaç, her istek için izlenen bir vaka, açık bir sahip, zaman damgaları ve tekrarlanabilir bir yol sağlamaktır.
Talepleri sınırlı sayıda kanaldan kabul edin, ancak hepsini aynı kuyruğa yönlendirin. Birçok ekip uygulama içi bir istek formu (hızlı ve yapılandırılmış), gizlilik e-posta gelen kutusu, destek bilet portalı ve ajanın kaydettiği telefon veya sohbet takibini kullanır (isteği sadece sesle ele almayın).
İstek uygulama içinden veya e-posta ile başlasa da aynı temel alanları yakalayın. Formu kısa tutun ama ekibinizin doğru hesabı bulmasını ve kişinin ne istediğini anlamasını sağlayacak kadar spesifik olsun. Faydalı giriş alanları: istek türü (dışa aktarma/erişim, düzeltme, silme), hesap tanımlayıcıları (kullanıcı ID, e-posta, telefon, müşteri numarası), teslimat hedefi (uygulama içi indirme, doğrulanmış e-posta cevabı, gerekliyse posta adresi), zaten sahip olduğunuz kimlik sinyalleri (son giriş tarihi, son sipariş ID, kaydedilmiş ödeme tokeninin son 4 hanesi vb.) ve serbest metin ayrıntılar.
İsteği aldığınız anda bir vaka oluşturun. “Bir istek = bir vaka” gibi bir kural kullanın ki daha sonra denetleyebilin. Ona benzersiz bir vaka kimliği verin (örneğin GDPR-2026-00128) ve kanal, alma zamanı, istek sahibi ayrıntıları ve sonraki adımın sahibi gibi bilgileri kaydedin.
Hızlı bir onay gönderin, hareket edemiyorsanız bile. Gerçekçi olun: vaka kimliğini doğrulayın, kimliği doğrulayacağınızı söyleyin ve gerçekçi bir zaman çizelgesi belirtin. “Her şeyi hemen sileceğiz” gibi sözlerden kaçının. Sonrasında ne olacağını, sizden ne gerektiğini (varsa) ve vaka kapandığında nasıl doğrulama yapacağınızı söyleyin.
Kimlik kontrolleri orantılı olmalıdır. Bir kişi oturum açılmış bir hesaptan profilinin bir kopyasını istiyorsa genellikle silme isteği gibi daha yüksek bir doğrulama seviyesine gerek yoktur. Silme gibi hesap, faturalar veya ekip çalışma alanlarını etkileyebilecek durumlarda daha sıkı kontroller gerekir.
İyi bir kural: sahip olduğunuz sinyalleri kullanarak doğrulayın, yeni hassas belgeler toplamayın.
En güvenli seçenekle başlayın: istekte bulunan kişinin zaten bildiğiniz hesabı kontrol ettiğini onaylayın.
Bu, yeni bir hassas kimlik belgesi yığını oluşturup onun da korunması, saklama kuralları ve ihlal yanıtı gerektirmesini engeller.
Bazen bir avukat, ebeveyn veya başka bir yetkili temsilci istekte bulunur. İki şey isteyin: veri sahibinin kimliğinin kanıtı (yukarıdaki minimal yaklaşımla) ve yetki kanıtı.
Uygulamada bu genellikle veri sahibinden imzalı bir yetkilendirme ve bunu doğrulayacak bir yol (örneğin hesapta kayıtlı e-postadan yanıt) anlamına gelir. Temsilci aynı kuruluşun bir parçasıysa (örneğin bir çalışan için hareket eden bir yönetici) iç politikayı belgeleyin ve yöneticinin neyi talep edebileceğini sınırlayın.
Kimlik doğrulanamıyorsa isteği hemen işlemeyin. İhtiyacınız olan minimum ek ayrıntıyı isteyin, iş akışını duraklatın ve her adımı kaydedin (ne istediniz, ne zaman istediniz ve ne aldınız). Doğrulama artefaktlarını işlem tamamlandığında silin.
Kimse verileri dışa aktarmadan, düzenlemeden veya silmeden önce bir ön inceleme adımı gerekir. Çoğu sorun burada önlenir: atlanmış sistemler, yanlış istek türü veya ne istendiğini tam bilmeden işe başlanması.
Kapsamı sade bir dille yazın. Üç soruyu cevaplayın: hangi veriler, nerede saklandıkları ve hangi zaman dilimi ilgili. Ayrıca herhangi bir işlemi durdurmanız veya sınırlamanız gerektiren bir durum (açık bir ihtilaf, dolandırıcılık soruşturması veya yasal tutma) olup olmadığını kontrol edin.
Basit bir ön inceleme kontrol listesi şunları kapsar: kişinin ne istediği (erişim/dışa aktarma, düzeltme, silme veya karışık), hangi sistemlerde verisinin olabileceği (uygulama veritabanı, destek gelen kutusu, faturalama, analiz), hangi tanımlayıcıları kullanacağınız (e-posta, kullanıcı ID, telefon, sipariş numarası), hangi zaman aralığının uygulanacağı (tüm zamanlar mı yoksa belirli bir dönem mi) ve herhangi bir kısıtlama (yasal tutma, paylaşılan hesap veya başka bir kişiyi etkileyen veriler).
Karışık istekleri erken sınıflandırın. “Verilerimi gönderin ve sonra hesabımı silin” iki ayrı takip çıktısına dönüşmelidir: bir veri paketi ve bir silme işlemi; her biri kendi onayı ve kanıtıyla takip edilir.
Elle inceleme gerekip gerekmediğine karar verin. Tetikleyiciler arasında hassas veriler, paylaşılan hesaplar (aile veya ekip girişleri), başka insanları içeren kayıtlar veya dahili notları ifşa edebilecek herhangi bir şey bulunur. Bu durumlarda, hiçbir şeyi göndermeden veya silmeden önce bir inceleyici adımı ekleyin.
İç son tarihler ve yükseltme noktaları belirleyin. GDPR zaman çizelgeleri sıkıdır, bu yüzden kısa iç hedefler koyun (örneğin ön inceleme 2 iş günü içinde) ve vaka tıkandığında kimlerin bilgilendirileceğini tanımlayın.
Örnek: bir kullanıcı silme istiyor, ancak ön inceleme faturalarda açık faturalar ve diğer müşterileri bahseden destek kayıtları buluyor. Yine de ilerleyebilirsiniz, ancak muhtemelen kısmi silme, finans kayıtlarının saklanması ve belgelenmiş bir inceleyici onayı gerekecektir. AppMaster gibi araçlarda durum değişiklikleri, onaylar ve tamamlanma notlarının tek bir yerde yakalanması bunu yönetmeyi kolaylaştırır.
İyi bir erişim isteği akışı “tüm verileri dökme” meselesi değildir. Önemli olan daha sonra tam olarak ne aradığınızı, neyi teslim ettiğinizi ve nedenini açıklayabilmektir.
Öncelikle (ve güncel tutarak) basit bir kullanıcı veri haritası oluşturun. Bir kullanıcı için verilerinin nerede olabileceğini listeleyin: temel profil tabloları, siparişler ve faturalar, destek kayıtları, sohbet mesajları, yüklenen dosyalar, denetim olayları ve kapsam olarak belirlediğiniz loglar. Üçüncü taraf sistemleri de dahil edin (örneğin ödeme sağlayıcı kayıtları) ki panik anında unutmayın.
Ardından dışa aktarmayı öngörülebilir bir sırayla yürütün:
Örnek: bir müşteri dışa aktarma istedi, ancak destek notlarında başka bir müşteri adı geçiyor. Bu notu diğer kişinin tanımlayıcıları kaldırılmış şekilde dahil edin ve neden kırpma yapıldığını kaydedin.
AppMaster içinde bunu oluşturuyorsanız dışa aktarma oluşturma ve gönderim onayını ayrı adımlar olarak ele alın. Bu, ikinci bir göz eklemeyi kolaylaştırır ve ne zaman ne teslim edildiğini göstermek gerektiğinde daha temiz kayıtlar sağlar.
Bir düzeltme isteği, bir kişinin hakkındaki bazı verilerin yanlış olduğunu söyleyip düzeltilmesini istemesidir. Amaç, düzeltilmesi gerekenleri düzeltmek, tarihi kanıt olması gereken kayıtları sessizce yeniden yazmamak.
Uygulamanızda “düzeltme”nin neyi kapsadığını belirleyin. Yaygın örnekler profil alanları (ad, e-posta, adres), hesap ayarları ve tercihlerdir. Kullanıcı tarafından oluşturulan içerik (örneğin bir yorumdaki görüntüleme adı) ve bazı işlem meta verileri (yanlış bir gönderim telefon numarası gibi) de olabilir. Finansal ve denetim kayıtlarına ekstra özen gösterin.
Onay kuralları desteği hızlı ama güvenli tutar. Pratik bir ayrım: destek düşük riskli profil alanlarını (yazım hataları, biçimlendirme) temel kontroller sonrası düzeltebilir; kimlik alanları veya faturalama ve erişimle bağlantılı olanlar için veri sahibi veya gizlilik lideri onay verir; çekirdek işlem tablolarını veya entegrasyonları etkileyen düzeltmeleri mühendislik inceler.
Denetim izi eski değeri, yeni değeri, nedeni, değişikliği yapanı, zamanı ve hangi isteğe ait olduğunu yakalamalıdır. AppMaster kullanıyorsanız bunu Data Designer içinde özel bir “Düzeltme Günlüğü” tablosu olarak modelleyebilir ve Business Process Editor ile onayları zorunlu kılabilirsiniz.
Doğruluk konusunda bir anlaşmazlık varsa her iki pozisyonu da kaydedin ve değişikliği araştırırken beklemeye alın. Ayrıca geçmişte kalması gereken kayıtları yeniden yazmaktan kaçının (faturalar, güvenlik logları). Bunun yerine tarihi doğru tutarken mevcut verinin doğru olmasını sağlamak için düzeltici bir girdi veya anotasyon ekleyin.
Bir GDPR silme isteği basit görünür, ta ki bağımlılıklarla karşılaşana kadar: saklamanız gereken faturalar, silinmemesi gereken dolandırıcılık sinyalleri veya diğer kişileri anan destek kayıtları. Silmeyi kontrol edilen bir iş olarak ele alın; net karar noktaları ve bir evrak izi olmalı.
Sakladığınız verilere ve yerine getirmek zorunda olduğunuz yasal yükümlülüklere göre üç sonuçtan birini seçin:
Bu durumu vaka dosyasına yazın, özellikle tam silemiyorsanız nedenini belirtin.
Kullanıcının verilerini, yaklaşımı engelleyebilecek veya değiştirebilecek sistemlere eşleyin: ödemeler ve faturalar, dolandırıcılık önleme bayrakları, destek geçmişi, ürün analizleri, e-posta ve SMS logları ve dosya yüklemeleri.
Bir ödeme kaydının saklanması gerekiyorsa, kullanıcı profili anonimleştirilirken faturayı minimal alanlarla tutabilirsiniz. Destek geçmişi için isimleri ve e-postaları sansürleyip konuşmayı kalite için saklamayı düşünebilirsiniz.
Tamamlanma kanıtı sağlayabilmek için adımları tutarlı tutun:
AppMaster içinde bunu bir iş süreci (Business Process) olarak ele alıp açık durumlar, onaylar ve yeniden denenebilir görevler oluşturun.
Üçüncü taraflara (ödeme, mesajlaşma, analiz) silme talimatları gönderin ve onların onaylarını kaydedin. Tamamlanma kanıtını saklayın: iş günlükleri, zaman damgaları, operatör veya otomasyon ID'si ve neyin silindiğini, anonimleştirildiğini veya saklandığını ve nedenini listeleyen kapanış notu.
Çoğu uyum hatası kötü niyet sonucu olmaz. E-posta dizileri, sohbet mesajları ve hızlı çözümler arasında iş dağıldığı için oluşur.
İlk tuzak tek bir vaka kimliğinin olmamasıdır. Tek bir vaka kaydı olmadan kimin ne istediğini, kimlik doğrulamasını ne zaman yaptığınızı, ne yaptığınızı ve ne zaman bitirdiğinizi gösteremezsiniz.
İkinci yaygın hata onayların eksikliğidir. Aynı kişi onaylayıp uygulayabiliyorsa hata fark edilmeden geçebilir. Hafif bir iki kişilik kontrol bile, özellikle silme ve dışa aktarmalarda fayda sağlar.
Silme iki yönde başarısız olabilir. Aşırı silme, güvenlik, dolandırıcılık önleme veya yasal ve muhasebe kayıtları için tutmanız gereken verileri gözden geçirmeden silmektir. Eksik silme ise daha yaygındır: ana veritabanı satırını silip ek dosyaları, logları, analiz olaylarını, arama dizinlerini, önbellekleri ve veriyi sonradan yeniden oluşturabilecek arka plan işlerlerini unutmak.
Dışa aktarmalar da risklidir. Birçok yerden veri çekmek küçük birleşim hatalarıyla başka bir kullanıcının verisini ekleyebilir. Dahili notlar sıkça sorun olur: “şüpheli dolandırıcılık” veya “VIP indirimi” gibi iç notlar, sadece personele yönelik olmalarına rağmen dışa aktarımda yer alabilir.
Örnek: bir destek temsilcisi bir müşteri için “tüm ticketları” dışa aktarır, ancak dışa aktarma sorgusu paylaşılan gelen kutusundan veya birleştirilmiş bir iletişim kaydından gelen mesajları da içerir. Bu, “yardımcı bir kestirme” yüzünden yaratılan bir gizlilik olayıdır.
Çoğu hattı önleyen koruyucular basittir: her eylemi tek bir vaka kimliği altında kaydetmek, alım, onay ve yürütme rollerini ayırmak, veri haritası tutmak (tablolar, dosyalar, loglar, arama, önbellekler, asenkron işler), kapsamlı dışa aktarma şablonları kullanmak ve denemeleri sahte/dummy hesaplarla test etmek, ayrıca tamamlanma kanıtlarını (ne değiştirildi veya silindi, kim tarafından ve ne zaman) kaydetmektir.
AppMaster içinde vakayı birincil nesne olarak ele alın ve her iş akışı adımının otomatik olarak bir denetim girdisi yazmasını sağlayın.
İyi bir GDPR istek iş akışı yoğun bir günde çalıştırması kolay ve daha sonra kanıtlaması kolay olandır. Eğer iki soruya hızla cevap verebiliyorsanız — ne yaptık ve ne zaman yaptık — iyi durumdasınız demektir.
Her vaka (erişim, düzeltme veya silme) için tutarlı bir kontrol listesi kullanın: alımı kaydedin ve vaka kimliği, sahibi ve son tarihi atayın; kimliği güvenli bir yöntemle doğrulayın ve nasıl doğrulandığını kaydedin; isteğin kapsamını belirleyin (ürünler, hesaplar, zaman aralığı, veri kaynakları); gereken onayları alın (gizlilik lideri, hukuk ve sistem sahibi gerektiğinde); uygulayın, isteği yapanı bilgilendirin ve tamamlanma kanıtlarını saklayın.
Kanıt için daha fazla kişisel veri saklamanız gerekmez. Ancak güvenilir metadata saklamalısınız. En azından vaka kimliği, istek türü, kimlik doğrulama yöntemi (ham belgeler değil), her adımın zaman damgaları, onaylayanların adları veya rolleri, yapılan eylemler ve teslimat/dosya/silme işinin referansı (örneğin dışa aktarma dosya ID'si, ticket numarası veya silme iş ID'si) gibi bilgileri tutun.
Hataları azaltmak ve yanıtları hızlandırmak için ana mesajları şablonlaştırın ki her istek sahibi net ve tutarlı güncellemeler alsın. Üç hazır mesajınız olsun: onay (ne aldınız, beklenen zaman çizelgesi ve kimliğin nasıl doğrulanacağı), bilgi talebi (ne eksik ve nasıl sağlanacağı) ve tamamlanma (ne teslim edildi veya değiştirildi, ne yapılamadı ve neden, nasıl itiraz edileceği).
Sonraki adımlar: iş akışını uygulamanızın içine yerleştirin, böylece dağılan e-postalarda yaşamaz. Vakayı bir kayıt olarak modelleyin, durum adımlarını ekleyin, kanıt referanslarını iliştirin ve rol tabanlı onaylar ile denetim kayıtları ekleyin.
Ekipler genellikle bu tür bir dahili GDPR vaka aracını AppMaster içinde oluşturur (appmaster.io) çünkü Data Designer ile vaka tablosunu tanımlayabilir, Business Process Editor ile onay ve yürütme adımlarını kurabilir ve denetim izini her durum değişikliğine bağlayabilirler. İyi yapıldığında iş akışı tekrarlanabilir, ölçülebilir ve savunulabilir olur.
GDPR isteği geldiğinde ilk yapmamız gereken şey nedir?İstek geldiğinde mümkün olan en kısa sürede tek bir izlenen vaka oluşturun; ardından kimlik doğrulamayı yapın, veri kaynaklarını belirleyin ve sadece ondan sonra dışa aktarma/düzeltme/silme adımlarını yürütün. “Erişim”, “düzeltme” ve “silme”yi ayrı yollar olarak ele alın ki her biri için doğru onaylar ve kanıt saklanabilsin.
Kimlik doğrulamasını kimlik taraması istemeden nasıl yaparız?Yeni hassas belgeler toplamaktansa, zaten sahip olduğunuz sinyalleri kullanın. Güvenli bir varsayılan yaklaşım, oturum açmış hesaptan doğrulama ya da sistemde kayıtlı e-postaya yanıt vererek doğrulamak; silme gibi daha yüksek riskli eylemler için ikinci bir doğrulama ekleyin.
Her isteğe neden vaka kimliği ve denetim izi gerekli?Çünkü sonradan ne yapıldığını kanıtlamanın tek yolu budur. Zaman damgalı bir vaka kaydı; sahipler, onaylar ve tamamlanma notları kaçırılan son tarihleri ve “birisi zaten halletti” kafa karışıklığını önler ve istek sahibi veya denetleyici sorarsa kanıt sağlar.
Girişte hangi bilgileri toplamalıyız (ve nelerden kaçınmalıyız)?Doğru kaydı bulmak ve sonucu güvenli şekilde teslim etmek için yeterli bilgiyi toplayın: istek türü, hesap tanımlayıcıları, tercih edilen teslim kanalı ve kullanacağınız kimlik doğrulama yöntemi. Gereksiz ek kişisel veriler toplamaktan kaçının; bu, yeni risk ve saklama yükümlülükleri yaratır.
“İsteğin kapsamını belirlemek” gerçekte ne demek?Kapsam, hangi verileri arayacağınızı, nerede saklandıklarını ve hangi zaman aralığının ilgili olduğunu yazmak demektir. Pratik bir varsayılan, uygulama veritabanınızın yanı sıra ödeme, destek, mesajlaşma, analiz, dosya depolama ve yedekler gibi mantıklı şekilde işlem yapabileceğiniz bağlı araçları içermektir.
Erişim (veri dışa aktarma) isteğini en güvenli şekilde nasıl ele alırız?Yapılandırılmış bir paket oluşturun (genellikle JSON veya CSV) ve kişinin anlaması için kısa bir düz dili özet ekleyin. Teslim etmeden önce başka kişilere ait verileri ve sadece dahili notları gözden geçirip temizleyin ve hangi sistemlerin tarandığını ile hangi dosyaların üretildiğini kesin olarak kaydedin.
Düzeltme isteğini denetim/geçmişi bozmadan nasıl yönetmeliyiz?Varsayılan olarak mevcut profil verilerini düzeltin, ancak faturalar veya güvenlik günlükleri gibi tarihsel olarak doğru kalması gereken kayıtları yeniden yazmayın. Üzerine yazılamayan durumlarda düzeltici not ekleyin veya yeni bir giriş ekleyin; eski ve yeni değerleri, değişiklik nedenini, değişikliği yapanı ve zamanı kaydedin.
Silme istendiğinde her şeyi silmek zorunda mıyız?Her zaman değil. Genellikle doğru sonuç kısmi silme veya anonimleştirme olur; yasal olarak tutulması gereken kayıtlar (örneğin finans belgeleri) saklanır. Vaka kapanış notlarında neyin neden tutulduğunu belgeleyin.
GDPR taleplerinde takımlarin en çok yaptığı hatalar nelerdir?Aşırı silme (saklanması gereken verilerin kontrolsüz silinmesi) ve eksik silme (ek dosyalar, günlükler, arama indeksleri veya üçüncü taraf sistemlerin unutulması) en yaygın hatalardır. Ayrıca dışa aktarmalarda birleşim hataları veya paylaşılan gelen kutuları nedeniyle başkasının verisinin dahil edilmesi sık olur.
Bu iş akışını AppMaster içinde nasıl uygularız?İsteği bir “vaka” tablosu olarak modelleyin: durum adımları, sahipler, son tarihler ve kanıt referansları; onayları ve yürütmeyi izin temelli eylemler olarak zorlayın. AppMaster içinde Data Designer ile vaka ve denetim tablolarını oluşturup Business Process Editor ile tekrar eden akışları ve otomatik denetim girdilerini uygulamak yaygın bir yaklaşımdır.
21 Oca 2026
8 dk
20 Oca 20268 dk
20 Oca 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
