Правилата DPDP во Индија: инженерската работа со рок до мај 2027

Индија ги објави Digital Personal Data Protection Rules, 2025 на 13 ноември 2025, како G.S.R. 846(E). Повеќето правила што го допираат вашиот производ сè уште не се на сила. Правилото 1(4) вели дека правилата 3, од 5 до 16, 22 и 23 „стапуваат на сила осумнаесет месеци по датумот на објавување во овој Службен весник“. Избројте осумнаесет месеци и стигнувате до 13 мај 2027, нешто повеќе од седум месеци од денес.

Тие ги опфаќаат известувањата, безбедноста, пријавувањето повреди, чувањето и бришењето, податоците за деца и барањата за остварување права. Правилото 4, што им овозможува на менаџерите на согласност (Consent Managers) да се регистрираат кај Одборот за заштита на податоци (Data Protection Board), доаѓа порано: една година по објавувањето, значи околу 13 ноември 2026. Соопштението на владата тоа го нарекува фазна временска рамка од 18 месеци.

Ова е за CTO и раководителите на производи во индиски потрошувачки апликации, финтек, едтек и компании за е-трговија, како и во странски компании со корисници во Индија. Законот ја опфаќа обработката надвор од Индија кога таа е „во врска со која било активност поврзана со нудење стоки или услуги на субјектите на податоците на територијата на Индија“ (член 3(b)). Она што следи е софтверот што мора да го изградите или промените. Тоа не е правна анализа на јазовите: дали сте во опсегот, кои изземања важат и како се формулирани вашите цели се прашања за вашите правници.

Кој навистина има работа за градење

Ако сите податоци за вашите корисници се во една готова SaaS платформа, голем дел од инфраструктурата (шифрирање, дневници за пристап, задачи за бришење) доаѓа од патоказот на добавувачот. Ваша работа се известувањата, конфигурацијата и договорите. Прочитајте ги тие договори: правилото 6(1)(f) бара безбедносните заштити да бидат запишани во нив, а една илустрација кон правилото 8 ве прави одговорни вашиот давател на облак да ги чува податоците и дневниците пропишаната една година.

Тешката работа паѓа врз компаниите што водат сопствени апликации и бази на податоци, хранат складиште на податоци од десетина текови и испорачуваат SDK од трети страни во мобилниот клиент. Тоа е поголемиот дел од индискиот потрошувачки интернет.

Што бара секое правило од вашиот софтвер

Известување (правило 3)

Известувањето мора да биде „разбирливо независно од која било друга информација“ што ја објавувате. Најмалку, дава „поединечен опис на тие лични податоци“, наведената цел и конкретен опис на стоките, услугите или употребите што обработката ги овозможува. Мора да каже и како се повлекува согласноста, како се остваруваат правата и како се поднесува жалба до Одборот.

Во пракса:

• Генерирајте ги известувањата од попис на податоците. Поле по поле, мапирано кон цели. „Може да собираме информации како“ не е поединечен опис.
• Водете верзии на секое известување. Секој запис за согласност мора да покажува на точниот текст што го видел корисникот.
• Планирајте за јазиците. Член 6(3) од Законот бара можност барањето за согласност да се прочита на англиски или на кој било јазик од Осмиот распоред кон Уставот. Чувајте ја содржината на известувањата како низи за превод, а не како PDF.
• Опфатете ги постојните корисници. Член 5(2) бара известување, „штом тоа е разумно изводливо“, до луѓето што дале согласност пред Законот да стапи на сила. Тоа е кампања кон целата ваша база на корисници.

Согласност, повлекување и менаџери на согласност

Согласноста според член 6 мора да биде конкретна и ограничена на податоците што ги бара целта. Член 6(10) го става товарот на докажување врз вас: во спор, вие покажувате дека известувањето е дадено и согласноста добиена. Таа реченица е причината поради која ви треба регистар на согласности, а не булова колона.

Функционален регистар евидентира, по корисник и цел: верзија на известувањето, временски печат, канал (веб, апликација, менаџер на согласност) и дејство (дадена или повлечена). Само додавање, без измени.

Повлекувањето мора да биде исто толку лесно колку и давањето согласност (правило 3(c)(i), член 6(4)). Ако согласноста била еден допир при регистрацијата, повлекувањето не може да биде е-порака до поддршката. Мора и да патува. Член 6(6) бара да ја прекинете обработката, и да предизвикате вашите обработувачи на податоци да ја прекинат, во разумен рок. Значи услугата за согласност објавува настани за повлекување до секој систем и добавувач што работи за таа цел: CRM, маркетинг платформа, аналитички тек.

Менаџер на согласност е регистрирана единствена контакт точка преку која корисникот може „да ја даде, управува, прегледа или повлече својата согласност“ (член 6(7)). Според Првиот распоред, тој мора да биде компанија основана во Индија со нето вредност од најмалку две крори рупии (една крора е 10 милиони), неговата платформа мора да биде независно сертифицирана според стандарди што ги објавува Одборот, не смее да може да ги чита податоците што ги пренесува и ги чува записите за согласност најмалку седум години.

