As DPDP Rules da Índia: o trabalho de engenharia com prazo em maio de 2027

A Índia publicou as Digital Personal Data Protection Rules, 2025 a 13 de novembro de 2025, como G.S.R. 846(E). A maior parte das regras que tocam no seu produto ainda não está em vigor. A regra 1(4) determina que as regras 3, 5 a 16, 22 e 23 «entram em vigor dezoito meses após a data de publicação desta Gazette». Contados dezoito meses, chega-se a 13 de maio de 2027, daqui a pouco mais de sete meses.

Essas regras tratam da informação aos titulares, da segurança, da comunicação de violações, da conservação e do apagamento, dos dados de crianças e dos pedidos de exercício de direitos. A regra 4, que permite aos Consent Managers registarem-se junto do Data Protection Board, chega mais cedo: um ano após a publicação, ou seja, por volta de 13 de novembro de 2026. O comunicado do governo fala de um calendário faseado de 18 meses.

Este texto é para CTO e responsáveis de produto de aplicações de consumo, fintechs, edtechs e empresas de comércio eletrónico indianas, e de empresas estrangeiras com utilizadores na Índia. A lei abrange o tratamento feito fora da Índia quando está «relacionado com qualquer atividade de oferta de bens ou serviços a Data Principals no território da Índia» (secção 3(b)). O que se segue é o software que tem de desenvolver ou alterar. Não é uma análise jurídica de lacunas: saber se está abrangido, que isenções se aplicam e como estão redigidas as suas finalidades são perguntas para o seu advogado.

Quem tem de facto trabalho de desenvolvimento

Se todos os dados dos seus clientes estão numa única plataforma SaaS de mercado, boa parte da infraestrutura (cifragem, registos de acesso, rotinas de apagamento) vem do roadmap do fornecedor. O seu trabalho são os avisos, a configuração e os contratos. Leia esses contratos: a regra 6(1)(f) exige que as salvaguardas de segurança lá fiquem escritas, e um exemplo da regra 8 torna-o responsável por o seu fornecedor de cloud guardar os dados e os registos durante o ano exigido.

O trabalho pesado recai sobre as empresas que gerem as suas próprias aplicações e bases de dados, alimentam um data warehouse a partir de uma dúzia de pipelines e incluem SDK de terceiros no cliente móvel. Ou seja, a maior parte da internet de consumo indiana.

O que cada regra pede ao seu software

Aviso (regra 3)

O aviso tem de ser «compreensível por si só, independentemente de qualquer outra informação» que publique. No mínimo, dá «uma descrição discriminada desses dados pessoais», a finalidade especificada e uma descrição concreta dos bens, serviços ou utilizações que o tratamento possibilita. Tem também de explicar como retirar o consentimento, exercer os direitos e apresentar queixa ao Board.

Na prática:

• Gere os avisos a partir de um inventário de dados. Campo a campo, associado a finalidades. «Podemos recolher informações como» não é uma descrição discriminada.
• Atribua uma versão a cada aviso. Cada registo de consentimento tem de apontar para o texto exato que o utilizador viu.
• Preveja as línguas. A secção 6(3) da lei exige a opção de ler um pedido de consentimento em inglês ou em qualquer língua do Eighth Schedule da Constituição. Guarde o conteúdo dos avisos como strings traduzíveis, não num PDF.
• Abranja os utilizadores existentes. A secção 5(2) exige um aviso, «logo que seja razoavelmente possível», às pessoas que deram consentimento antes da entrada em vigor da lei. Isso é uma campanha para toda a sua base de utilizadores.

Consentimento, retirada e Consent Managers

O consentimento nos termos da secção 6 tem de ser específico e limitado aos dados de que a finalidade precisa. A secção 6(10) põe o ónus da prova do seu lado: num litígio, é a sua empresa que demonstra que o aviso foi dado e o consentimento obtido. É por causa desta frase que precisa de um registo de consentimentos e não de uma coluna booleana.

Um registo que funcione guarda, por utilizador e por finalidade: a versão do aviso, a data e hora, o canal (web, aplicação, Consent Manager) e a ação (dado ou retirado). Só com acrescentos, nunca com alterações.

