Hindistan'ın DPDP Kuralları: Mayıs 2027'ye Kadar Bitmesi Gereken Mühendislik İşi

Hindistan, Digital Personal Data Protection Rules, 2025'i 13 Kasım 2025'te G.S.R. 846(E) numarasıyla yayımladı. Ürününüzü ilgilendiren kuralların çoğu henüz yürürlükte değil. Kural 1(4)'e göre 3, 5 ila 16, 22 ve 23 numaralı kurallar “bu Resmi Gazete'nin yayım tarihinden on sekiz ay sonra yürürlüğe girer”. On sekiz ay saydığınızda 13 Mayıs 2027'ye varıyorsunuz: bugünden itibaren yedi aydan biraz fazla.

Bu kurallar aydınlatma metnini, güvenliği, ihlal bildirimini, saklama ve silmeyi, çocukların verilerini ve hak taleplerini kapsıyor. Rıza Yöneticilerinin (Consent Manager) Veri Koruma Kurulu'na (Data Protection Board) kaydolmasını sağlayan Kural 4 daha erken geliyor: yayımdan bir yıl sonra, yani 13 Kasım 2026 civarında. Hükümetin duyurusu bunu 18 aylık aşamalı bir takvim olarak tanımlıyor.

Bu yazı Hindistan'daki tüketici uygulamalarının, fintech, edtech ve e-ticaret şirketlerinin, ayrıca Hindistan'da kullanıcısı olan yabancı şirketlerin CTO'ları ve ürün yöneticileri için. Kanun, Hindistan dışında yapılan işlemeyi de “Hindistan topraklarındaki Veri Sahiplerine mal veya hizmet sunulmasına ilişkin herhangi bir faaliyetle bağlantılı” olduğunda kapsıyor (madde 3(b)). Aşağıda anlatılan, geliştirmeniz ya da değiştirmeniz gereken yazılım. Bu bir hukuki boşluk analizi değil: kapsamda olup olmadığınız, hangi istisnaların geçerli olduğu ve amaçlarınızın nasıl ifade edildiği hukuk danışmanınızın cevaplayacağı sorular.

Asıl Geliştirme Yükü Kimde

Müşteri verilerinizin tamamı tek bir hazır SaaS platformunda duruyorsa, altyapının büyük kısmı (şifreleme, erişim kayıtları, silme işleri) sağlayıcının yol haritasından gelir. Sizin işiniz aydınlatma metinleri, yapılandırma ve sözleşmelerdir. Bu sözleşmeleri okuyun: Kural 6(1)(f) güvenlik tedbirlerinin sözleşmelere yazılmasını istiyor ve Kural 8'e eklenen bir örnek, bulut sağlayıcınızın verileri ve kayıtları gereken bir yıl boyunca saklamasından sizi sorumlu tutuyor.

Ağır iş, kendi uygulamalarını ve veritabanlarını işleten, veri ambarını bir düzine veri hattıyla besleyen ve mobil istemcide üçüncü taraf SDK'lar barındıran şirketlerin üzerinde. Hindistan'ın tüketici internetinin çoğu da tam olarak bu.

Her Kural Yazılımınızdan Ne İstiyor

Aydınlatma metni (Kural 3)

Aydınlatma metni, yayımladığınız “başka herhangi bir bilgiden bağımsız olarak anlaşılabilir” olmalı. En azından “bu kişisel verilerin kalem kalem bir tanımını”, belirlenmiş amacı ve işlemenin mümkün kıldığı mal, hizmet veya kullanımların belirli bir tanımını vermeli. Rızanın nasıl geri alınacağını, hakların nasıl kullanılacağını ve Kurul'a nasıl şikâyette bulunulacağını da söylemeli.

Uygulamada:

• Aydınlatma metinlerini bir veri envanterinden üretin. Alan alan, amaçlarla eşleştirilmiş olarak. “Şu gibi bilgileri toplayabiliriz” kalem kalem bir tanım değildir.
• Her aydınlatma metnine sürüm numarası verin. Her rıza kaydı, kullanıcının gördüğü metnin tam sürümüne işaret etmelidir.
• Dilleri baştan planlayın. Kanunun 6(3) maddesi, rıza talebinin İngilizce veya Anayasa'nın Sekizinci Ek Listesi'ndeki herhangi bir dilde okunabilmesi seçeneğini zorunlu kılıyor. Aydınlatma içeriğini PDF olarak değil, çevrilebilir metin dizeleri olarak tutun.
• Mevcut kullanıcıları unutmayın. Madde 5(2), Kanun yürürlüğe girmeden önce rıza vermiş kişilere “makul olarak mümkün olan en kısa sürede” bir aydınlatma metni gönderilmesini istiyor. Bu, tüm kullanıcı tabanınıza yönelik bir kampanya demek.

