Reddedilen müvekkil talebi: Hukuk bürolarının hangi verileri silmesi gerektiği ve çıkar çatışması kontrolü için hangilerini saklayabileceği

Reddedilen bir müvekkil talebi, ne otomatik olarak altı yıl süreyle dosya arşivinde tutulmalı ne de hemen tamamen çöp kutusuna atılmalıdır. Belirleyici olan, reddedilme sonrasında hangi amaç hala geçerli olduğu, bunun için hangi verilerin gerekli olduğu ve bir avukatlık görevi oluşup oluşmadığıdır.

Hukuk büroları için bunun anlamı şudur: Talebin tamamı, küçük bir çıkar çatışması kontrolü veri seti ve teknik kayıtlar tek bir veri bloğu olarak ele alınmamalıdır. Güvenilir bir süreç, bu düzeyleri birbirinden ayırır, ilgili yasal dayanağı belgeler ve denetlenebilir bir silme zamanı belirler.

Bu yazı, yaygın beş efsaneyi ele alıyor ve bunları kabul, reddetme ve silme süreçleri için pratik bir üç aşamalı modele dönüştürüyor.

Efsane 1: Her müvekkil talebi altı yıllık dosya haline gelir

BRAO’nun 50. maddesi, avukatları görevlerinin işlenmesine ilişkin dosya tutmaya ve bunları ilke olarak altı yıl süreyle saklamaya yükümlü kılar. Süre, görevin sona erdiği takvim yılının bitimiyle başlar. Bu kural, elektronik ortamda tutulan dosyalar için de geçerlidir.

Bu nedenle, salt bir talepte bulunulduğunda öncelikle bir görevin kabul edilip edilmediği netleştirilmelidir. Yalnızca yetki alanı veya çıkar çatışması incelemesinin ardından yapılan kesin bir red, halihazırda kabul edilmiş bir danışmanlık görevi ile aynı şey değildir. Tersine, bir işlemin hukuk bürosu tarafından sistemde “bağlayıcı olmayan talep” olarak tanımlanması, onu bağlayıcı olmayan bir talep haline getirmez: Halihazırda hukuki sorular incelenmişse, eylem önerileri verilmişse veya ücretli bir ilk danışmanlık gerçekleştirilmişse, hukuki sınıflandırma farklı olabilir.

Bunun pratikteki sonucu “altı yıl sonra veya hemen silin” değil, şudur: Öncelikle işlem türünü belirleyin.

• Görev alınmadan yapılan salt ilk temas
• Görev durumu belirsiz olan ön inceleme
• Sınırlı inceleme sonrasında reddedilen görev
• Kabul edilmiş ve daha sonra sonlandırılmış vekalet

Ancak bu durumlar net bir şekilde ayırt edilebildiğinde, § 50 BRAO uygun şekilde uygulanabilir. Şüphe durumunda, hukuk bürosu vekalet kabulünün zamanını ve kapsamını hukuki açıdan incelemeli ve iletişiminde bunu açıkça belirtmelidir.

Efsane 2: Reddedildikten sonra tüm talep derhal silinmelidir

GDPR, veri saklama süresinin sınırlandırılmasını gerektirir: Kişisel veriler, ilgili amaçlar için gerekli olduğu sürece tanımlanabilir şekilde saklanabilir. GDPR’nin 17. maddesi, verilerin asıl amaç için artık gerekli olmadığı durumlarda silinmesini öngörmektedir. Aynı zamanda, bu hüküm, yasal yükümlülükler gibi istisnaları veya verilerin hukuki hakların ileri sürülmesi, kullanılması veya savunulması için gerekli olduğu durumları da kapsamaktadır.

Bir red cevabı, genellikle “görev değerlendirilmesi ve başlatılması” amacını sona erdirir. Ancak bu durum, her sistemdeki tüm bilgilerin aynı anda silinmesi gerektiği anlamına gelmez. Hala sınırlı amaçlar söz konusu olabilir: red mektubunun gönderilmesi ve teyit edilmesi, teslim edilen orijinallerin iadesi, bir sorgunun işlenmesi, somut olarak öngörülebilir taleplere karşı savunma veya daha sonraki bir ihtilaf kontrolü.

Bu amaçlar, verilerin saklanması için bir serbest geçiş kartı değildir. Hukuk bürosu her amaç için şu soruları yanıtlamalıdır:

1. Hangi somut bilgilere hala ihtiyaç vardır?
2. İşlemenin devamı hangi hukuki dayanağa dayanmaktadır?
3. Kimler bu bilgilere erişebilir?
4. Hangi olay inceleme, kısıtlama veya silme işlemini tetikler?

