Veri işleme sözleşmesi: web ajansları için GDPR Madde 28

Ajansınız bir müşterinin WordPress yönetim paneline giriş yapabiliyorsa, siteyi barındırıyorsa ya da yedeklerini tutuyorsa, o müşteri adına büyük olasılıkla kişisel veri işliyorsunuz demektir. Bu durumda müşteriyle bir veri işleme sözleşmesi yapmanız gerekir. Ekibin büyüklüğü fark etmez: beş kişilik bir ajans da tek başına çalışan bir freelancer da aynı durumdadır.

Bu yazı sözleşmeye ajansın tarafından bakıyor. Sattığınız hangi hizmetlerin sizi veri işleyen yaptığını, güvenlik ekinde neyin yazması gerektiğini ve pratikte sorun çıkaran konuları ele alıyor: alt işleyenler, olaylar ve sözleşmenin sona ermesi.

Bir web ajansı ne zaman veri işleme sözleşmesi yapmalı?

Bir işletmenin WordPress sitesinde neredeyse her zaman kişisel veri bulunur. Tipik örnekler: bir form eklentisinin veritabanında sakladığı iletişim formu kayıtları, ad ve adres içeren WooCommerce siparişleri, müşteri kullanıcı hesapları ve bülten abonelikleri. Bunlara yönetici girişi, barındırma erişimi, veritabanı bağlantısı ya da bir yedek dosyası üzerinden ulaşabiliyorsanız, bu verileri işliyor olabilirsiniz.

GDPR (AB Genel Veri Koruma Tüzüğü) uyarınca müşteri veri sorumlusudur; verinin neden ve nasıl işleneceğine o karar verir. Siz ise bu veriyi onun talimatıyla, örneğin sitesini güncel tutarak ya da barındırmasını yöneterek işlediğinizde veri işleyensiniz. Madde 28, ikiniz arasında bir sözleşme yapılmasını zorunlu kılar: veri işleme sözleşmesi (DPA). Bu sözleşme, veriyle neler yapabileceğinizi ve onu nasıl koruyacağınızı belirler.

Hangi ajans hizmetleri genellikle veri işleme sayılır?

Belirleyici olan, veriye erişebilmenizdir; verilere fiilen bakıp bakmamanız değil. Aşağıdakiler tipik örneklerdir, kesin kurallar değil:

İki nokta sık gözden kaçar. Birincisi, bir temayı denemek için canlı veritabanını staging ortamına kopyaladığınız anda "yalnızca tasarım" projesi olmaktan çıkar. O kopya gerçek müşteri verisi içerir. İkincisi, kendi iletişim formlarınız, CRM'iniz ve faturalamanız müşteri adına yapılan işleme değildir. Bu veriler için veri sorumlusu ajansınızdır ve kendi aydınlatma metninize ve önlemlerinize ihtiyacınız vardır.

Pratik bir ilk adım olarak her müşteri sitesini listeleyin ve her birinde hangi erişimlere sahip olduğunuzu yazın. Muhtemelen kimsenin hatırlamadığı girişler bulacaksınız. Bunları nasıl kaldıracağınız kullanıcı rollerini temizleme rehberinde anlatılıyor.

Güvenlik bölümü: teknik ve organizasyonel önlemlerin tarifi

Çoğu veri işleme sözleşmesinde teknik ve organizasyonel önlemlere (TOM) ayrılmış bir ek bulunur. Ajanslar çoğu zaman bu eke hazır bir liste yapıştırır. Daha iyi yol, gerçekte yaptığınız şeyleri sade bir dille yazmaktır:

• Girişler: Müşteri sitelerinde kullandığınız her yönetici hesabında iki faktörlü kimlik doğrulama.
• Kişiye özel hesaplar: Her çalışan için ayrı bir hesap; asla ortak bir "ajans" yöneticisi olmasın. Böylece kimin ne yaptığı görülebilir ve bir kişinin erişimi ekibin geri kalanını etkilemeden kaldırılabilir.
• Kimlik bilgileri: Tablolarda ya da sohbet yazışmalarında değil, müşteri bazında erişim tanımlanmış bir ekip parola yöneticisinde saklanır.
• En az yetki: Tam yönetici erişimi gerekmeyen yerde Editör rolü ya da özel bir rol kullanın.
• Yedekler: Nerede saklandıkları, şifrelenip şifrelenmedikleri ve hangi adı belli kişilerin geri yükleyebildiği ya da indirebildiği.
• Yamalar: Çekirdek, eklenti ve tema güncellemelerini ne sıklıkla uyguladığınız, kritik güvenlik düzeltmelerine ne kadar hızlı müdahale ettiğiniz.
• Günlük kaydı: Hangi etkinlikleri kaydettiğiniz ve kayıtları ne kadar süre tuttuğunuz.
• Kişiler: Çalışanlar ve freelancer'lar için gizlilik yükümlülükleri ve biri ayrıldığında uygulanan yazılı bir çıkış süreci.