Rıza, rızanın geri alınması ve Rıza Yöneticileri

Madde 6 kapsamındaki rıza belirli olmalı ve amacın gerektirdiği verilerle sınırlı kalmalı. Madde 6(10) ispat yükünü size yüklüyor: bir uyuşmazlıkta aydınlatmanın yapıldığını ve rızanın alındığını siz göstermek zorundasınız. Boolean bir sütun yerine bir rıza defterine ihtiyaç duymanızın nedeni bu cümle.

İşe yarar bir defter, her kullanıcı ve amaç için şunları kaydeder: aydınlatma metni sürümü, zaman damgası, kanal (web, uygulama, Rıza Yöneticisi) ve işlem (verildi veya geri alındı). Yalnızca ekleme yapılır, kayıt değiştirilmez.

Rızayı geri almak, rıza vermek kadar kolay olmalı (Kural 3(c)(i), madde 6(4)). Rıza kayıt sırasında tek dokunuşla verildiyse, geri alma işlemi destek ekibine e-posta göndermek olamaz. Geri alma bilgisi ayrıca yayılmalı. Madde 6(6), makul bir süre içinde işlemeyi durdurmanızı ve Veri İşleyenlerinizin de durdurmasını sağlamanızı istiyor. Dolayısıyla rıza servisi, geri alma olaylarını o amaç için işlem yapan her sisteme ve sağlayıcıya iletir: CRM, pazarlama platformu, analitik veri hattı.

Rıza Yöneticisi, kullanıcının “rızasını verebileceği, yönetebileceği, gözden geçirebileceği veya geri alabileceği” kayıtlı tek bir temas noktasıdır (madde 6(7)). Birinci Ek Liste'ye göre Hindistan'da kurulmuş ve öz varlığı en az iki crore (20 milyon) rupi olan bir şirket olmalı; platformu, Kurul'un yayımladığı standartlara göre bağımsız olarak sertifikalandırılmalı; aracılık ettiği verileri okuyamamalı ve rıza kayıtlarını en az yedi yıl saklamalı.

Kurallar bu standardı Kurul'a bırakıyor. Harici bir platformdan gelen rıza veya geri alma işleminin kendi arayüzünüzden gelenle tamamen aynı şekilde işlenmesi için gelen bağlantı yolunu şimdiden kurun, ancak veri formatını ancak Kurul bir format yayımladığında kesinleştirin. Kayıtlar 13 Kasım 2026 civarında açılıyor, yani entegrasyon gerçekçi olarak 2027'nin başında başlar.

Güvenlik tedbirleri ve kayıtlar (Kural 6)

Asgari liste şöyle: şifreleme, karartma, maskeleme veya tokenizasyon; ilgili sistemlerde erişim kontrolü; “uygun kayıtlar, izleme ve gözden geçirme yoluyla bu kişisel verilere erişim konusunda görünürlük”; bir olaydan sonra işlemenin sürebilmesi için yedekler; ve “bu kayıtların ve kişisel verilerin bir yıl süreyle” saklanması.

Çoğu sistemin yetersiz kaldığı yer kayıt tutma gereksinimi. Altyapı kayıtları hangi müşterinin kaydını kimin, hangi servisten okuduğunu söylemez ve bu cevaba bir yıl sonra ihtiyacınız olur. Yapılacak iş şu: kişisel veri barındıran her depoda uygulama düzeyinde erişim kaydı, servislerin değiştiremeyeceği bir yere aktarılmış ve en az bir yıl saklanmış olarak. Erken başlayın; bunu çok sayıda servise yaymak buradaki herhangi bir özellikten daha uzun sürer.

İhlal bildirimi (Kural 7)

