Правилата DPDP в Индия: инженерната работа, която трябва да е готова до май 2027 г.

На 13 ноември 2025 г. Индия обнародва Digital Personal Data Protection Rules, 2025 (Правилата за защита на цифровите лични данни) като G.S.R. 846(E). Повечето правила, които засягат вашия продукт, още не са в сила. Правило 1(4) гласи, че правила 3, от 5 до 16, 22 и 23 „влизат в сила осемнадесет месеца след датата на обнародване в този Държавен вестник". Пребройте осемнадесет месеца и стигате до 13 май 2027 г., малко повече от седем месеца от днес.

Те обхващат уведомленията, сигурността, съобщаването на пробиви, съхранението и изтриването, данните на деца и исканията за упражняване на права. Правило 4, което позволява на Consent Managers (посредници за управление на съгласието) да се регистрират в Съвета за защита на данните (Data Protection Board), влиза в сила по-рано: една година след обнародването, тоест около 13 ноември 2026 г. В съобщението на правителството това е наречено поетапен график от 18 месеца.

Статията е за технически директори и продуктови ръководители в индийски потребителски приложения, финтех и едтех компании и електронни магазини, както и в чуждестранни компании с потребители в Индия. Законът обхваща и обработване извън Индия, когато то е „във връзка с дейност, свързана с предлагане на стоки или услуги на субекти на данни на територията на Индия" (раздел 3(b)). По-долу е описан софтуерът, който трябва да изградите или промените. Това не е правен анализ на пропуските: дали попадате в обхвата, кои изключения важат и как са формулирани целите ви, са въпроси към юриста ви.

Кой всъщност има работа по разработката

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

Тежката работа е за компаниите, които поддържат собствени приложения и бази данни, захранват склад за данни от десетина конвейера и вграждат SDK на трети страни в мобилния клиент. Това е по-голямата част от индийския потребителски интернет.

Какво изисква всяко правило от софтуера ви

Уведомление (правило 3)

Уведомлението трябва да е „разбираемо самостоятелно, независимо от всяка друга информация", която публикувате. Като минимум то съдържа „подробно описание по позиции на тези лични данни", конкретната цел и конкретно описание на стоките, услугите или ползите, които обработването прави възможни. В него трябва да е посочено и как се оттегля съгласие, как се упражняват права и как се подава жалба до Съвета.

На практика:

• Генерирайте уведомленията от опис на данните. Поле по поле, свързано с целите. „Може да събираме информация като" не е описание по позиции.
• Версионирайте всяко уведомление. Всеки запис за съгласие трябва да сочи точно текста, който потребителят е видял.
• Предвидете езиците. Раздел 6(3) от закона изисква искането за съгласие да може да се прочете на английски или на всеки от езиците в Осмото приложение към Конституцията. Пазете съдържанието на уведомленията като низове за превод, а не като PDF.
• Обхванете и съществуващите потребители. Раздел 5(2) изисква уведомление „веднага щом това е разумно осъществимо" до хората, дали съгласие преди влизането в сила на закона. Това е кампания към цялата ви потребителска база.

Съгласие, оттегляне и Consent Managers

Съгласието по раздел 6 трябва да е конкретно и ограничено до данните, от които целта се нуждае. Раздел 6(10) прехвърля тежестта на доказване върху вас: при спор вие доказвате, че е дадено уведомление и е получено съгласие. Точно заради това изречение ви трябва регистър на съгласията, а не булева колона.

Работещият регистър записва за всеки потребител и всяка цел: версията на уведомлението, времевия печат, канала (уеб, приложение, Consent Manager) и действието (дадено или оттеглено). Само добавяне, без промяна на записи.

Оттеглянето трябва да е толкова лесно, колкото и даването на съгласие (правило 3(c)(i), раздел 6(4)). Ако съгласието е било едно докосване при регистрацията, оттеглянето не може да е имейл до поддръжката. То трябва и да се разпространява. Раздел 6(6) изисква да спрете обработването и да накарате обработващите ви данни (Data Processors) да го спрат в разумен срок. Затова услугата за съгласие публикува събитията за оттегляне към всяка система и всеки доставчик, които действат по тази цел: CRM, маркетинговата платформа, аналитичния конвейер.

Consent Manager е регистрирано единно звено за контакт, чрез което потребителят може да „дава, управлява, преглежда или оттегля съгласието си" (раздел 6(7)). Според Първото приложение той трябва да е дружество, учредено в Индия, с нетна стойност на активите поне два крора рупии, платформата му трябва да е независимо сертифицирана по стандарти, които Съветът публикува, не бива да може да чете данните, които препраща, и пази записите за съгласие поне седем години.

Правилата оставят този стандарт на Съвета. Изградете входящ канал още сега, така че съгласие или оттегляне, пристигнало от външна платформа, да се обработва точно както това от собствения ви интерфейс, и се обвържете с конкретен формат на обмен едва когато Съветът публикува такъв. Регистрацията се открива около 13 ноември 2026 г., така че реално интеграцията започва в началото на 2027 г.

Предпазни мерки за сигурност и журнали (правило 6)