Правилата тој стандард му го оставаат на Одборот. Изградете влезна патека сега, така што согласност или повлекување што пристигнува од надворешна платформа се обработува точно како оние од вашиот сопствен интерфејс, а обврзете се на формат на пораките дури кога Одборот ќе објави таков. Регистрацијата се отвора околу 13 ноември 2026, па интеграцијата реално почнува на почетокот на 2027.

Безбедносни заштити и дневници (правило 6)

Минималниот список: шифрирање, замаглување, маскирање или токенизација; контрола на пристапот до вклучените системи; „увид во пристапувањето до тие лични податоци, преку соодветни дневници, следење и преглед“; резервни копии за обработката да може да продолжи по инцидент; и чување на „тие дневници и лични податоци за период од една година“.

Барањето за дневниците е местото каде повеќето системи заостануваат. Инфраструктурните дневници не ви кажуваат кој го прочитал записот на кој корисник од која услуга, а тој одговор ви треба една година подоцна. Значи: дневници за пристап на ниво на апликација на секое складиште на лични податоци, испратени на место што услугите не можат да го менуваат, чувани најмалку една година. Почнете рано; воведувањето низ многу услуги трае подолго од која било поединечна функција тука.

Пријавување повреда (правило 7)

Кога ќе дознаете за повреда, го известувате секој засегнат корисник „без одлагање“, преку корисничката сметка или регистриран канал за контакт: што се случило, веројатните последици за него, што правите вие, што може тој да направи и кого да контактира. Одборот добива опис без одлагање, а потоа во рок од 72 часа детален извештај за причините, ублажувањето, евентуалните наоди за тоа кој ја предизвикал, корективните мерки и испратените известувања до корисниците. Одборот може да дозволи подолг рок на писмено барање.

Во софтверот: начин да се пресмета засегнатото множество (што зависи од дневниците за пристап погоре), однапред напишани шаблони, патека за известување што не минува низ повредениот систем и оперативен прирачник што именува кој поднесува до Одборот.

Бришење и чување (правило 8)

Член 8(7) бара бришење кога согласноста е повлечена или целта повеќе не се остварува, освен ако друг закон бара чување. Правилото 8 додава две работи.

Прво, три класи од Третиот распоред се соочуваат со претпоставен крај на целта по три години без контакт: субјекти за е-трговија со најмалку две крори (20 милиони) регистрирани корисници во Индија, посредници за онлајн игри со најмалку педесет лакхи (5 милиони) и посредници на социјални мрежи со најмалку две крори. Пристапот до сметката и токените со зачувана вредност се исклучени. Мора да го предупредите корисникот најмалку 48 часа пред бришењето, а најавувањето го откажува. Тоа е следач на неактивност, распоредувач и задача за известување. Трите години течат од последниот контакт или од стапувањето на сила на Правилата, што ќе е подоцна, па бришење нема да доспее со години, но следењето мора да е точно од почеток.

Второ, правилото 8(3) поставува долна граница: личните податоци, податоците за сообраќај и дневниците за обработка се чуваат најмалку една година од обработката. Илустрацијата во правилото е нарачка на е-книга чии детали мора да го преживеат бришењето на сметката. Значи „избриши ја мојата сметка“ не може да значи DELETE FROM users. Значи: прекини ја обработката, премести го она што мора да се чува во ограничено складиште со датум на чување и избриши го кога датумот ќе помине. Секоја табела бара класа на чување, а исто така и секоја копија во резервните копии, складиштето на податоци и системите на вашите обработувачи.

Барања за права и податоци за контакт (правила 9 и 14)

Корисниците можат да побараат преглед на своите податоци и обработката и идентитетите на секој контролор и обработувач со кој сте ги споделиле (член 11), да побараат исправка, дополнување, ажурирање или бришење (член 12) и да номинираат некој да постапува во нивно име во случај на смрт или неспособност (член 14). Правилото 14 бара да објавите како се поднесува барање и кој идентификатор ви треба и да одговарате на поплаките во објавен рок од најмногу деведесет дена. Правилото 9 бара во секој одговор да бидат наведени податоците за контакт на вашиот службеник за заштита на податоци, или на некој што може да одговори.

За изградба: прием на барања во апликацијата, проверка на идентитетот врзана за сметката, следач на предмети што го води часовникот од деведесет дена, извоз што ги наоѓа податоците на корисникот низ услугите и регистар на споделувања, така што „со кого сте ги споделиле“ е барање кон базата, а не истрага.

Деца и лица со попреченост (правила од 10 до 12)

Според Законот, дете е секој под осумнаесет години. Пред да обработувате податоци на дете, ви треба проверлива согласност од родител, а правилото 10 бара проверка дека родителот е полнолетно лице што може да се идентификува. Проверката може да користи податоци за идентитет и возраст што веќе ги имате за регистриран родител, податоци што ги дава родителот или „виртуелен токен мапиран кон тие податоци“ од овластен субјект, што вклучува и давател на услугата Digital Locker. DigiLocker на MeitY објавува API за барателите за организациите што преземаат проверени документи; нека вашите правници потврдат кои извори го задоволуваат правилото за вашите текови.

