Indiens DPDP Rules: det tekniske arbejde, der skal være færdigt i maj 2027

Indien offentliggjorde Digital Personal Data Protection Rules, 2025 den 13. november 2025 som G.S.R. 846(E). De fleste af de regler, der berører jeres produkt, er endnu ikke trådt i kraft. Regel 1(4) siger, at reglerne 3, 5 til 16, 22 og 23 »træder i kraft atten måneder efter datoen for offentliggørelsen i denne Gazette«. Tæl atten måneder frem, og I lander på 13. maj 2027, lidt over syv måneder fra i dag.

De dækker oplysningspligt, sikkerhed, underretning om brud, opbevaring og sletning, børns data og anmodninger om rettigheder. Regel 4, der lader Consent Managers (samtykkeforvaltere) registrere sig hos Data Protection Board, kommer tidligere: et år efter offentliggørelsen, altså omkring 13. november 2026. Regeringens meddelelse kalder det en trinvis tidsplan på 18 måneder.

Artiklen er til teknologichefer og produktchefer i indiske forbrugerapps, fintech-, edtech- og e-handelsvirksomheder og i udenlandske virksomheder med indiske brugere. Loven omfatter behandling uden for Indien, når den sker »i forbindelse med enhver aktivitet vedrørende udbud af varer eller tjenester til Data Principals (de registrerede) på Indiens område« (section 3(b)). Det følgende er den software, I skal bygge eller ændre. Det er ikke en juridisk gapanalyse: om I er omfattet, hvilke undtagelser der gælder, og hvordan jeres formål er formuleret, er spørgsmål til jeres juridiske rådgivere.

Hvem der reelt har udviklingsarbejde

Ligger alle jeres kundedata i én standard-SaaS-platform, kommer meget af rørføringen (kryptering, adgangslogs, sletningsjob) fra leverandørens køreplan. Jeres arbejde er oplysninger til brugerne, konfiguration og kontrakter. Læs de kontrakter: regel 6(1)(f) kræver, at sikkerhedsforanstaltninger skrives ind i dem, og et eksempel til regel 8 gør jer ansvarlige for, at jeres cloududbyder opbevarer data og logs i det krævede år.

Det tunge arbejde falder på virksomheder, der driver deres egne apps og databaser, fodrer et datawarehouse fra et dusin pipelines og leverer tredjeparts-SDK'er i mobilklienten. Det er det meste af det indiske forbrugerinternet.

Hvad hver regel kræver af jeres software

Oplysning (regel 3)

Oplysningen skal være »forståelig uafhængigt af andre oplysninger«, I offentliggør. Som minimum giver den »en specificeret beskrivelse af sådanne personoplysninger«, det fastlagte formål og en konkret beskrivelse af de varer, tjenester eller anvendelser, behandlingen muliggør. Den skal også oplyse, hvordan man trækker samtykke tilbage, udøver sine rettigheder og klager til Board.

I praksis:

• Dan oplysningerne ud fra en datafortegnelse. Felt for felt, koblet til formål. »Vi kan indsamle oplysninger som« er ikke specificeret.
• Versionér hver oplysning. Hver samtykkeregistrering skal pege på præcis den tekst, brugeren så.
• Planlæg for sprog. Lovens section 6(3) kræver, at man kan læse en anmodning om samtykke på engelsk eller et af sprogene i forfatningens Eighth Schedule. Hold oplysningernes indhold som oversættelige strenge, ikke som en PDF.
• Dæk eksisterende brugere. Section 5(2) kræver en oplysning, »så snart det med rimelighed er praktisk muligt«, til personer, der gav samtykke, før loven trådte i kraft. Det er en kampagne til hele jeres brugerbase.

Samtykke, tilbagetrækning og Consent Managers

Samtykke efter section 6 skal være specifikt og begrænset til de data, formålet kræver. Section 6(10) lægger bevisbyrden på jer: i en tvist skal I vise, at oplysningen blev givet, og samtykket indhentet. Den sætning er grunden til, at I har brug for en samtykkehovedbog og ikke en boolesk kolonne.