“İleride faydalı olabilir” gibi genel bir gerekçe bu modele uygun değildir. Mesajlar, ekler ve sağlık verileri sınırsız ve eksiksiz olarak aranabilir durumda kaldığı sürece, CRM statüsünün “reddedildi” olması da aynı derecede sorunludur.

Efsane 3: Daha sonraki çıkar çatışması kontrolleri için hukuk bürosunun dosyanın tamamına ihtiyacı vardır

BRAO’nun 43a. maddesinin 4. fıkrası, çıkar çatışması durumunda aynı hukuki davada faaliyet gösterilmesini yasaklamaktadır. Münih Barosu, gerekli çıkar çatışması kontrolünün verilerin daha uzun süre saklanmasını destekleyebileceğine dikkat çekmektedir. Ancak bu durum, ne genel bir saklama süresi ne de gönderilen her belgenin kalıcı olarak saklanması gerekliliğini doğurmaz.

İleride yapılacak bir çıkar çatışması kontrolü için, genellikle temel özet, davanın tam içeriğinden daha yararlıdır. Bu özet, hukuk bürosunun yapısına ve hukuk alanına bağlı olarak şunları içerebilir:

• Tarafların isimleri veya benzersiz tanımlamaları,
• İncelenen işlemdeki roller,
• Davanın kısa ve gereksiz ayrıntılara girmeyen bir tanımı,
• Çıkış kontrolünün tarihi ve sonucu,
• Kontrolü yapan sorumlu kişi.

Böyle bir veri kaydının gerekli olup olmadığı ve ne kadar süreyle saklanması gerektiği, hukuk bürosu tarafından gerekçelendirilmelidir. GDPR’nin 9. maddesine göre özellikle hassas bilgiler, ayrıntılı olay özetleri, kimlik fotokopileri veya eksiksiz ekler, sırf bir kez teslim edildikleri için engel çekirdeğine dahil edilmemelidir.

Bu, Önce karşı tarafı kontrol edin, sonra dosyayı açın başlıklı yazıyla bağlantılıdır: İyi bir çıkar çatışması kontrolü, mümkün olduğunca eksiksiz bir dijital dosya ile değil, gerekli taraf bilgileriyle başlar.

Efsane 4: Silme, Intake sisteminde “reddedildi” seçeneğine tıklamak demektir

Bir durum değişikliği, ilk etapta yalnızca mesleki bir karardır. Teknik olarak, aynı veriler Intake sisteminde, e-posta kutusunda, indirmeler bölümünde, ekip sohbetlerinde, hukuk bürosu yazılımında, yerel çalışma klasörlerinde, yedeklemelerde ve kayıtlarda hâlâ bulunabilir.

Bu nedenle silme süreci, veri akışını yansıtmalıdır. İletişim Formu mu, Dijital İlk Değerlendirme mi? başlıklı yazı, bir talebin neden formla bitmediğini göstermektedir. Silme işlemi için de aynı şey geçerlidir: Verilerin aktarımı boyunca planlanmalıdır.

Beş sorudan oluşan bir sistem haritası oluşturmak mantıklıdır:

Yedeklemeler, üretim verileri gibi tek tek aranabilir ve anında üzerine yazılabilir olmak zorunda değildir. Ancak yedekleme konsepti, geri yükleme, erişim koruması ve düzenli üzerine yazma işlemlerini, silinen taleplerin kontrolsüz bir şekilde günlük iş akışına geri dönmemesi için düzenlemelidir. Somut teknik uygulama sisteme bağlıdır ve araç incelemesi kapsamında ele alınmalıdır.

Efsane 5: Reddedilen tüm talepler için tek bir silme süresi yeterlidir

GDPR, reddedilen yetki talepleri için evrensel bir ay veya yıl sayısı belirtmez. 13. madde, daha ziyade saklama süresi hakkında şeffaf bilgiler veya bu sürenin belirtilememesi durumunda, sürenin belirlenmesine ilişkin kriterler hakkında bilgi verilmesini gerektirir. 5. maddede belirtilen saklama sınırlaması, amaca yönelik bir değerlendirme yapılmasını gerektirir.

Bu nedenle bir hukuk bürosu, kendi süreçlerini incelemeden herhangi bir süreyi aynen uygulamamalıdır. Sadece geri aranma talebi içeren bir işlem, çıkar çatışması nedeniyle reddedilen bir talep, içeriği zaten incelenmiş acil bir talep ve faturalandırılmış ilk danışmanlık hizmeti, birbirinden farklı veriler, riskler ve hukuki dayanaklara sahiptir.

Olay temelli silme kuralları daha uygundur:

• Red mektubu gönderildikten ve artık tamamlanmamış herhangi bir organizasyonel işlem kalmadığında, operasyonel dosya açma amacı sona erer.
• Belgeler iade edildiğinde veya sorular yanıtlandığında, dosyanın tamamı silinmeye hazır hale gelebilir.
• Çatışma kontrolleri için gerekçeli bir saklama çekirdeği kalırsa, bu ayrı olarak tutulur ve gerekliliği düzenli olarak kontrol edilir.
• Somut bir hukuki ihtilaf veya talep öngörülebiliyorsa, bunun için gerekli belgeler ayrı olarak değerlendirilir, erişimi kısıtlanır ve rutin olarak kullanılmaya devam edilmez.
• Bir görev talebi varsa, bu konuda geçerli mesleki hukuk kuralları ve diğer saklama yükümlülükleri geçerlidir.

Münih Barosu, teknik önlemler alınmasını, bir silme planı hazırlanmasını ve bir süre takvimi oluşturulmasını tavsiye etmektedir. Bu bağlamda yeniden gündeme alma süreci önemlidir: İnceleme tarihi belirtilmemiş bir kayıt, genellikle daha kibar bir adla anılan süresiz depolamadan ibarettir.

Reddedilen talepler için üç aşamalı model

Küçük ve orta ölçekli hukuk büroları için karar süreci, üç ayrı veri düzeyine indirgenebilir.

1. Düzey: Dosya Kaydı

Bu kayıt, orijinal mesajı, anket yanıtlarını, ekleri, iç notları ve red kararını içerir. Müvekkillik sürecinin sona ermesinden sonra, bu dosyanın hâlâ bir amacı olup olmadığı ve ne ölçüde bir amacı olduğu kontrol edilir. Artık gerekli olmayan içerikler silinir; saklanması gereken içerikler ise yasal dayanak, erişim yetkisi ve inceleme tarihi ile birlikte belgelenir.

Katman 2: Engelleme Çekirdeği

Bu katman, daha sonra haklı bir ihtilaf incelemesi için gerekli olan bilgileri içerir. Kilitli çekirdek, tamamen reddedilmiş vekaletlerin gölge arşivi haline gelmemelidir. Erişim, arama mantığı ve denetim sıklığı, normal iletişim verilerine kıyasla daha sıkı bir şekilde tanımlanmalıdır.

Katman 3: Sistem İzleri

Bunlar arasında gönderim kanıtları, denetim günlükleri, güvenlik protokolleri ve yedekleme durumları yer alır. Bunların kendine özgü teknik veya güvenlikle ilgili amaçları vardır. Hukuk bürosu, hangi içeriklerin gerçekten bulunduğunu, kimlerin erişebileceğini, izlerin ne kadar süreyle gerekli olduğunu ve bir geri yükleme durumunda ne olacağını belgeler.

Bu ayrım, iki tipik hatayı önler: gerekli bir kanıtın aceleyle imha edilmesi ve sadece ileride olası bir çıkar çatışması kontrolü nedeniyle tam bir talebin sınırsız olarak saklanması.

Yedi adımda uygulanabilir bir iş akışı

1. Girişi sınırlayın. Çatışma kontrolünden önce, yalnızca bunun için gerekli olan taraf bilgilerini toplayın. Ayrıntılı olay özetleri ve dosya yüklemelerini daha sonraki aşamalarda talep edin. Bu konuyla ilgili daha fazla bilgi için Dijital müvekkil kaydı: daha az geri dönüş başlıklı yazıya bakabilirsiniz.

2. Durumu net bir şekilde belirleyin. “Yeni”, “inceleniyor”, “dava kabul edildi”, “reddedildi” ve “ek bilgi bekleniyor” durumlarının sistemde farklı sonuçlar doğurması gerekir.

3. Reddi belgelendirin. Reddin ne zaman ve hangi yolla gönderildiğini kayda geçirin. Belgeleme kısa tutulmalı ve gereksiz teknik değerlendirmeler içermemelidir.

4. Verileri sınıflandırın. Tam işlem dosyası, olası erişim engelleme çekirdeği ve sistem izlerini ayrı ayrı değerlendirin.

5. Yasal dayanağı ve tetikleyiciyi belirleyin. Kalan her kategori için amaç, yasal dayanak, erişim, süre kriteri ve silme olayını belgelendirin.

6. Silme işlemini tüm sistemler genelinde gerçekleştirin. Giriş, e-posta, dosya, dışa aktarmalar ve bağlı hizmetleri dahil edin. Genel bir denetim mantığı için Hukuk Bürosunda GDPR: Yeni Araçlar İçin Pratik Denetim Noktaları başlıklı makaleye bakabilirsiniz.

7. Örneklem kontrolü yapın. Düzenli olarak, reddedilen bazı işlemleri giriş aşamasından yedekleme planına kadar takip edin. Böylece, belgelenen sürecin gerçekten işleyip işlemediği ortaya çıkar.

Jurono ile ilgili not: Yaşam döngüsü dosya oluşturulmadan önce başlar

