De Indiase DPDP Rules: het technische werk dat uiterlijk mei 2027 af moet zijn

India publiceerde de Digital Personal Data Protection Rules, 2025 op 13 november 2025, als G.S.R. 846(E). De meeste regels die uw product raken, zijn nog niet van kracht. Regel 1(4) bepaalt dat de regels 3, 5 tot en met 16, 22 en 23 “in werking treden achttien maanden na de datum van publicatie in deze Gazette”. Tel achttien maanden en u komt uit op 13 mei 2027, iets meer dan zeven maanden vanaf vandaag.

Die regels dekken kennisgevingen, beveiliging, het melden van datalekken, bewaring en verwijdering, gegevens van kinderen en verzoeken van betrokkenen. Regel 4, waarmee Consent Managers zich bij de Data Protection Board kunnen registreren, komt eerder: een jaar na publicatie, dus rond 13 november 2026. De aankondiging van de overheid spreekt van een gefaseerde tijdlijn van 18 maanden.

Dit artikel is voor CTO's en productverantwoordelijken bij Indiase consumentenapps, fintechs, edtechs en e-commercebedrijven, en bij buitenlandse bedrijven met Indiase gebruikers. De wet reikt tot verwerking buiten India als die plaatsvindt “in verband met een activiteit die te maken heeft met het aanbieden van goederen of diensten aan Data Principals op het grondgebied van India” (sectie 3(b)). Wat volgt, is de software die u moet bouwen of aanpassen. Het is geen juridische gapanalyse: of u eronder valt, welke uitzonderingen gelden en hoe uw doeleinden zijn geformuleerd, zijn vragen voor uw juristen.

Wie echt bouwwerk heeft

Staan al uw klantgegevens in één standaard-SaaS-platform, dan komt veel van het loodgieterswerk (versleuteling, toegangslogs, verwijderingstaken) uit de roadmap van de leverancier. Uw werk bestaat uit kennisgevingen, configuratie en contracten. Lees die contracten: regel 6(1)(f) wil dat beveiligingsmaatregelen erin worden vastgelegd, en een toelichtend voorbeeld bij regel 8 maakt u verantwoordelijk voor het bewaren van gegevens en logs door uw cloudleverancier gedurende het vereiste jaar.

Het zware werk ligt bij bedrijven die hun eigen apps en databases draaien, een datawarehouse vullen vanuit een dozijn pijplijnen en SDK's van derden in de mobiele client meeleveren. Dat is het grootste deel van het Indiase consumenteninternet.

Wat elke regel van uw software vraagt

Kennisgeving (regel 3)

De kennisgeving moet “op zichzelf begrijpelijk zijn, los van andere informatie” die u publiceert. Ze geeft minimaal “een gespecificeerde beschrijving van die persoonsgegevens”, het specifieke doel, en een specifieke beschrijving van de goederen, diensten of toepassingen die de verwerking mogelijk maakt. Ze moet ook vermelden hoe toestemming kan worden ingetrokken, hoe rechten kunnen worden uitgeoefend en hoe een klacht bij de Board kan worden ingediend.

In de praktijk:

• Genereer kennisgevingen uit een data-inventaris. Veld voor veld, gekoppeld aan doeleinden. “Wij kunnen informatie verzamelen zoals” is niet gespecificeerd.
• Geef elke kennisgeving een versie. Elk toestemmingsrecord moet verwijzen naar de exacte tekst die de gebruiker zag.
• Plan voor talen. Sectie 6(3) van de wet eist de mogelijkheid een toestemmingsverzoek te lezen in het Engels of in een van de talen uit de Achtste Bijlage bij de grondwet. Houd de inhoud van kennisgevingen bij als vertaalbare strings, niet als pdf.
• Dek bestaande gebruikers. Sectie 5(2) eist een kennisgeving, “zodra dat redelijkerwijs mogelijk is”, aan mensen die toestemming gaven voordat de wet in werking trad. Dat is een campagne naar uw hele gebruikersbestand.

Toestemming, intrekking en Consent Managers

Toestemming op grond van sectie 6 moet specifiek zijn en beperkt tot de gegevens die het doel nodig heeft. Sectie 6(10) legt de bewijslast bij u: in een geschil toont u aan dat een kennisgeving is gegeven en toestemming is verkregen. Om die zin hebt u een toestemmingsregister nodig in plaats van een booleaanse kolom.