Bir ihlalden haberdar olduğunuzda, etkilenen her kullanıcıya kullanıcı hesabı veya kayıtlı bir iletişim kanalı üzerinden “gecikmeksizin” bilgi verirsiniz: ne olduğu, onlar için olası sonuçları, sizin ne yaptığınız, onların ne yapabileceği ve kiminle iletişime geçecekleri. Kurul'a gecikmeksizin bir açıklama, ardından 72 saat içinde nedenler, etkiyi azaltma adımları, ihlale kimin yol açtığına dair bulgular, düzeltici önlemler ve kullanıcılara gönderilen bildirimler hakkında ayrıntılı bir rapor gider. Kurul, yazılı talep üzerine daha uzun süre tanıyabilir.

Yazılım tarafında gerekenler: etkilenen kişi kümesini hesaplamanın bir yolu (bu, yukarıdaki erişim kayıtlarına bağlıdır), önceden yazılmış şablonlar, ihlale uğrayan sistemden geçmeyen bir bildirim yolu ve Kurul'a bildirimi kimin yapacağını belirten bir müdahale kılavuzu.

Silme ve saklama (Kural 8)

Madde 8(7), başka bir kanun saklamayı zorunlu kılmadıkça, rıza geri alındığında veya amaç artık karşılanmadığında silmeyi zorunlu tutuyor. Kural 8 buna iki şey ekliyor.

Birincisi, Üçüncü Ek Liste'deki üç sınıf için, üç yıl boyunca temas olmazsa amacın sona erdiği kabul ediliyor: Hindistan'da en az iki crore (20 milyon) kayıtlı kullanıcısı olan e-ticaret kuruluşları, en az elli lakh (5 milyon) kullanıcısı olan çevrim içi oyun aracıları ve en az iki crore (20 milyon) kullanıcısı olan sosyal medya aracıları. Hesap erişimi ve saklanan değer token'ları bunun dışında. Kullanıcıyı silmeden en az 48 saat önce uyarmanız gerekiyor ve bir oturum açma silmeyi iptal ediyor. Bu da bir hareketsizlik takipçisi, bir zamanlayıcı ve bir bildirim işi demek. Üç yıl, son temastan veya Kuralların yürürlüğe girmesinden (hangisi daha geçse) itibaren işliyor; yani yıllarca silinmesi gereken bir şey olmayacak, ama takip en baştan doğru yapılmalı.

İkincisi, Kural 8(3) bir alt sınır koyuyor: kişisel veriler, trafik verileri ve işleme kayıtları, işlemeden itibaren en az bir yıl saklanır. Kuralın verdiği örnek, ayrıntıları hesap silindikten sonra da saklanması gereken bir e-kitap siparişi. Yani “hesabımı sil” DELETE FROM users anlamına gelemez. Anlamı şu: işlemeyi durdurun, saklanması gerekeni bir saklama tarihiyle birlikte erişimi kısıtlı bir depoya taşıyın ve tarih geçince silin. Her tablonun bir saklama sınıfına ihtiyacı var; yedeklerdeki, veri ambarındaki ve veri işleyenlerinizin sistemlerindeki her kopyanın da.

Hak talepleri ve iletişim bilgileri (Kural 9 ve 14)

Kullanıcılar verilerinin ve işleme faaliyetlerinin bir özetini ve bu verileri paylaştığınız her veri sorumlusunun ve veri işleyenin kimliğini isteyebilir (madde 11), düzeltme, tamamlama, güncelleme veya silme talep edebilir (madde 12) ve ölüm veya ehliyetsizlik hâlinde kendi adlarına hareket edecek birini atayabilir (madde 14). Kural 14, bir talebin nasıl yapılacağını ve hangi tanımlayıcıya ihtiyaç duyduğunuzu yayımlamanızı ve şikâyetleri doksan günü geçmeyen, önceden yayımlanmış bir süre içinde yanıtlamanızı istiyor. Kural 9, her yanıtta Veri Koruma Görevlinizin veya soruları yanıtlayabilecek bir kişinin iletişim bilgilerinin yer almasını şart koşuyor.

Geliştirilecekler: uygulama içi talep alma, hesaba bağlı kimlik doğrulama, doksan günlük süreyi işleten bir vaka takip sistemi, bir kullanıcının verilerini servisler arasında bulan bir dışa aktarma ve “kiminle paylaştınız” sorusunu bir soruşturma değil bir sorgu hâline getiren bir paylaşım kaydı.