Retirar o consentimento tem de ser tão fácil como dá-lo (regra 3(c)(i), secção 6(4)). Se o consentimento foi um toque durante o onboarding, a retirada não pode ser um email para o suporte. E tem de chegar a todo o lado. A secção 6(6) obriga a deixar de tratar os dados, e a fazer com que os seus Data Processors deixem de o fazer, num prazo razoável. Por isso o serviço de consentimento publica os eventos de retirada para todos os sistemas e fornecedores que trabalham com essa finalidade: CRM, plataforma de marketing, pipeline de analítica.

Um Consent Manager é um ponto de contacto único e registado através do qual o utilizador pode «dar, gerir, rever ou retirar o seu consentimento» (secção 6(7)). Segundo o First Schedule, tem de ser uma sociedade constituída na Índia com capitais próprios de pelo menos dois crore de rupias (20 milhões), a sua plataforma tem de ser certificada de forma independente segundo normas que o Board publica, não pode conseguir ler os dados que encaminha e guarda os registos de consentimento durante pelo menos sete anos.

As regras deixam essa norma ao Board. Crie já um canal de entrada, para que um consentimento ou uma retirada vindos de uma plataforma externa sejam tratados exatamente como os que vêm da sua própria interface, e só se comprometa com um formato de mensagem quando o Board publicar um. As inscrições abrem por volta de 13 de novembro de 2026, por isso a integração deverá começar, realisticamente, no início de 2027.

Salvaguardas de segurança e registos (regra 6)

A lista mínima: cifragem, ofuscação, mascaramento ou tokenização; controlo de acessos nos sistemas envolvidos; «visibilidade sobre o acesso a esses dados pessoais, através de registos, monitorização e revisão adequados»; cópias de segurança para que o tratamento possa continuar depois de um incidente; e conservação «desses registos e dados pessoais durante um período de um ano».

É no requisito dos registos que a maior parte dos sistemas fica aquém. Os registos de infraestrutura não dizem quem leu o registo de que cliente a partir de que serviço, e vai precisar dessa resposta um ano depois. Portanto: registo de acessos ao nível da aplicação em todos os repositórios de dados pessoais, enviado para um sítio que os serviços não possam alterar e guardado durante pelo menos um ano. Comece cedo; implementá-lo em muitos serviços demora mais do que qualquer outra funcionalidade desta lista.

Comunicação de violações (regra 7)

Quando toma conhecimento de uma violação, informa cada utilizador afetado «sem demora», através da conta do utilizador ou de um canal de contacto registado: o que aconteceu, as consequências prováveis para ele, o que está a fazer, o que ele pode fazer e quem contactar. O Board recebe uma descrição sem demora e, no prazo de 72 horas, um relatório detalhado sobre as causas, a mitigação, as conclusões sobre quem a provocou, as medidas corretivas e as comunicações enviadas aos utilizadores. O Board pode conceder mais tempo mediante pedido escrito.

Em software: uma forma de calcular o conjunto de afetados (que depende dos registos de acesso acima), modelos redigidos de antemão, um canal de notificação que não passe pelo sistema comprometido e um runbook que diga quem faz a comunicação ao Board.

Apagamento e conservação (regra 8)

A secção 8(7) exige o apagamento quando o consentimento é retirado ou a finalidade deixa de ser servida, salvo se outra lei obrigar à conservação. A regra 8 acrescenta duas coisas.

Primeiro, três categorias do Third Schedule têm um fim de finalidade presumido ao fim de três anos sem contacto: entidades de comércio eletrónico com pelo menos dois crore (20 milhões) de utilizadores registados na Índia, intermediários de jogos online com pelo menos cinquenta lakh (5 milhões) e intermediários de redes sociais com pelo menos dois crore (20 milhões). O acesso à conta e os tokens de valor armazenado ficam excluídos. Tem de avisar o utilizador pelo menos 48 horas antes do apagamento, e um início de sessão cancela-o. Isso é um contador de inatividade, um agendador e uma tarefa de notificação. Os três anos contam a partir do último contacto ou da entrada em vigor das Rules, o que ocorrer mais tarde, pelo que nenhum apagamento será devido durante anos, mas a contagem tem de estar certa desde o início.

