Le DPDP Rules indiane: il lavoro di sviluppo da completare entro maggio 2027

L'India ha notificato le Digital Personal Data Protection Rules, 2025 il 13 novembre 2025, come G.S.R. 846(E). La maggior parte delle norme che toccano il vostro prodotto non è ancora in vigore. La regola 1(4) dice che le regole 3, da 5 a 16, 22 e 23 «entrano in vigore diciotto mesi dopo la data di pubblicazione in questa Gazzetta». Contate diciotto mesi e arrivate al 13 maggio 2027, poco più di sette mesi da oggi.

Quelle regole riguardano informative, sicurezza, notifica delle violazioni, conservazione e cancellazione, dati dei minori e richieste di esercizio dei diritti. La regola 4, che consente ai Consent Manager di registrarsi presso il Data Protection Board, arriva prima: un anno dopo la pubblicazione, quindi intorno al 13 novembre 2026. L'annuncio del governo parla di un calendario per fasi di 18 mesi.

Questo articolo è per CTO e responsabili di prodotto di app consumer, fintech, edtech e aziende di e-commerce indiane, e di aziende estere con utenti indiani. La legge si applica anche ai trattamenti svolti fuori dall'India quando avvengono «in relazione a qualsiasi attività legata all'offerta di beni o servizi agli interessati nel territorio dell'India» (sezione 3(b)). Quello che segue è il software che dovete costruire o modificare. Non è un'analisi legale delle lacune: se rientrate nell'ambito, quali esenzioni si applicano e come sono formulate le vostre finalità sono domande per i vostri legali.

Chi ha davvero lavoro di sviluppo

Se tutti i dati dei vostri clienti stanno in un'unica piattaforma SaaS pacchettizzata, buona parte dell'infrastruttura (cifratura, log di accesso, job di cancellazione) arriva dalla roadmap del fornitore. Il vostro lavoro sono informative, configurazione e contratti. Leggeteli, quei contratti: la regola 6(1)(f) vuole le misure di sicurezza scritte nei contratti, e un esempio illustrativo della regola 8 vi rende responsabili del fatto che il vostro fornitore cloud conservi dati e log per l'anno richiesto.

Il lavoro pesante ricade sulle aziende che gestiscono app e database propri, alimentano un data warehouse con una dozzina di pipeline e includono SDK di terzi nel client mobile. Cioè la maggior parte dell'internet consumer indiano.

Cosa chiede al vostro software ciascuna regola

Informativa (regola 3)

L'informativa deve essere «comprensibile indipendentemente da qualsiasi altra informazione» che pubblicate. Come minimo fornisce «una descrizione dettagliata voce per voce di tali dati personali», la finalità specificata e una descrizione specifica dei beni, servizi o usi che il trattamento consente. Deve anche spiegare come revocare il consenso, esercitare i diritti e presentare reclamo al Board.

In pratica:

• Generate le informative da un inventario dei dati. Campo per campo, collegato alle finalità. «Potremmo raccogliere informazioni come» non è una descrizione voce per voce.
• Gestite le versioni di ogni informativa. Ogni registrazione di consenso deve puntare al testo esatto che l'utente ha visto.
• Pianificate le lingue. La sezione 6(3) della legge impone la possibilità di leggere una richiesta di consenso in inglese o in una qualsiasi delle lingue dell'Ottavo allegato della Costituzione. Tenete i contenuti delle informative come stringhe traducibili, non come PDF.
• Coprite gli utenti esistenti. La sezione 5(2) impone di inviare un'informativa, «non appena ragionevolmente possibile», a chi ha dato il consenso prima dell'entrata in vigore della legge. È una campagna verso l'intera base utenti.

Consenso, revoca e Consent Manager

Il consenso ai sensi della sezione 6 deve essere specifico e limitato ai dati necessari alla finalità. La sezione 6(10) mette l'onere della prova su di voi: in caso di controversia, siete voi a dimostrare che l'informativa è stata data e il consenso ottenuto. È per questa frase che vi serve un registro dei consensi e non una colonna booleana.