En brugbar hovedbog registrerer pr. bruger og formål: oplysningsversion, tidsstempel, kanal (web, app, Consent Manager) og handling (givet eller trukket tilbage). Kun tilføjelser.

Tilbagetrækning skal være lige så let som at give samtykke (regel 3(c)(i), section 6(4)). Var samtykket ét tryk under onboarding, kan tilbagetrækning ikke være en e-mail til supporten. Den skal også nå frem. Section 6(6) kræver, at I ophører med behandlingen, og får jeres Data Processors (databehandlere) til at ophøre, inden for rimelig tid. Samtykketjenesten udsender derfor hændelser om tilbagetrækning til alle systemer og leverandører, der handler på det formål: CRM, marketingplatform, analysepipeline.

En Consent Manager er et registreret, fælles kontaktpunkt, hvorigennem en bruger kan »give, forvalte, gennemgå eller trække sit samtykke tilbage« (section 6(7)). Efter First Schedule skal den være et selskab registreret i Indien med en egenkapital på mindst to crore (20 millioner) rupees, dens platform skal være uafhængigt certificeret efter standarder, som Board offentliggør, den må ikke kunne læse de data, den videresender, og den opbevarer samtykkeregistreringer i mindst syv år.

Reglerne overlader standarden til Board. Byg en indgående vej nu, så et samtykke eller en tilbagetrækning, der kommer fra en ekstern platform, håndteres præcis som én fra jeres egen brugergrænseflade, og bind jer først til et dataformat, når Board offentliggør et. Registreringen åbner omkring 13. november 2026, så integrationen starter realistisk set i begyndelsen af 2027.

Sikkerhedsforanstaltninger og logs (regel 6)

Minimumslisten: kryptering, sløring, maskering eller tokenisering; adgangskontrol på de berørte systemer; »overblik over adgangen til sådanne personoplysninger gennem passende logs, overvågning og gennemgang«; backup, så behandlingen kan fortsætte efter en hændelse; og opbevaring af »sådanne logs og personoplysninger i en periode på et år«.

Kravet om logning er dér, hvor de fleste systemer kommer til kort. Infrastrukturlogs fortæller jer ikke, hvem der læste hvilken kundes post fra hvilken tjeneste, og det svar skal I kunne give et år senere. Altså: adgangslogning på applikationsniveau for hvert lager med personoplysninger, sendt til et sted, hvor tjenesterne ikke kan ændre den, og opbevaret i mindst et år. Start tidligt; udrulningen på tværs af mange tjenester tager længere tid end nogen enkelt funktion her.

Underretning om brud (regel 7)

Når I bliver opmærksomme på et brud, underretter I hver berørt bruger »uden ophold« via brugerkontoen eller en registreret kontaktkanal: hvad der skete, de sandsynlige konsekvenser for dem, hvad I gør, hvad de selv kan gøre, og hvem de kan kontakte. Board får en beskrivelse uden ophold og derefter inden for 72 timer en detaljeret rapport om årsager, afbødning, eventuelle konklusioner om, hvem der forårsagede bruddet, afhjælpende foranstaltninger og de underretninger, der er sendt til brugerne. Board kan give længere tid efter skriftlig anmodning.

I software: en måde at beregne de berørte på (som afhænger af adgangslogsene ovenfor), skabeloner skrevet på forhånd, en underretningsvej, der ikke går gennem det kompromitterede system, og en drejebog, der navngiver, hvem der indberetter til Board.

Sletning og opbevaring (regel 8)

Section 8(7) kræver sletning, når samtykket trækkes tilbage, eller formålet ikke længere tjenes, medmindre en anden lov kræver opbevaring. Regel 8 tilføjer to ting.