Een werkbaar register legt per gebruiker en doel vast: de versie van de kennisgeving, het tijdstip, het kanaal (web, app, Consent Manager) en de handeling (gegeven of ingetrokken). Alleen toevoegen, nooit wijzigen.

Intrekken moet even makkelijk zijn als toestemming geven (regel 3(c)(i), sectie 6(4)). Was de toestemming één tik tijdens de onboarding, dan kan intrekken geen e-mail aan support zijn. De intrekking moet ook doorreizen. Sectie 6(6) eist dat u binnen een redelijke termijn stopt met verwerken, en dat u uw Data Processors laat stoppen. De toestemmingsdienst publiceert dus intrekkingsgebeurtenissen naar elk systeem en elke leverancier die voor dat doel werkt: CRM, marketingplatform, analysepijplijn.

Een Consent Manager is een geregistreerd centraal aanspreekpunt via welk een gebruiker “haar toestemming kan geven, beheren, bekijken of intrekken” (sectie 6(7)). Volgens de Eerste Bijlage moet dat een in India opgerichte vennootschap zijn met een eigen vermogen van ten minste twee crore roepie, moet het platform onafhankelijk zijn gecertificeerd tegen normen die de Board publiceert, mag de Consent Manager de gegevens die hij doorgeeft niet kunnen lezen, en bewaart hij toestemmingsrecords ten minste zeven jaar.

De regels laten die norm aan de Board over. Bouw nu een inkomend pad, zodat een toestemming of intrekking die van een extern platform binnenkomt precies zo wordt afgehandeld als een die uit uw eigen UI komt, en leg u pas vast op een berichtformaat zodra de Board er een publiceert. De registratie opent rond 13 november 2026, dus de integratie begint realistisch gezien begin 2027.

Beveiligingsmaatregelen en logs (regel 6)

De minimumlijst: versleuteling, verhulling, maskering of tokenisatie; toegangsbeheer op de betrokken systemen; “zicht op de toegang tot die persoonsgegevens, door middel van passende logs, monitoring en controle”; back-ups zodat de verwerking na een incident kan doorgaan; en het bewaren van “die logs en persoonsgegevens gedurende een periode van een jaar”.

Op de logeis schieten de meeste systemen tekort. Infrastructuurlogs vertellen u niet wie welk klantrecord vanuit welke dienst heeft gelezen, en dat antwoord hebt u een jaar later nog nodig. Dus: toegangslogging op applicatieniveau bij elke opslag van persoonsgegevens, verstuurd naar een plek die diensten niet kunnen wijzigen, en ten minste een jaar bewaard. Begin vroeg; het uitrollen over veel diensten duurt langer dan welke functie hier ook.

Melden van datalekken (regel 7)

Zodra u van een datalek op de hoogte bent, licht u elke getroffen gebruiker “onverwijld” in, via het gebruikersaccount of een geregistreerd contactkanaal: wat er is gebeurd, de waarschijnlijke gevolgen voor hem, wat u doet, wat hij kan doen en met wie hij contact kan opnemen. De Board krijgt onverwijld een beschrijving, en daarna binnen 72 uur een gedetailleerd verslag over oorzaken, mitigatie, eventuele bevindingen over wie het lek veroorzaakte, herstelmaatregelen en de verstuurde meldingen aan gebruikers. De Board kan op schriftelijk verzoek meer tijd toestaan.

In software: een manier om de getroffen groep te bepalen (die afhangt van de toegangslogs hierboven), vooraf geschreven sjablonen, een meldingspad dat niet door het getroffen systeem loopt, en een runbook dat noemt wie de melding bij de Board indient.

Verwijdering en bewaring (regel 8)

Sectie 8(7) eist verwijdering wanneer toestemming wordt ingetrokken of het doel niet meer wordt gediend, tenzij een andere wet bewaring vereist. Regel 8 voegt daar twee dingen aan toe.