Член 9(3) ги забранува следењето, набљудувањето на однесувањето и таргетираното рекламирање насочено кон деца. За потрошувачка апликација тоа е проблем на SDK, а безбедниот стандарден избор е аналитичките и рекламните SDK да се исклучат за секоја сметка означена како малолетна, наместо да се конфигурираат до усогласеност.

Правилото 11 ги опфаќа законските старатели на лица со попреченост: проверувате дека старателот е назначен од суд, назначен орган или комисија на локално ниво. Тоа е прикачување документ и редица за рачен преглед.

Правилото 12 и Четвртиот распоред изземаат одредена обработка од барањето за родителска согласност и од забраната за следење, меѓу другото здравствената заштита, образовните установи (за образовни активности и безбедност), локацијата во реално време заради безбедност и потврдувањето дека корисникот не е дете. Едтек компанија не треба да претпоставува дека се смета за „образовна установа“. Добијте одговор на тоа писмено.

Значајни контролори на податоци (правило 13)

Ако владата ве нотифицира како значаен контролор на податоци (Significant Data Fiduciary), правилото 13 додава годишна процена на влијанието врз заштитата на податоците и ревизија со извештај до Одборот, длабинска анализа дека вашиот алгоритамски софтвер не ги загрозува правата на корисниците и чување во Индија на сите лични податоци што ќе ги определи владата. Член 10 од Законот додава службеник за заштита на податоци со седиште во Индија и независен ревизор на податоци.

Колку чини грешката

Распоредот кон Законот ги утврдува максималните казни: до 250 крори рупии за непреземање разумни безбедносни заштити, до 200 крори за непријавување повреда, до 200 крори за кршење на обврските за податоците за деца, до 150 крори за дополнителните обврски на значаен контролор на податоци и до 50 крори за кршење на која било друга одредба.

План од седум месеци

Октомври 2026: попис. Наведете го секое складиште и тек што содржи лични податоци на корисници од Индија, вклучително и резервните копии, складиштето на податоци, дневниците и обработувачите. Мапирајте го секое поле кон цел. Означете ги корисниците што се деца, проверете ги праговите од Третиот распоред и добијте го мислењето на правниците за опсегот и изземањата.

Ноември 2026: дизајн. Модел на содржина на известувањата и верзии, шема на регистарот на согласности, класи на чување по табела, тек за барањата за права. Почнете со дневниците за пристап. По околу 13 ноември, следете го Одборот за регистрирани менаџери на согласност и стандардот за интероперабилност.

Од декември 2026 до јануари 2027: известувања и согласност. Пуштете ја услугата за согласност, со настаните за повлекување распратени до обработувачите. Преведете ги известувањата.

Февруари 2027: чување и бришење. Ограничено складиште за чување, задачи за бришење низ примарните складишта и кај обработувачите и следачот на неактивност ако спаѓате во класа од Третиот распоред. Изменете ги договорите со обработувачите за заштитите и чувањето од една година.

Март 2027: права и повреди. Прием на барања, проверка, следачот на предмети од деведесет дена, извоз низ услугите, регистар на споделувања. Оперативен прирачник за повреди, шаблони и независна патека за известување, а потоа една вежба на маса.

Април 2027: деца и постојни корисници. Возрасна порта, проверка на родителите, исклучување на SDK за малолетници, преглед на старателите. Испратете го известувањето според член 5(2) до постојните корисници. Интегрирајте се со менаџерите на согласност ако стандардот е објавен.

Почеток на мај 2027: тестирање и замрзнување. Повлечете согласност и потврдете дека маркетинг платформата престанала. Побарајте бришење и потврдете дека копијата во складиштето на податоци отишла во чување. Соберете ги доказите и престанете да менувате работи во неделата пред 13 мај.

Ова претпоставува три или четири паралелни текови. На постари или недокументирани системи, само пописот трае подолго од еден месец.

Каде се вклопува ова

Ако сте граделе за GDPR, добар дел од инфраструктурата се пренесува, а нашиот инженерски водич за GDPR ги опфаќа обрасците за согласност и бришење. Разликите што гризат се поединечното известување, долната граница за чување од една година и проверливата родителска согласност до осумнаесет години. За друг азиски пазар со сопствен режим, погледнете ја регистрацијата PSE во Индонезија.

Градиме услуги за согласност, задачи за чување и бришење, дневници за пристап и текови за барања за права во постојни производи и додаваме инженери во вашиот тим преку зајакнување на тимот кога планот бара повеќе раце отколку што имате. Ние сме инженери, а не правници: опсегот и формулациите им припаѓаат на вашите правници, а ние градиме според нивниот одговор. Пишете ни на office@c9group.dev.