For det første anses formålet for ophørt efter tre år uden kontakt for tre klasser i Third Schedule: e-handelsvirksomheder med mindst to crore (20 millioner) registrerede brugere i Indien, mellemmænd for onlinespil med mindst halvtreds lakh (5 millioner) og mellemmænd for sociale medier med mindst to crore (20 millioner). Adgang til kontoen og tokens med opsparet værdi er undtaget. I skal advare brugeren mindst 48 timer før sletning, og et login annullerer den. Det er en inaktivitetsmåler, en planlægger og et notifikationsjob. De tre år løber fra seneste kontakt eller reglernes ikrafttræden, alt efter hvad der kommer sidst, så ingen sletning forfalder i årevis, men målingen skal være rigtig fra starten.

For det andet fastsætter regel 8(3) et minimum: personoplysninger, trafikdata og behandlingslogs opbevares i mindst et år fra behandlingen. Reglens eksempel er en ordre på en e-bog, hvis detaljer skal overleve en sletning af kontoen. »Slet min konto« kan derfor ikke betyde DELETE FROM users. Det betyder: stop behandlingen, flyt det, der skal bevares, til et begrænset lager med en opbevaringsdato, og slet det, når datoen er passeret. Hver tabel har brug for en opbevaringsklasse, og det samme gælder hver kopi i backups, datawarehouse og jeres databehandleres systemer.

Anmodninger om rettigheder og kontaktoplysninger (regel 9 og 14)

Brugere kan bede om et resumé af deres data og behandlingen og identiteten på hver fiduciary og processor, I har delt dem med (section 11), bede om berigtigelse, fuldstændiggørelse, opdatering eller sletning (section 12) og udpege en person, der kan handle på deres vegne ved død eller manglende handleevne (section 14). Regel 14 kræver, at I offentliggør, hvordan man fremsætter en anmodning, og hvilken identifikator I har brug for, og at I besvarer klager inden for en offentliggjort frist på højst halvfems dage. Regel 9 kræver kontaktoplysningerne på jeres databeskyttelsesrådgiver (Data Protection Officer), eller på en person, der kan svare, i hvert svar.

Det skal bygges: modtagelse af anmodninger i appen, identitetskontrol knyttet til kontoen, en sagsstyring, der holder styr på fristen på halvfems dage, en eksport, der finder en brugers data på tværs af tjenester, og et register over videregivelser, så »hvem har I delt det med?« er en forespørgsel og ikke en undersøgelse.

Børn og personer med handicap (regel 10 til 12)

Efter loven er et barn enhver under atten. Før I behandler et barns data, skal I have verificerbart samtykke fra en forælder, og regel 10 kræver en kontrol af, at forælderen er en identificerbar voksen. Kontrollen kan bruge identitets- og aldersoplysninger, I allerede har om en registreret forælder, oplysninger som forælderen giver, eller »et virtuelt token koblet til sådanne oplysninger« fra en autoriseret enhed, herunder en udbyder af Digital Locker-tjenester. MeitY's DigiLocker offentliggør API'er til forespørgere for organisationer, der henter verificerede dokumenter; få jeres juridiske rådgivere til at bekræfte, hvilke kilder der opfylder reglen for jeres forløb.

Section 9(3) forbyder sporing, adfærdsovervågning og målrettet annoncering rettet mod børn. For en forbrugerapp er det et SDK-problem, og den sikre standard er at slå analyse- og annonce-SDK'er fra for alle konti, der er markeret som mindreårige, i stedet for at forsøge at konfigurere dem til at overholde reglerne.

Regel 11 dækker lovlige værger for personer med handicap: I kontrollerer, at værgen er udpeget af en domstol, en udpeget myndighed eller en lokal komité. Det er en dokumentupload og en kø til manuel gennemgang.

Regel 12 og Fourth Schedule undtager visse behandlinger fra kravet om forældresamtykke og forbuddet mod sporing, blandt andet sundhedsydelser, uddannelsesinstitutioner (til uddannelsesaktiviteter og sikkerhed), realtidsplacering af sikkerhedshensyn og bekræftelse af, at en bruger ikke er et barn. En edtechvirksomhed bør ikke gå ud fra, at den tæller som en »uddannelsesinstitution«. Få det besvaret skriftligt.

Significant Data Fiduciaries (regel 13)