Ten eerste geldt voor drie klassen uit de Derde Bijlage een fictief einde van het doel na drie jaar zonder contact: e-commerce-entiteiten met ten minste twee crore geregistreerde gebruikers in India, online-gamingintermediairs met ten minste vijftig lakh, en socialemedia-intermediairs met ten minste twee crore. Toegang tot het account en tokens met opgeslagen waarde zijn uitgezonderd. U moet de gebruiker ten minste 48 uur vóór de verwijdering waarschuwen, en inloggen annuleert haar. Dat vraagt om een inactiviteitstracker, een planner en een meldingstaak. De drie jaar lopen vanaf het laatste contact of vanaf de inwerkingtreding van de regels, als dat later is, dus er is jarenlang geen verwijdering verschuldigd, maar de tracking moet vanaf het begin kloppen.

Ten tweede legt regel 8(3) een ondergrens vast: persoonsgegevens, verkeersgegevens en verwerkingslogs worden ten minste een jaar na de verwerking bewaard. Het voorbeeld bij de regel is een bestelling van een e-book waarvan de gegevens het verwijderen van het account moeten overleven. “Verwijder mijn account” kan dus niet DELETE FROM users betekenen. Het betekent: stop met verwerken, verplaats wat bewaard moet blijven naar een afgeschermde opslag met een bewaardatum, en verwijder het als die datum verstreken is. Elke tabel heeft een bewaarklasse nodig, en elke kopie in back-ups, het datawarehouse en de systemen van uw verwerkers ook.

Verzoeken en contactgegevens (regels 9 en 14)

Gebruikers kunnen vragen om een overzicht van hun gegevens en de verwerking, en om de identiteit van elke fiduciary en verwerker met wie u ze hebt gedeeld (sectie 11), om correctie, aanvulling, bijwerking of verwijdering vragen (sectie 12), en iemand aanwijzen die bij overlijden of handelingsonbekwaamheid namens hen optreedt (sectie 14). Regel 14 eist dat u publiceert hoe een verzoek kan worden ingediend en welke identificatie u nodig hebt, en dat u klachten beantwoordt binnen een gepubliceerde termijn van maximaal negentig dagen. Regel 9 eist dat in elk antwoord de contactgegevens staan van uw Data Protection Officer, of van iemand die vragen kan beantwoorden.

Te bouwen: indienen van verzoeken in de app, identiteitsverificatie gekoppeld aan het account, een dossiertracker die de termijn van negentig dagen bewaakt, een export die de gegevens van een gebruiker over alle diensten heen vindt, en een register van gedeelde gegevens, zodat “met wie hebt u het gedeeld” een query is in plaats van een onderzoek.

Kinderen en personen met een beperking (regels 10 tot en met 12)

Volgens de wet is een kind iedereen onder de achttien. Voordat u gegevens van een kind verwerkt, hebt u de verifieerbare toestemming van een ouder nodig, en regel 10 eist dat u controleert of de ouder een identificeerbare volwassene is. Die controle kan gebruikmaken van identiteits- en leeftijdsgegevens die u al hebt van een geregistreerde ouder, van gegevens die de ouder verstrekt, of van “een virtueel token dat aan die gegevens is gekoppeld” van een geautoriseerde entiteit, waaronder een aanbieder van een Digital Locker-dienst. DigiLocker van MeitY publiceert API's voor aanvragers voor organisaties die geverifieerde documenten ophalen; laat uw juristen bevestigen welke bronnen voor uw stromen aan de regel voldoen.

Sectie 9(3) verbiedt tracking, gedragsmonitoring en gerichte reclame die op kinderen is gericht. Voor een consumentenapp is dat een SDK-probleem, en de veilige standaard is analyse- en advertentie-SDK's uit te schakelen voor elk account dat als minderjarig is gemarkeerd, in plaats van ze zo te configureren dat ze voldoen.

Regel 11 gaat over wettelijke vertegenwoordigers van personen met een beperking: u controleert of de vertegenwoordiger is benoemd door een rechter, een aangewezen instantie of een lokale commissie. Dat is een documentupload en een wachtrij voor handmatige beoordeling.

Regel 12 en de Vierde Bijlage zonderen sommige verwerkingen uit van de eis van ouderlijke toestemming en het trackingverbod, waaronder gezondheidszorg, onderwijsinstellingen (voor onderwijsactiviteiten en veiligheid), realtime locatie voor de veiligheid, en de bevestiging dat een gebruiker geen kind is. Een edtech moet er niet van uitgaan dat hij als “onderwijsinstelling” telt. Laat dat schriftelijk beantwoorden.