Ek, gerçeği yansıtmalıdır. Yürütmediğiniz 7/24 izleme ya da üç ayda bir yapılan sızma testleri vaat ederseniz, bir şey ters gittiği gün kendi aleyhinize yazılı delil üretmiş olursunuz. Eki kısa ve doğru tutun, kurulumunuz değiştikçe güncelleyin.

Bu önlemler Madde 32(1)(a)–(d) ile örtüşür: takma adlandırma ve şifreleme; gizlilik, bütünlük, erişilebilirlik ve dayanıklılığın sürekliliği; olaydan sonra verilere zamanında yeniden erişebilme; önlemlerin düzenli olarak test edilmesi. GDPR Madde 32 rehberi her bir noktayı ayrıntılı biçimde ele alıyor.

Alt işleyenler: barındırma, yedek depolama ve kullandığınız araçlar

Müşteri verisi nadiren yalnızca sizde kalır. Genellikle başka hizmetlerden de geçer:

• yeniden sattığınız ya da yönettiğiniz barındırma sağlayıcısı veya sunucu platformu
• S3 türü bir depolama alanı ya da bir yedekleme eklentisinin kendi bulutu gibi yedek depolama
• kimlik bilgilerini tutan veya site içeriğini görebilen uptime ya da izleme hizmetleri
• ayrı bir platformdaki staging ortamları
• müşterilerin sipariş ayrıntılarını ya da müşteri e-postalarını yapıştırdığı destek ve bilet araçları

Bunların her biri bir alt işleyendir. Her müşteri için, o müşteri adına hangi sağlayıcıları kullandığınızı ve verileri nerede sakladıklarını gösteren yazılı bir liste tutun. Sağlayıcı eklemeden ya da değiştirmeden önce müşteriye haber verin ve her biriyle kendi veri işleme sözleşmenizin bulunduğundan emin olun. Bir sağlayıcı veriyi AB dışında saklıyor ya da oradan erişiyorsa, buna güvenmeden önce aktarım dayanağını kontrol edin ve bunu listede belirtin. Müşteri, yedeklerinin hiç duymadığı bir serviste durduğunu bir ihlal bildiriminden öğrenmemelidir.

Olay bildirimi: müşteriye nasıl ve ne zaman haber verirsiniz?

Veri sorumlusu olan müşteri, bir kişisel veri ihlalini öğrendiği andan itibaren gereksiz gecikme olmaksızın ve mümkünse 72 saat içinde denetim otoritesine bildirmek zorundadır (Madde 33). Bildirmediği ihlaller dahil her ihlali belgelemesi de gerekir (Madde 33(5)). Bunu ancak siz ona hızlı haber verir ve kullanabileceği bilgiler sunarsanız yapabilir.

Veri işleme sözleşmesinde ya da operasyonel bir ekte şunları kararlaştırın:

1. Müşteriye bolca zaman bırakan bir iç süre sınırı. Örneğin şüpheli bir ihlali fark ettikten sonraki 24 saat içinde, inceleme bitmemiş olsa bile bildirin.
2. Her iki tarafta da bir yedeğiyle birlikte adı belli bir irtibat kişisi.
3. Mesai dışında da çalışan bir bildirim kanalı. Yalnızca e-posta zayıf bir seçimdir.
4. Gönderilecek asgari bilgiler: ne oldu, ne zaman fark ettiniz, hangi sistemler ve veriler etkilendi, şimdiye kadar ne yaptınız.

Müşterinin sizin bildiriminizden sonraki adımları, yani değerlendirme ve bildirimin içeriği, 72 saatlik ihlal bildirimi rehberinde anlatılıyor.

Sözleşme sonu: erişimlerin kapatılması, verilerin iade ve silinmesi

Hiç kaldırılmayan ajans girişleri, eski müşteri sitelerine giren yaygın bir yoldur. Aynı zamanda sizin için de bir yükümlülüktür: bu hesaplardan biri kötüye kullanılırsa müşteri, hesabın neden hâlâ var olduğunu soracaktır. Bir sözleşme bittiğinde şu kontrol listesini kullanın:

• İçerikleri bir müşteri hesabına devrettikten sonra tüm ajans yönetici hesaplarını silin
• Araçlarınız için oluşturulan uygulama parolalarını iptal edin
• SFTP/SSH anahtarlarınızı ve barındırma kontrol paneli erişiminizi kaldırın
• Elinizdeki yedekleri müşterinin talimatına göre teslim edin veya silin
• Yerel veritabanı kopyalarını, dışa aktarımları ve staging sitelerini silin
• Müşteriye ait kayıtları parola yöneticinizden ve izleme araçlarınızdan kaldırın
• Tamamlanan adımları müşteriye yazılı olarak teyit edin

WP-CLI erişiminiz olan sitelerde, devretmeden önce geriye kalan yöneticileri şu komutla listeleyebilirsiniz:

wp user list --role=administrator --fields=ID,user_login,user_email

Sözleşmeyi gerçeğe uygun tutmak: kanıtlar ve NIS2 kaynaklı müşteri soruları

Madde 5(2) uyarınca veri sorumlusu, uyumu kanıtlayabilmelidir. Pratikte müşteri, ekinizin gerçekte yaptıklarınızı yansıttığını göstermenizi isteyecektir. Kullanışlı kanıtlar arasında çalışan hesaplarınızın 2FA durumu, tarihli erişim gözden geçirmeleri, yedek geri yükleme testleri ve güncel güvenlik denetim raporları yer alır. Nelerin saklanacağını denetim belgelendirme rehberi açıklıyor.

NIS2 Direktifi kapsamındaki müşteriler tedarikçilerinin güvenliğini yönetmek zorundadır (Madde 21(2)(d)). NIS2 size doğrudan uygulanmasa bile size anketler gönderecekler. Müşteri sistemlerini yöneten, orta ölçekli bir ajans, yani 50 veya daha fazla çalışanı ya da 10 milyon avroyu aşan yıllık cirosu ve bilanço toplamı olan bir ajans, yönetilen hizmet sağlayıcısı olarak kendisi de kapsama girebilir. Ülkenizin ulusal NIS2 mevzuatına bakın; kontrolü NIS2 kapsam rehberi adım adım gösteriyor.

secaudit.eu eklentisi, GDPR Madde 32 ve NIS2 Madde 21 ile eşleştirilmiş bir denetim raporunu ve bir olay bildirimi taslağını dışa aktarır. İkisi de bu kanıtlara destek olabilir. Hiçbiri sizi ya da müşterinizi uyumlu hale getirmez.

Madde 28 ve 32'yi de kapsayan GDPR Madde 25–39 ihlalleri, 10 milyon avroya veya küresel yıllık cironun %2'sine kadar idari para cezasıyla sonuçlanabilir (Madde 83(4)(a)). Çoğu ajans için daha yakın risk, sözleşme gerçeği yansıtmadığı için bir olaydan sonra müşteri kaybetmektir.

Sonraki adım: Erişiminiz olan her müşteri sitesinin listesini çıkarın. Her biri için güncel bir veri işleme sözleşmesinin bulunup bulunmadığını ve TOM ekinin bugün gerçekte yaptıklarınızı anlatıp anlatmadığını kaydedin. İki sorudan birinin cevabı "hayır" olan siteleri önce düzeltin.

Sık sorulan sorular

Tek başıma çalışan bir freelancer'ım. Yine de veri işleme sözleşmesi gerekir mi?

Evet, müşteri adına kişisel veri işliyorsanız gerekir. GDPR, veri işleyenleri büyüklüklerine göre muaf tutmaz.

Sözleşmeyi kim hazırlar, müşteri mi ajans mı?

İki taraf da hazırlayabilir. Birçok ajans bakım paketleriyle birlikte standart bir veri işleme sözleşmesi sunar; bu, çok sayıda müşteride zaman kazandırır. Bir avukata bir kez inceletin ve TOM ekini her hizmete göre uyarlayın.

Barındırma şirketimin veri işleme sözleşmesi bunu kapsamaz mı?

Hayır. O sözleşme sizin barındırma sağlayıcısıyla ilişkinizi kapsar. Müşteriyle ilişkinizin kendi sözleşmesi olmalıdır.

Bu makale genel bilgi niteliğindedir; hukuki danışmanlık değildir.