Çocuklar ve engelli bireyler (Kural 10-12)

Kanuna göre on sekiz yaşından küçük herkes çocuktur. Bir çocuğun verilerini işlemeden önce ebeveynin doğrulanabilir rızasına ihtiyacınız var ve Kural 10, ebeveynin kimliği belirlenebilir bir yetişkin olduğunun kontrol edilmesini istiyor. Bu kontrol, kayıtlı bir ebeveyn için zaten elinizde olan kimlik ve yaş bilgilerini, ebeveynin sağladığı bilgileri veya yetkili bir kuruluştan gelen “bu bilgilerle eşleştirilmiş sanal bir token”ı kullanabilir; yetkili kuruluşlara Dijital Kasa (Digital Locker) hizmet sağlayıcıları da dahil. MeitY'nin DigiLocker'ı, doğrulanmış belgeleri çeken kuruluşlar için talep eden API'leri yayımlıyor; hangi kaynakların sizin akışlarınız için kuralı karşıladığını hukuk danışmanınıza teyit ettirin.

Madde 9(3), çocuklara yönelik takibi, davranışsal izlemeyi ve hedefli reklamcılığı yasaklıyor. Bir tüketici uygulaması için bu bir SDK sorunudur ve güvenli varsayılan, analitik ve reklam SDK'larını uyumlu olacak şekilde yapılandırmaya çalışmak yerine reşit olmayan olarak işaretlenmiş her hesapta tamamen kapatmaktır.

Kural 11, engelli bireylerin yasal vasilerini kapsıyor: vasinin bir mahkeme, yetkili bir makam veya yerel düzeyde bir komite tarafından atandığını doğrularsınız. Bu bir belge yükleme ve manuel bir inceleme kuyruğu demek. Hint hukuk bürolarına göre MeitY, Ekim 2026'da Kanunun 43. maddesi kapsamında Digital Personal Data Protection (Removal of Difficulties) Order, 2026'yı (S.O. 5458(E)) yayımladı ve bu karar madde 9(1)'i “bir çocuğun veya engelli bir kişinin” şeklinde düzeltiyor. Doğrulanabilir rıza yükümlülüğü artık açıkça bir çocuğun verilerinin yanı sıra engelli bir kişinin verilerini de kapsıyor. Bu, metinsel bir düzeltme olarak tanımlanıyor ve bu akışa yeni bir adım eklemiyor.

Kural 12 ve Dördüncü Ek Liste, bazı işleme faaliyetlerini ebeveyn rızası şartından ve takip yasağından muaf tutuyor; bunların arasında sağlık hizmetleri, eğitim kurumları (eğitim faaliyetleri ve güvenlik için), güvenlik amacıyla gerçek zamanlı konum ve bir kullanıcının çocuk olmadığının teyidi var. Bir edtech şirketi “eğitim kurumu” sayıldığını varsaymamalı. Bunun cevabını yazılı olarak alın.

Önemli Veri Sorumluları (Kural 13)

Hükümet sizi Önemli Veri Sorumlusu (Significant Data Fiduciary) olarak bildirirse, Kural 13 şunları ekliyor: Kurul'a rapor sunulan yıllık bir Veri Koruma Etki Değerlendirmesi ve denetim, algoritmik yazılımınızın kullanıcıların haklarını riske atmadığına dair özen yükümlülüğü ve hükümetin belirlediği kişisel verilerin Hindistan içinde tutulması. Kanunun 10. maddesi buna Hindistan'da yerleşik bir Veri Koruma Görevlisi ve bağımsız bir veri denetçisi ekliyor. Aynı kararın, bildirildiğine göre madde 10(2)(c)(ii)'deki “denetim” ifadesini “veri denetimi” ile değiştirdiği ve böylece periyodik denetimi o denetçinin çalışmasına bağladığı belirtiliyor. Tarih de değişebilir: Ocak 2026'da Business Standard, MeitY'nin aralarında Kural 13'ün de bulunduğu bazı hükümler için süreyi 18 aydan 12 aya indirmeyi önerdiğini yazdı. 10 Ekim 2026 itibarıyla bu değişikliği yapan bir bildirim bulamadık, dolayısıyla 13 Mayıs 2027 geçerliliğini koruyor.