Un registro funzionante annota, per utente e finalità: versione dell'informativa, marca temporale, canale (web, app, Consent Manager) e azione (consenso dato o revocato). Solo in aggiunta.

La revoca deve essere facile quanto il consenso (regola 3(c)(i), sezione 6(4)). Se il consenso era un tocco durante l'onboarding, la revoca non può essere un'email all'assistenza. E deve viaggiare. La sezione 6(6) impone di cessare il trattamento, e di farlo cessare ai vostri responsabili del trattamento (Data Processor), entro un tempo ragionevole. Quindi il servizio dei consensi pubblica gli eventi di revoca verso ogni sistema e fornitore che agisce su quella finalità: CRM, piattaforma di marketing, pipeline di analisi.

Un Consent Manager è un punto di contatto unico registrato tramite cui un utente può «dare, gestire, rivedere o revocare il proprio consenso» (sezione 6(7)). Secondo il Primo allegato deve essere una società costituita in India con un patrimonio netto di almeno due crore di rupie (20 milioni di rupie), la sua piattaforma deve essere certificata in modo indipendente rispetto agli standard pubblicati dal Board, non deve poter leggere i dati che instrada e conserva le registrazioni dei consensi per almeno sette anni.

Le regole lasciano quello standard al Board. Costruite adesso un percorso in ingresso, così che un consenso o una revoca in arrivo da una piattaforma esterna venga gestito esattamente come uno proveniente dalla vostra interfaccia, e impegnatevi su un formato di scambio solo quando il Board ne pubblicherà uno. La registrazione apre intorno al 13 novembre 2026, quindi realisticamente l'integrazione parte a inizio 2027.

Misure di sicurezza e log (regola 6)

L'elenco minimo: cifratura, offuscamento, mascheramento o tokenizzazione; controllo degli accessi sui sistemi coinvolti; «visibilità sugli accessi a tali dati personali, tramite log, monitoraggio e revisione adeguati»; backup che permettano di proseguire il trattamento dopo un incidente; e conservazione di «tali log e dati personali per un periodo di un anno».

Il requisito sui log è quello su cui la maggior parte dei sistemi è carente. I log di infrastruttura non vi dicono chi ha letto il record di quale cliente e da quale servizio, e quella risposta vi serve un anno dopo. Quindi: log degli accessi a livello applicativo su ogni archivio di dati personali, inviati in un luogo che i servizi non possono alterare, conservati per almeno un anno. Iniziate presto; estenderli a molti servizi richiede più tempo di qualsiasi singola funzionalità di questo elenco.

Notifica delle violazioni (regola 7)

Quando venite a conoscenza di una violazione, informate ogni utente coinvolto «senza ritardo», tramite l'account utente o un canale di contatto registrato: cosa è successo, le probabili conseguenze per lui, cosa state facendo, cosa può fare lui e chi contattare. Il Board riceve una descrizione senza ritardo, poi entro 72 ore una relazione dettagliata su cause, mitigazione, eventuali elementi su chi l'ha causata, misure correttive e comunicazioni inviate agli utenti. Il Board può concedere più tempo su richiesta scritta.

In termini di software: un modo per calcolare l'insieme degli interessati (che dipende dai log di accesso descritti sopra), modelli scritti in anticipo, un percorso di notifica che non passi dal sistema violato e un runbook che indichi chi presenta la comunicazione al Board.

Cancellazione e conservazione (regola 8)

La sezione 8(7) impone la cancellazione quando il consenso viene revocato o la finalità non è più perseguita, salvo che un'altra legge imponga la conservazione. La regola 8 aggiunge due cose.