Udpeger regeringen jer som Significant Data Fiduciary (betydelig dataansvarlig), tilføjer regel 13 en årlig konsekvensanalyse vedrørende databeskyttelse og revision med en rapport til Board, due diligence af, at jeres algoritmiske software ikke bringer brugernes rettigheder i fare, og krav om at holde de personoplysninger, regeringen fastlægger, inden for Indiens grænser. Lovens section 10 tilføjer en databeskyttelsesrådgiver med base i Indien og en uafhængig datarevisor.

Hvad det koster at tage fejl

Schedule til loven fastsætter maksimale bøder: op til 250 crore (2,5 milliarder) rupees for ikke at træffe rimelige sikkerhedsforanstaltninger, op til 200 crore for ikke at underrette om et brud, op til 200 crore for at overtræde forpligtelserne vedrørende børns data, op til 150 crore for en Significant Data Fiduciarys yderligere forpligtelser og op til 50 crore for overtrædelse af enhver anden bestemmelse.

En plan på syv måneder

Oktober 2026: overblik. List hvert lager og hver pipeline med indiske brugeres personoplysninger, inklusive backups, datawarehouse, logs og databehandlere. Kobl hvert felt til et formål. Markér brugere, der er børn, tjek grænserne i Third Schedule, og få jeres juridiske rådgiveres vurdering af omfang og undtagelser.

November 2026: design. Indholdsmodel og versionering for oplysninger, skema for samtykkehovedbogen, opbevaringsklasser pr. tabel og forløbet for anmodninger om rettigheder. Start adgangslogningen. Efter omkring 13. november: hold øje med Board for registrerede Consent Managers og standarden for interoperabilitet.

December 2026 til januar 2027: oplysninger og samtykke. Lancér samtykketjenesten med hændelser om tilbagetrækning sendt ud til databehandlerne. Oversæt oplysningerne.

Februar 2027: opbevaring og sletning. Begrænset opbevaringslager, sletningsjob på tværs af primære lagre og databehandlere og inaktivitetsmåleren, hvis I falder ind under en klasse i Third Schedule. Ændr databehandleraftalerne, så de dækker sikkerhedsforanstaltninger og opbevaringen på et år.

Marts 2027: rettigheder og brud. Modtagelse af anmodninger, verifikation, sagsstyring med fristen på halvfems dage, eksport på tværs af tjenester og register over videregivelser. Drejebog for brud, skabeloner og en uafhængig underretningsvej, efterfulgt af én skrivebordsøvelse.

April 2027: børn og eksisterende brugere. Aldersgrænser, verifikation af forældre, SDK-kontakter for mindreårige og gennemgang af værger. Send oplysningen efter section 5(2) til eksisterende brugere. Integrér med Consent Managers, hvis standarden er kommet.

Begyndelsen af maj 2027: test og frys. Træk et samtykke tilbage, og bekræft, at marketingplatformen stoppede. Anmod om en sletning, og bekræft, at kopien i datawarehouse kom i opbevaring. Saml dokumentationen, og stop med at ændre ting i ugen før 13. maj.

Planen forudsætter tre eller fire parallelle spor. På ældre eller udokumenterede systemer tager overblikket alene mere end en måned.

Hvor dette passer ind

Har I bygget til GDPR, kan en god del af rørføringen genbruges, og vores ingeniørrettede GDPR-guide dækker mønstrene for samtykke og sletning. De forskelle, der bider, er den specificerede oplysning, minimumsopbevaringen på et år og verificerbart forældresamtykke op til atten år. Et andet asiatisk marked med sin egen ordning findes i registrering som PSE i Indonesien.

Vi bygger samtykketjenester, opbevarings- og sletningsjob, adgangslogning og forløb for anmodninger om rettigheder ind i eksisterende produkter, og vi tilføjer ingeniører til jeres team gennem teamforstærkning, når planen kræver flere hænder, end I har. Vi er ingeniører, ikke jurister: omfang og formuleringer hører hjemme hos jeres juridiske rådgivere, og vi bygger efter deres svar. Skriv til office@c9group.dev.