Hata Yapmanın Bedeli

Kanunun Ek Listesi azami cezaları belirliyor: makul güvenlik tedbirlerini almamak için 250 crore (2,5 milyar) rupiye kadar, bir ihlali bildirmemek için 200 crore rupiye kadar, çocuk verilerine ilişkin yükümlülükleri ihlal etmek için 200 crore rupiye kadar, bir Önemli Veri Sorumlusunun ek yükümlülükleri için 150 crore rupiye kadar ve diğer herhangi bir hükmün ihlali için 50 crore rupiye kadar.

Yedi Aylık Bir Plan

Ekim 2026: envanter. Hintli kullanıcıların kişisel verilerini barındıran her depoyu ve veri hattını listeleyin; yedekler, veri ambarı, kayıtlar ve veri işleyenler dahil. Her alanı bir amaçla eşleştirin. Çocuk kullanıcıları işaretleyin, Üçüncü Ek Liste eşiklerini kontrol edin ve kapsam ile istisnalar konusunda hukuk danışmanınızın görüşünü alın.

Kasım 2026: tasarım. Aydınlatma metni içerik modeli ve sürümleme, rıza defteri şeması, tablo bazında saklama sınıfları, hak talebi akışı. Erişim kaydına başlayın. 13 Kasım civarından sonra Kurul'u, kayıtlı Rıza Yöneticileri ve birlikte çalışabilirlik standardı açısından takip edin.

Aralık 2026-Ocak 2027: aydınlatma ve rıza. Geri alma olaylarını veri işleyenlere ileten rıza servisini devreye alın. Aydınlatma metinlerini çevirin.

Şubat 2027: saklama ve silme. Erişimi kısıtlı saklama deposu, birincil depolarda ve veri işleyenlerde silme işleri ve Üçüncü Ek Liste sınıflarından birine giriyorsanız hareketsizlik takipçisi. Veri işleyen sözleşmelerini güvenlik tedbirleri ve bir yıllık saklama için değiştirin.

Mart 2027: haklar ve ihlal. Talep alma, doğrulama, doksan günlük vaka takip sistemi, servisler arası dışa aktarma, paylaşım kaydı. İhlal müdahale kılavuzu, şablonlar ve bağımsız bir bildirim yolu; ardından bir masa başı tatbikatı.

Nisan 2027: çocuklar ve mevcut kullanıcılar. Yaş kontrolü, ebeveyn doğrulaması, reşit olmayanlar için SDK anahtarları, vasi incelemesi. Mevcut kullanıcılara madde 5(2) bildirimini gönderin. Standart yayımlandıysa Rıza Yöneticileriyle entegre olun.

Mayıs 2027 başı: test ve dondurma. Bir rızayı geri alın ve pazarlama platformunun durduğunu teyit edin. Bir silme talebinde bulunun ve veri ambarındaki kopyanın saklama deposuna geçtiğini teyit edin. Kanıtları bir araya getirin ve 13 Mayıs'tan önceki haftada hiçbir şeyi değiştirmeyin.

Bu plan üç veya dört paralel iş akışı varsayıyor. Eski veya belgelenmemiş sistemlerde yalnızca envanter bile bir aydan uzun sürer.

Bunun Yeri Neresi

GDPR için geliştirme yaptıysanız altyapının önemli bir kısmı işinize yarar; GDPR mühendislik rehberimiz rıza ve silme kalıplarını ele alıyor. Can yakan farklar kalem kalem aydınlatma metni, bir yıllık saklama alt sınırı ve on sekiz yaşına kadar doğrulanabilir ebeveyn rızası. Kendi düzenlemesi olan başka bir Asya pazarı için Endonezya PSE kaydı yazımıza bakın.

Mevcut ürünlere rıza servisleri, saklama ve silme işleri, erişim kaydı ve hak talebi iş akışları geliştiriyoruz; plan elinizdekinden fazla insan gerektirdiğinde de ekip takviyesi yoluyla ekibinize mühendis ekliyoruz. Biz mühendisiz, avukat değiliz: kapsam ve ifadeler hukuk danışmanınızın işi, biz de onların cevabına göre geliştiriyoruz. office@c9group.dev adresine yazın.