Primo, tre categorie del Terzo allegato vanno incontro a una cessazione presunta della finalità dopo tre anni senza contatti: entità di e-commerce con almeno due crore (20 milioni) di utenti registrati in India, intermediari di gioco online con almeno cinquanta lakh (5 milioni) e intermediari di social media con almeno due crore (20 milioni). Fanno eccezione l'accesso all'account e i token a valore memorizzato. Dovete avvisare l'utente almeno 48 ore prima della cancellazione, e un accesso la annulla. Servono un tracciatore dell'inattività, uno scheduler e un job di notifica. I tre anni decorrono dall'ultimo contatto o dall'entrata in vigore delle regole, se successiva, quindi per anni non sarà dovuta alcuna cancellazione, ma il tracciamento deve essere corretto fin dall'inizio.

Secondo, la regola 8(3) fissa un minimo: dati personali, dati di traffico e log di trattamento si conservano per almeno un anno dal trattamento. L'esempio illustrativo della regola è un ordine di e-book i cui dettagli devono sopravvivere alla cancellazione dell'account. Quindi «cancella il mio account» non può significare DELETE FROM users. Significa: fermare il trattamento, spostare ciò che va conservato in un archivio riservato con una data di scadenza, e cancellarlo quando la data passa. Ogni tabella ha bisogno di una classe di conservazione, e così ogni copia nei backup, nel data warehouse e nei sistemi dei vostri responsabili del trattamento.

Richieste di esercizio dei diritti e recapiti (regole 9 e 14)

Gli utenti possono chiedere un riepilogo dei propri dati e dei trattamenti e l'identità di ogni titolare e responsabile con cui li avete condivisi (sezione 11), chiederne la rettifica, l'integrazione, l'aggiornamento o la cancellazione (sezione 12) e nominare qualcuno che agisca per loro in caso di morte o incapacità (sezione 14). La regola 14 impone di pubblicare come presentare una richiesta e quale identificativo vi serve, e di rispondere ai reclami entro un termine pubblicato non superiore a novanta giorni. La regola 9 impone di indicare in ogni risposta i recapiti del vostro Data Protection Officer, o di qualcuno in grado di rispondere.

Da costruire: raccolta delle richieste nell'app, verifica dell'identità legata all'account, un sistema di gestione dei casi con il conteggio dei novanta giorni, un'esportazione che trovi i dati di un utente in tutti i servizi e un registro delle condivisioni, così che «con chi li avete condivisi» sia una query e non un'indagine.

Minori e persone con disabilità (regole da 10 a 12)

Per la legge è minore chiunque abbia meno di diciotto anni. Prima di trattare i dati di un minore vi serve il consenso verificabile di un genitore, e la regola 10 impone di verificare che il genitore sia un adulto identificabile. La verifica può usare i dati di identità ed età che avete già per un genitore registrato, dati forniti dal genitore stesso o «un token virtuale associato a tali dati» rilasciato da un soggetto autorizzato, tra cui un fornitore di servizi Digital Locker. DigiLocker, del MeitY, pubblica API per i richiedenti destinate alle organizzazioni che acquisiscono documenti verificati; fate confermare ai vostri legali quali fonti soddisfano la regola per i vostri flussi.

La sezione 9(3) vieta il tracciamento, il monitoraggio comportamentale e la pubblicità mirata rivolti ai minori. Per un'app consumer è un problema di SDK, e la scelta predefinita sicura è spegnere gli SDK di analisi e pubblicità per ogni account contrassegnato come minore, anziché configurarli fino a renderli conformi.

La regola 11 riguarda i tutori legali delle persone con disabilità: verificate che il tutore sia stato nominato da un tribunale, da un'autorità designata o da un comitato locale. Servono un caricamento di documenti e una coda di revisione manuale.

La regola 12 e il Quarto allegato esentano alcuni trattamenti dall'obbligo di consenso dei genitori e dal divieto di tracciamento, tra cui sanità, istituti di istruzione (per le attività didattiche e la sicurezza), localizzazione in tempo reale per la sicurezza e verifica che un utente non sia minore. Un'edtech non deve dare per scontato di valere come «istituto di istruzione». Fatevi dare la risposta per iscritto.

Significant Data Fiduciary (regola 13)