Segundo, a regra 8(3) fixa um mínimo: os dados pessoais, os dados de tráfego e os registos de tratamento são guardados durante pelo menos um ano a contar do tratamento. O exemplo da regra é uma encomenda de um livro eletrónico cujos dados têm de sobreviver ao apagamento da conta. Logo, «apagar a minha conta» não pode significar DELETE FROM users. Significa: parar o tratamento, passar o que tem de ser guardado para um repositório restrito com uma data de conservação e apagá-lo quando essa data passar. Cada tabela precisa de uma classe de conservação, e o mesmo vale para cada cópia nas cópias de segurança, no data warehouse e nos sistemas dos seus subcontratantes.

Pedidos de exercício de direitos e contactos (regras 9 e 14)

Os utilizadores podem pedir um resumo dos seus dados e do tratamento, bem como a identidade de todos os responsáveis e subcontratantes com quem os partilhou (secção 11), pedir a retificação, o completamento, a atualização ou o apagamento (secção 12) e designar alguém que aja em seu nome em caso de morte ou incapacidade (secção 14). A regra 14 obriga a publicar como se faz um pedido e que identificador é necessário, e a responder às reclamações num prazo publicado que não exceda noventa dias. A regra 9 exige os contactos do seu Data Protection Officer, ou de alguém que possa responder, em todas as respostas.

A desenvolver: receção de pedidos dentro da aplicação, verificação de identidade ligada à conta, um gestor de processos que controle o prazo de noventa dias, uma exportação que encontre os dados de um utilizador em todos os serviços e um registo de partilhas, para que «com quem os partilharam» seja uma consulta e não uma investigação.

Crianças e pessoas com deficiência (regras 10 a 12)

Nos termos da lei, criança é qualquer pessoa com menos de dezoito anos. Antes de tratar dados de uma criança, precisa do consentimento verificável de um dos pais, e a regra 10 exige que se confirme que esse pai ou mãe é um adulto identificável. A verificação pode usar dados de identidade e idade que já tenha de um progenitor registado, dados fornecidos pelo próprio ou «um token virtual associado a esses dados» emitido por uma entidade autorizada, o que inclui um prestador de serviços Digital Locker. O DigiLocker do MeitY publica APIs para requerentes destinadas a organizações que obtêm documentos verificados; peça ao seu advogado que confirme que fontes cumprem a regra nos seus fluxos.

A secção 9(3) proíbe o rastreio, a monitorização comportamental e a publicidade direcionada a crianças. Numa aplicação de consumo, isto é um problema de SDK, e a opção segura é desligar os SDK de analítica e de publicidade em qualquer conta marcada como de menor, em vez de os configurar até ficarem conformes.

A regra 11 trata dos tutores legais de pessoas com deficiência: tem de verificar que o tutor foi nomeado por um tribunal, por uma autoridade designada ou por um comité local. Isso é um carregamento de documento e uma fila de revisão manual. Segundo sociedades de advogados indianas, o MeitY emitiu em outubro de 2026, ao abrigo da secção 43 da lei, a Digital Personal Data Protection (Removal of Difficulties) Order, 2026 (S.O. 5458(E)), que corrige a secção 9(1) para passar a referir «uma criança ou uma pessoa com deficiência». O dever de consentimento verificável passa assim a abranger claramente os dados de uma pessoa com deficiência, além dos de uma criança. A alteração é descrita como uma correção de redação e não acrescenta nenhum passo a este fluxo.

A regra 12 e o Fourth Schedule isentam alguns tratamentos da exigência de consentimento parental e da proibição de rastreio, entre eles os cuidados de saúde, os estabelecimentos de ensino (para atividades educativas e de segurança), a localização em tempo real por razões de segurança e a confirmação de que um utilizador não é uma criança. Uma edtech não deve partir do princípio de que conta como «estabelecimento de ensino». Obtenha essa resposta por escrito.

Significant Data Fiduciaries (regra 13)