Минималният списък: криптиране, обфускация, маскиране или токенизация; контрол на достъпа до засегнатите системи; „видимост върху достъпа до тези лични данни чрез подходящи журнали, наблюдение и преглед"; резервни копия, за да може обработването да продължи след инцидент; и съхранение на „тези журнали и лични данни за срок от една година".

Изискването за журналите е мястото, където повечето системи не достигат. Инфраструктурните журнали не ви казват кой от коя услуга е прочел записа на кой клиент, а този отговор ви трябва и година по-късно. Затова: журнали за достъп на ниво приложение при всяко хранилище на лични данни, изпращани на място, което услугите не могат да променят, и пазени поне година. Започнете рано; въвеждането им в много услуги отнема повече време от която и да е отделна функционалност тук.

Съобщаване на пробив (правило 7)

Щом научите за пробив, уведомявате всеки засегнат потребител „без забавяне" чрез потребителския му акаунт или регистриран канал за контакт: какво се е случило, какви са вероятните последици за него, какво правите вие, какво може да направи той и към кого да се обърне. Съветът получава описание без забавяне, а до 72 часа и подробен доклад за причините, ограничаването на щетите, установеното за това кой е причинил пробива, коригиращите мерки и изпратените до потребителите уведомления. По писмено искане Съветът може да даде по-дълъг срок.

В софтуера това означава: начин да се изчисли кръгът на засегнатите (което зависи от журналите за достъп по-горе), предварително написани шаблони, канал за уведомяване, който не минава през пробитата система, и наръчник за действие, в който е посочено кой подава доклада до Съвета.

Изтриване и съхранение (правило 8)

Раздел 8(7) изисква изтриване при оттегляне на съгласието или когато целта вече не се обслужва, освен ако друг закон не изисква съхранение. Правило 8 добавя две неща.

Първо, за три категории от Третото приложение се приема, че целта е отпаднала след три години без контакт: субекти за електронна търговия с поне два крора регистрирани потребители в Индия, посредници за онлайн игри с поне петдесет лакха и посредници в социалните медии с поне два крора. Изключение правят достъпът до акаунта и токените със съхранена стойност. Трябва да предупредите потребителя поне 48 часа преди изтриването, а едно влизане в акаунта го отменя. Това е проследяване на неактивността, планировчик и задача за уведомяване. Трите години текат от последния контакт или от влизането в сила на Правилата, което от двете настъпи по-късно, така че никакво изтриване няма да е дължимо години наред, но проследяването трябва да е правилно от самото начало.

Второ, правило 8(3) поставя долна граница: личните данни, данните за трафика и журналите за обработване се пазят поне една година от обработването. Примерът към правилото е поръчка на електронна книга, чиито данни трябва да оцелеят след изтриването на акаунта. Затова „изтрийте акаунта ми" не може да означава DELETE FROM users. Означава: спрете обработването, преместете това, което трябва да се пази, в хранилище с ограничен достъп и дата на изтичане и го изтрийте, когато датата мине. Всяка таблица трябва да има клас на съхранение, както и всяко копие в резервните копия, склада за данни и системите на обработващите ви.

Искания за права и данни за контакт (правила 9 и 14)

Потребителите могат да поискат обобщение на данните си и на обработването, както и самоличността на всеки администратор и обработващ, с когото сте ги споделили (раздел 11), да поискат коригиране, допълване, актуализиране или изтриване (раздел 12) и да посочат човек, който да действа от тяхно име при смърт или неспособност (раздел 14). Правило 14 изисква да публикувате как се подава искане и какъв идентификатор ви е нужен, както и да отговаряте на жалби в публикуван срок, не по-дълъг от деветдесет дни. Правило 9 изисква във всеки отговор да има данни за контакт с вашето длъжностно лице по защита на данните (Data Protection Officer) или с човек, който може да отговаря на въпроси.

Какво да изградите: приемане на искания в приложението, проверка на самоличността, свързана с акаунта, система за проследяване на случаите, която отброява деветдесетте дни, експорт, който намира данните на потребителя във всички услуги, и регистър на споделянето, така че „с кого сте ги споделили" да е заявка, а не разследване.

Деца и хора с увреждания (правила 10 до 12)

Според закона дете е всяко лице под осемнадесет години. Преди да обработвате данни на дете, ви трябва проверимо съгласие от родител, а правило 10 изисква да проверите, че родителят е пълнолетно лице, което може да бъде идентифицирано. Проверката може да използва данни за самоличност и възраст, които вече имате за регистриран родител, данни, предоставени от родителя, или „виртуален токен, свързан с тези данни" от упълномощен субект, включително доставчик на услуга Digital Locker. DigiLocker на MeitY публикува API за заявители за организации, които изтеглят проверени документи; нека юристът ви потвърди кои източници отговарят на правилото за вашите процеси.

Раздел 9(3) забранява проследяването, наблюдението на поведението и насочената реклама, насочени към деца. За потребителско приложение това е проблем на SDK, а безопасното решение по подразбиране е да изключите аналитичните и рекламните SDK за всеки акаунт, отбелязан като непълнолетен, вместо да ги настройвате така, че да станат съвместими.