Significant Data Fiduciaries (regel 13)

Wijst de overheid u aan als Significant Data Fiduciary, dan voegt regel 13 een jaarlijkse Data Protection Impact Assessment en audit toe met een verslag aan de Board, zorgvuldigheidsonderzoek dat uw algoritmische software de rechten van gebruikers niet in gevaar brengt, en het binnen India houden van persoonsgegevens die de overheid aanwijst. Sectie 10 van de wet voegt daar een Data Protection Officer met standplaats in India en een onafhankelijke data-auditor aan toe.

Wat het kost als het misgaat

De bijlage bij de wet legt maximale boetes vast: tot 250 crore roepie voor het niet nemen van redelijke beveiligingsmaatregelen, tot 200 crore voor het niet melden van een datalek, tot 200 crore voor het schenden van de verplichtingen rond gegevens van kinderen, tot 150 crore voor de aanvullende verplichtingen van een Significant Data Fiduciary, en tot 50 crore voor schending van een andere bepaling.

Een plan van zeven maanden

Oktober 2026: inventarisatie. Maak een lijst van elke opslag en pijplijn met persoonsgegevens van Indiase gebruikers, inclusief back-ups, het datawarehouse, logs en verwerkers. Koppel elk veld aan een doel. Markeer gebruikers die kind zijn, controleer de drempels uit de Derde Bijlage, en vraag uw juristen om een oordeel over reikwijdte en uitzonderingen.

November 2026: ontwerp. Contentmodel en versiebeheer voor kennisgevingen, schema voor het toestemmingsregister, bewaarklassen per tabel, stroom voor verzoeken. Begin met toegangslogging. Houd na ongeveer 13 november de Board in de gaten voor geregistreerde Consent Managers en de interoperabiliteitsnorm.

December 2026 tot januari 2027: kennisgevingen en toestemming. Lever de toestemmingsdienst op, met intrekkingsgebeurtenissen die naar verwerkers worden doorgestuurd. Vertaal de kennisgevingen.

Februari 2027: bewaring en verwijdering. Afgeschermde bewaaropslag, verwijderingstaken over primaire opslag en verwerkers, en de inactiviteitstracker als u in een klasse uit de Derde Bijlage valt. Pas contracten met verwerkers aan voor beveiligingsmaatregelen en de bewaring van een jaar.

Maart 2027: rechten en datalekken. Indienen van verzoeken, verificatie, de dossiertracker voor negentig dagen, export over diensten heen, register van gedeelde gegevens. Runbook voor datalekken, sjablonen en een onafhankelijk meldingspad, en daarna één tabletopoefening.

April 2027: kinderen en bestaande gebruikers. Leeftijdscontrole, verificatie van ouders, SDK-schakelaars voor minderjarigen, beoordeling van vertegenwoordigers. Stuur de kennisgeving op grond van sectie 5(2) naar bestaande gebruikers. Integreer met Consent Managers als de norm er is.

Begin mei 2027: testen en bevriezen. Trek een toestemming in en controleer of het marketingplatform is gestopt. Vraag om verwijdering en controleer of de kopie in het datawarehouse in de bewaaropslag is beland. Stel het bewijs samen, en wijzig niets meer in de week vóór 13 mei.

Dit plan gaat uit van drie of vier parallelle sporen. Bij oudere of ongedocumenteerde systemen duurt alleen de inventarisatie al langer dan een maand.

Waar dit past

Hebt u voor de AVG gebouwd, dan gaat een flink deel van het loodgieterswerk mee, en onze technische AVG-gids behandelt de patronen voor toestemming en verwijdering. De verschillen die pijn doen, zijn de gespecificeerde kennisgeving, de ondergrens van een jaar bewaring en verifieerbare ouderlijke toestemming tot achttien jaar. Voor een andere Aziatische markt met een eigen regime, zie PSE-registratie in Indonesië.

Wij bouwen toestemmingsdiensten, bewaar- en verwijderingstaken, toegangslogging en workflows voor verzoeken in bestaande producten, en we voegen via staff augmentation engineers aan uw team toe als het plan meer handen vraagt dan u hebt. Wij zijn ingenieurs, geen juristen: reikwijdte en formuleringen horen bij uw juristen, en wij bouwen naar hun antwoord. Schrijf naar office@c9group.dev.