Se il governo vi designa come Significant Data Fiduciary, la regola 13 aggiunge una valutazione d'impatto sulla protezione dei dati e un audit annuali con relazione al Board, la verifica che il vostro software algoritmico non metta a rischio i diritti degli utenti e la conservazione in India dei dati personali indicati dal governo. La sezione 10 della legge aggiunge un Data Protection Officer con sede in India e un revisore indipendente dei dati.

Quanto costa sbagliare

L'allegato alla legge fissa le sanzioni massime: fino a 250 crore di rupie (2,5 miliardi) per la mancata adozione di misure di sicurezza ragionevoli, fino a 200 crore per la mancata notifica di una violazione, fino a 200 crore per la violazione degli obblighi sui dati dei minori, fino a 150 crore per gli obblighi aggiuntivi di un Significant Data Fiduciary e fino a 50 crore per la violazione di qualsiasi altra disposizione.

Un piano di sette mesi

Ottobre 2026: inventario. Elencate ogni archivio e pipeline che contiene dati personali di utenti indiani, compresi backup, data warehouse, log e responsabili del trattamento. Collegate ogni campo a una finalità. Segnalate gli utenti minori, verificate le soglie del Terzo allegato e chiedete ai legali un parere su ambito ed esenzioni.

Novembre 2026: progettazione. Modello dei contenuti delle informative e gestione delle versioni, schema del registro dei consensi, classi di conservazione per tabella, flusso delle richieste di esercizio dei diritti. Avviate i log degli accessi. Dopo il 13 novembre circa, seguite il Board per i Consent Manager registrati e lo standard di interoperabilità.

Da dicembre 2026 a gennaio 2027: informative e consenso. Rilasciate il servizio dei consensi, con gli eventi di revoca distribuiti ai responsabili del trattamento. Traducete le informative.

Febbraio 2027: conservazione e cancellazione. Archivio riservato per la conservazione, job di cancellazione sugli archivi primari e presso i responsabili del trattamento, e il tracciatore dell'inattività se rientrate in una categoria del Terzo allegato. Modificate i contratti con i responsabili del trattamento per le misure di sicurezza e la conservazione di un anno.

Marzo 2027: diritti e violazioni. Raccolta delle richieste, verifica, gestione dei casi con il termine di novanta giorni, esportazione trasversale ai servizi, registro delle condivisioni. Runbook per le violazioni, modelli e un percorso di notifica indipendente, poi una simulazione a tavolino.

Aprile 2027: minori e utenti esistenti. Verifica dell'età, verifica dei genitori, disattivazione degli SDK per i minori, revisione dei tutori. Inviate agli utenti esistenti l'informativa della sezione 5(2). Integratevi con i Consent Manager se lo standard è uscito.

Inizio maggio 2027: test e congelamento. Revocate un consenso e verificate che la piattaforma di marketing si sia fermata. Chiedete una cancellazione e verificate che la copia nel data warehouse sia passata in conservazione. Raccogliete le prove e smettete di modificare qualsiasi cosa nella settimana prima del 13 maggio.

Questo piano presuppone tre o quattro filoni di lavoro in parallelo. Su sistemi più vecchi o non documentati, il solo inventario richiede più di un mese.

Dove si colloca

Se avete costruito per il GDPR, buona parte dell'infrastruttura si riutilizza, e la nostra guida tecnica al GDPR tratta gli schemi di consenso e cancellazione. Le differenze che fanno male sono l'informativa voce per voce, il minimo di conservazione di un anno e il consenso verificabile dei genitori fino ai diciotto anni. Per un altro mercato asiatico con un regime proprio, vedete la registrazione PSE in Indonesia.

Integriamo in prodotti esistenti servizi dei consensi, job di conservazione e cancellazione, log degli accessi e flussi per le richieste di esercizio dei diritti, e aggiungiamo ingegneri al vostro team tramite la staff augmentation quando il piano richiede più braccia di quante ne abbiate. Siamo ingegneri, non avvocati: ambito e formulazioni spettano ai vostri legali, e noi sviluppiamo sulla base della loro risposta. Scrivete a office@c9group.dev.