Jurono, yapılandırılmış müvekkil kaydı sürecini sonraki iş akışının bir parçası olarak değerlendirir. Silme kuralları açısından bu tutarlılık önemlidir: Verilerin toplanması aşamasında bile, çakışma denetimi öncesinde hangi verilerin gerekli olduğu, hangi durumun daha ileri işlemeyi tetiklediği ve kabul edilmeyen taleplerin nasıl ele alınacağı net olmalıdır.

Somut bir Jurono uygulamasında hangi silme, yetki ve kayıt tutma işlevlerinin mevcut olduğu ve kendi amaçlarınıza uygun olup olmadığı, güncel işlev kapsamı temelinde değerlendirilmelidir. Jurono, ne saklama sürelerinin yasal olarak belirlenmesini ne de münferit vakaların incelenmesini ikame eder. Ancak, gerçek hukuk bürosu senaryoları temelinde, talebin alınmasından reddedilmesine kadar planlanan yaşam döngüsünü simüle etmek için bir demo kullanılabilir.

Sonuç: Talebi değil, her bir amacı sonlandırın

Bir müvekkil talebinin reddedilmesinden sonra, ne genel bir saklama ne de genel bir anında silme yaklaşımı ikna edicidir. Hukuk bürosu, bir görevin var olup olmadığını ve reddedilme sonrasında hangi sınırlı amaçların devam ettiğini netleştirmelidir.

Üç aşamalı model bu konuda pratik bir düzen sağlar: eksiksiz dosya verileri, asgari kilitleme çekirdeği ve teknik sistem izleri ayrı ayrı değerlendirilir. Her veri kaydına bir amaç, bir yasal dayanak, bir erişim ve bir silme olayı atayanlar, aynı zamanda veri koruma risklerini, gölge arşivleri ve bir sonraki ihtilaf kontrolü sırasında ortaya çıkabilecek belirsizliği de azaltır.

Bu yazı, genel organizasyonel ve hukuki bir sınıflandırma amaçlıdır ve bireysel hukuki danışmanlık niteliği taşımaz. Bir işin gerçekleşip gerçekleşmediği ve her bir durumda hangi saklama süresinin izin verilebilir veya gerekli olduğu, somut olarak incelenmelidir.

Kaynaklar

1. Avrupa Birliği, EUR-Lex – “(AB) 2016/679 sayılı Tüzük (Genel Veri Koruma Tüzüğü)”, 27.04.2016, özellikle Madde 5, 6, 9, 13, 17, 18 ve 25, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:02016R0679-20160504, Erişim tarihi: 12.08.2026. Desteklenen hususlar: Amaç sınırlaması, veri asgari tutma ilkesi, saklama süresi sınırlaması, yasal dayanaklar, özel veri kategorileri, şeffaflık, silme, kısıtlama ve tasarım yoluyla veri koruma.
2. Federal Adalet Bakanlığı / Federal Adalet Dairesi – “§ 43a BRAO – Temel Yükümlülükler”, güncel yasa metni, https://www.gesetze-im-internet.de/brao/__43a.html, Erişim tarihi: 12.08.2026. Dayanak: Çıkar çatışması durumunda gizlilik ve faaliyet yasağı.
3. Federal Adalet Bakanlığı / Federal Adalet Dairesi – “§ 50 BRAO – Dosyalar”, güncel yasa metni, https://www.gesetze-im-internet.de/brao/__50.html, Erişim tarihi: 12.08.2026. Destekleyici açıklama: İşlemlerin yürütülmesine ilişkin dosya kayıtlarının tutulması ve altı yıl süreyle saklanması; elektronik dosya yönetiminde de buna uygun şekilde uygulanması.
4. Münih Barosu – “Hukuk Bürolarında Veri Koruma”, yayın tarihi belirtilmemiş, https://www.rak-muenchen.de/rechtsanwaelte/mitgliederservice/datenschutz-in-anwaltskanzleien/, Erişim tarihi: 12.08.2026. Desteklenen ifade: Depolama sınırı, çıkar çatışması kontrolünün olası saklama amacı ile teknik silme önlemleri, silme planı ve süre takvimi önerileri.
5. Hessen Veri Koruma ve Bilgi Özgürlüğü Sorumlusu – “Veri sahiplerinin avukatlara karşı hakları”, 31.03.2023 tarihi itibarıyla, https://datenschutz.hessen.de/datenschutz/polizei-und-justiz/rechte-betroffener-personen-gegenueber-rechtsanwaeltinnen-und-anwaelten, Erişim tarihi: 12.08.2026. Dayanak: Mevcut müvekkillik ilişkilerinde GDPR Madde 17 ile BRAO § 50 arasındaki ilişki ve müvekkillik ilişkisi bulunmayan kişilerle ilgili özel durumlar.