Se o governo o designar como Significant Data Fiduciary, a regra 13 acrescenta uma avaliação de impacto sobre a proteção de dados e uma auditoria anuais, com relatório ao Board, diligência devida para garantir que o seu software algorítmico não põe em risco os direitos dos utilizadores e a conservação na Índia dos dados pessoais que o governo indicar. A secção 10 da lei acrescenta um Data Protection Officer sediado na Índia e um auditor de dados independente. Segundo consta, a mesma ordem substitui «auditoria» por «auditoria de dados» na secção 10(2)(c)(ii), o que liga a auditoria periódica ao trabalho desse auditor. A data também pode mudar: em janeiro de 2026, o Business Standard noticiou que o MeitY tinha proposto encurtar o prazo de algumas disposições, entre elas a regra 13, de 18 para 12 meses. Até 10 de outubro de 2026 não encontrámos nenhuma notificação a concretizar essa alteração, por isso mantém-se 13 de maio de 2027.

Quanto custa falhar

O Schedule da lei fixa as coimas máximas: até 250 crore de rupias (2,5 mil milhões) por não adotar salvaguardas de segurança razoáveis, até 200 crore por não comunicar uma violação, até 200 crore por incumprir as obrigações relativas aos dados de crianças, até 150 crore pelas obrigações adicionais de um Significant Data Fiduciary e até 50 crore pela violação de qualquer outra disposição.

Um plano de sete meses

Outubro de 2026: inventário. Liste todos os repositórios e pipelines com dados pessoais de utilizadores indianos, incluindo cópias de segurança, o data warehouse, os registos e os subcontratantes. Associe cada campo a uma finalidade. Assinale os utilizadores menores, verifique os limiares do Third Schedule e peça ao seu advogado um parecer sobre âmbito e isenções.

Novembro de 2026: desenho. Modelo de conteúdo e versões dos avisos, esquema do registo de consentimentos, classes de conservação por tabela, fluxo dos pedidos de exercício de direitos. Comece o registo de acessos. Depois de 13 de novembro, mais ou menos, acompanhe o Board para saber que Consent Managers estão registados e qual é a norma de interoperabilidade.

Dezembro de 2026 a janeiro de 2027: avisos e consentimento. Ponha em produção o serviço de consentimento, com os eventos de retirada distribuídos pelos subcontratantes. Traduza os avisos.

Fevereiro de 2027: conservação e apagamento. Repositório de conservação restrito, rotinas de apagamento nos repositórios principais e nos subcontratantes e, se pertencer a uma categoria do Third Schedule, o contador de inatividade. Altere os contratos com os subcontratantes para incluir as salvaguardas e a conservação de um ano.

Março de 2027: direitos e violações. Receção de pedidos, verificação, gestor de processos com o prazo de noventa dias, exportação transversal aos serviços, registo de partilhas. Runbook de violações, modelos e um canal de notificação independente, seguidos de um exercício de simulação.

Abril de 2027: crianças e utilizadores existentes. Controlo de idade, verificação dos pais, desativação dos SDK para menores, revisão de tutores. Envie o aviso da secção 5(2) aos utilizadores existentes. Integre os Consent Managers se a norma já estiver publicada.

Início de maio de 2027: testes e congelamento. Retire um consentimento e confirme que a plataforma de marketing parou. Peça um apagamento e confirme que a cópia no data warehouse passou para conservação. Reúna as provas e deixe de mexer em tudo na semana anterior a 13 de maio.

Este plano pressupõe três ou quatro frentes em paralelo. Em sistemas mais antigos ou sem documentação, só o inventário demora mais de um mês.

Onde isto encaixa

Se desenvolveu para o RGPD, boa parte da infraestrutura aproveita-se, e o nosso guia de engenharia do RGPD cobre os padrões de consentimento e de apagamento. As diferenças que custam são o aviso discriminado, o mínimo de um ano de conservação e o consentimento parental verificável até aos dezoito anos. Para outro mercado asiático com regime próprio, veja o registo PSE na Indonésia.

Integramos serviços de consentimento, rotinas de conservação e apagamento, registo de acessos e fluxos de pedidos de exercício de direitos em produtos existentes, e reforçamos a sua equipa com engenheiros através de staff augmentation quando o plano precisa de mais mãos do que as que tem. Somos engenheiros, não juristas: o âmbito e a redação cabem ao seu advogado, e nós desenvolvemos de acordo com a resposta dele. Escreva para office@c9group.dev.