Правило 11 се отнася до законните настойници на хора с увреждания: проверявате, че настойникът е назначен от съд, от определен орган или от местна комисия. Това е качване на документ и опашка за ръчен преглед. Според индийски адвокатски кантори през октомври 2026 г. MeitY е издало заповед по раздел 43 от закона, Digital Personal Data Protection (Removal of Difficulties) Order, 2026 (S.O. 5458(E)), която поправя раздел 9(1) да гласи „дете или лице с увреждане". Задължението за проверимо съгласие вече недвусмислено обхваща данните на лице с увреждане, както и тези на дете. Поправката е описана като редакционна и не добавя стъпка към този процес.

Правило 12 и Четвъртото приложение освобождават част от обработването от изискването за родителско съгласие и от забраната за проследяване, сред тях здравеопазването, образователните институции (за образователни дейности и безопасност), местоположението в реално време с цел безопасност и потвърждаването, че потребителят не е дете. Едтех компания не бива да приема, че се смята за „образователна институция". Получете отговор на този въпрос писмено.

Значими администратори на данни (правило 13)

Ако правителството ви определи като Significant Data Fiduciary (значим администратор на данни), правило 13 добавя ежегодна оценка на въздействието върху защитата на данните и одит с доклад до Съвета, комплексна проверка, че алгоритмичният ви софтуер не застрашава правата на потребителите, и съхраняване в Индия на всички лични данни, които правителството посочи. Раздел 10 от закона добавя длъжностно лице по защита на данните, базирано в Индия, и независим одитор на данни. Според информациите същата заповед заменя „одит" с „одит на данните" в раздел 10(2)(c)(ii), което обвързва периодичния одит с работата на този одитор. Датата също може да се промени: през януари 2026 г. Business Standard съобщи, че MeitY е предложило да съкрати срока за някои разпоредби, сред тях и правило 13, от 18 на 12 месеца. Към 10 октомври 2026 г. не открихме обнародван акт с такава промяна, така че 13 май 2027 г. остава в сила.

Колко струва грешката

Приложението към закона определя максималните санкции: до 250 крора рупии при липса на разумни предпазни мерки за сигурност, до 200 крора при неуведомяване за пробив, до 200 крора при нарушаване на задълженията за данни на деца, до 150 крора за допълнителните задължения на значим администратор на данни и до 50 крора при нарушаване на всяка друга разпоредба.

План за седем месеца

Октомври 2026 г.: опис. Избройте всяко хранилище и всеки конвейер с лични данни на потребители от Индия, включително резервните копия, склада за данни, журналите и обработващите. Свържете всяко поле с цел. Отбележете потребителите деца, проверете праговете от Третото приложение и поискайте становището на юриста ви за обхвата и изключенията.

Ноември 2026 г.: проектиране. Модел на съдържанието на уведомленията и версиониране, схема на регистъра на съгласията, класове на съхранение за всяка таблица, процес за исканията за права. Започнете журналите за достъп. След около 13 ноември следете Съвета за регистрирани Consent Managers и за стандарта за оперативна съвместимост.

Декември 2026 г. до януари 2027 г.: уведомления и съгласие. Пуснете услугата за съгласие, като събитията за оттегляне се разпращат до обработващите. Преведете уведомленията.

Февруари 2027 г.: съхранение и изтриване. Хранилище с ограничен достъп за съхраняваните данни, задачи за изтриване в основните хранилища и при обработващите и проследяване на неактивността, ако попадате в категория от Третото приложение. Изменете договорите с обработващите заради предпазните мерки и едногодишното съхранение.

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

Април 2027 г.: деца и съществуващи потребители. Проверка на възрастта, проверка на родителите, изключване на SDK за непълнолетни, преглед на настойниците. Изпратете уведомлението по раздел 5(2) до съществуващите потребители. Интегрирайте се с Consent Managers, ако стандартът е излязъл.

Началото на май 2027 г.: тестване и замразяване. Оттеглете съгласие и проверете, че маркетинговата платформа е спряла. Поискайте изтриване и проверете, че копието в склада за данни е преминало в режим на съхранение. Съберете доказателствата и спрете промените през седмицата преди 13 май.

Планът предполага три или четири паралелни направления. При по-стари или недокументирани системи само описът отнема повече от месец.

Къде се вписва това

Ако сте изграждали системите си съобразно ОРЗД, добра част от основата се пренася и нашето инженерно ръководство за ОРЗД описва моделите за съгласие и изтриване. Разликите, които ще ви затруднят, са описанието по позиции в уведомлението, минималният срок на съхранение от една година и проверимото родителско съгласие до осемнадесетгодишна възраст. За друг азиатски пазар със собствен режим вижте регистрацията PSE в Индонезия.

Вграждаме в съществуващи продукти услуги за съгласие, задачи за съхранение и изтриване, журнали за достъп и процеси за исканията за права, а когато планът изисква повече хора, отколкото имате, добавяме инженери към екипа ви чрез разширяване на екипа (staff augmentation). Ние сме инженери, не юристи: обхватът и формулировките са работа на юриста ви, а ние изграждаме според неговия отговор. Пишете ни на office@c9group.dev.